Freigeben über

PlayReady-Inhaltsverschlüsselungsmodi

Dieses Thema enthält eine Übersicht über Inhaltsverschlüsselungsmodi in PlayReady-Systemen. Eine Übersicht über PlayReady- und Inhaltsverschlüsselung finden Sie unter PlayReady Content Encryption. Siehe Glossar für Verschlüsselungsbegriffe und Definitionen.

PlayReady Version 1.0 führte den AES-128 CTR-Inhaltsverschlüsselungsmodus zusätzlich zum microsoftspezifischen COCKTAIL-Verschlüsselungsmodus ein, der zuvor in WMDRM (Windows Media Digital Rights Management) verwendet wurde. Der AES-128 CTR-Inhaltsverschlüsselungsmodus verwendet AES-Schlüssel mit einer Länge von 128 Bits, die für die Inhaltsdateien im Counter Mode (CTR) verwendet werden.

Ab Version 4.0 unterstützen PlayReady-Systeme AES 128-Bit-Tasten sowohl im Counter Mode (CTR) als auch im Chiffreblockkettenmodus (CBC).

Diese Änderung stellt sicher, dass Dienste, die PlayReady verwenden, vollständig von einem einzigartigen Stream- und Dateiformat auf allen Geräten profitieren können. Darüber hinaus unterstützt Microsoft den CMAF-Standard (Common Media Application Format), wie in ISO/IEC FDIS 23000-19 definiert.

Allgemeine Verschlüsselungsmodi

Der ISO-Standard ISO/IEC 23001-7 definiert vier Gängige Verschlüsselungsmodi.

Allgemeine Verschlüsselungsmodi

PlayReady-Clients ab Version 4.0 unterstützen AES-CBC-Schlüssel, die unterstützung für den allgemeinen Verschlüsselungsmodus "cbcs" sowie AES CTR-Schlüssel für den allgemeinen Verschlüsselungsmodus "cenc" ermöglichen. Vor Version 4.0 war AES CTR der Modus, der hauptsächlich von PlayReady-Clients unterstützt wurde, was die Unterstützung für den allgemeinen Verschlüsselungsmodus "cenc" ermöglicht. Beachten Sie, dass allgemeine Verschlüsselungsmodi "cens" und "cbc1" in einem PlayReady-Ökosystem zulässig und technisch machbar sind, aber nicht unterstützt werden.

Unterstützung für das cbcs-AES-CBC Verschlüsselungsschema

Alle Clients, die auf oder nach PlayReady PK Version 4.0 basieren, unterstützen möglicherweise CBC-Schlüssel. Die Unterstützung ist jedoch für Clients optional und über eine zusätzliche Eigenschaft im Lizenzerwerbsprotokoll an Lizenzserver signalisiert.

Version COCKTAIL 'cenc' 'cbcs'
PlayReady Client 1.0 unterstützt unterstützt Nicht unterstützt
PlayReady Client 2.0 unterstützt unterstützt Nicht unterstützt
PlayReady Client 2.5 unterstützt unterstützt Nicht unterstützt
PlayReady Client 3.0 Nicht unterstützt unterstützt Nicht unterstützt
PlayReady Client 3.3 Nicht unterstützt unterstützt Nicht unterstützt
PlayReady Client 4.0 Nicht unterstützt unterstützt unterstützt

Hinweis

  • Alle Xbox One-Einheiten, die mit Version 1709 oder höher aktualisiert wurden, unterstützen "cbcs".
  • Alle PlayReady-Lizenzserver ab Version 4.0 unterstützen das Ausstellen von Lizenzen mit CBC-Schlüsseln.

Signalisierung der ALGID im PlayReady Header

Der PlayReady-Header ist ein XML-Dokument, das in der Regel in der Kopfzeile einer Inhaltsdatei oder eines Datenstroms enthalten ist. Es beschreibt die PlayReady-Attribute, die für einen Client zum Entschlüsseln dieses Inhalts erforderlich sind. Der PlayReady-Header verfügt über eine eigene Spezifikation und Versionsverwaltung. Weitere Informationen finden Sie unter PlayReady Header Specification.

Version PlayReady Header 4.3 PlayReady Header 4.2 PlayReady-Kopfzeile 4.1 PlayReady Header 4.0
PlayReady Client 4.0
(siehe Hinweis 4)		 ✔ ✔ ✔ ✔
PlayReady Client 3.3
(siehe Hinweis 3)		 ✔ ✔ ✔
PlayReady Client 3.0
(siehe Hinweis 3)		 ✔ ✔ ✔
PlayReady Client 2.5
(siehe Hinweis 2)		 ✔ ✔
PlayReady Client 2.0
(siehe Hinweis 2)		 ✔ ✔
PlayReady Client 1.0
(siehe Hinweis 1)		 ✔

Hinweis

  • (4) Xbox One, Version 1709 oder höher, sind PlayReady 4.X-Clients.
  • (3) Windows 10 alle Versionen und Xbox One, Version 1703 oder niedriger, sind PlayReady 3.X-Clients. Neueste Nicht-Windows-Geräte (z. B. Smart TVs), die nach 2017 veröffentlicht wurden, sind PlayReady 3.X-Clients.
  • (2) Silverlight und Windows 8, 8.1 sind PlayReady 2.X-Clients. Die meisten Nicht-Windows-Geräte (z. B. Smart TVs), die zwischen 2011 und 2017 veröffentlicht werden, sind PlayReady 2.X-Clients.
  • (1) Die meisten Nicht-Windows-Geräte (z. B. Smart TVs), die zwischen 2008 und 2011 veröffentlicht werden, sind PlayReady 1.X-Clients.

Im Folgenden sehen Sie ein Beispiel für einen PlayReady-Header v4.2.

<WRMHEADER
          version="4.2.0.0"
          xmlns="http://schemas.microsoft.com/DRM/2007/03/PlayReadyHeader">
  <DATA>
    <PROTECTINFO>
      <KIDS>
        <KID ALGID="AESCTR" CHECKSUM="xNvWVxoWk04=" VALUE="0IbHou/5s0yzM80yOkKEpQ=="></KID>
        <KID ALGID="AESCTR" CHECKSUM="GnKaQIRacPU=" VALUE="/qgG2xbs4k2SKCxx6bhWqw=="></KID>
       </KIDS>
    </PROTECTINFO>
    <LA_URL>http://rm.contoso.com/rightsmanager.asmx</LA_URL>
    <DS_ID>AH+03juKbUGbHl1V/QIwRA==</DS_ID>
    <DECRYPTORSETUP>ONDEMAND</DECRYPTORSETUP>
  </DATA>
</WRMHEADER>

Der ALGID (Algorithmusbezeichner) ist eine Eigenschaft des KID-Elements und gibt den Verschlüsselungsalgorithmus an, der zum Verschlüsseln des Inhalts verwendet wurde. Ab PlayReady Header Version 4.2 ist die ALGID erforderlich und muss entweder auf "AESCTR" oder "COCKTAIL" festgelegt werden. Ab Version 4.3 kann die ALGID jedoch auch auf den Wert "AESCBC" festgelegt werden. Das folgende Beispiel zeigt eine PlayReady Header Version 4.3 mit den ALGID-Werten, die auf "AESCBC" festgelegt sind.

<WRMHEADER
          version="4.3.0.0"
          xmlns="http://schemas.microsoft.com/DRM/2007/03/PlayReadyHeader">
  <DATA>
    <PROTECTINFO>
      <KIDS>
        <KID VALUE="PV1LM/VEVk+kEOB8qqcWDg==" ALGID="AESCBC"/>
        <KID VALUE="tuhDoKUN7EyxDPtMRNmhyA==" ALGID="AESCBC"/>
      </KIDS>
    </PROTECTINFO>
    <LA_URL>http://rm.contoso.com/rightsmanager.asmx</LA_URL>
    <DS_ID>AH+03juKbUGbHl1V/QIwRA==</DS_ID>
    <DECRYPTORSETUP>ONDEMAND</DECRYPTORSETUP>
  </DATA>
</WRMHEADER>

Die folgende Abbildung zeigt einen Inhaltsfluss, in dem die Lizenzanforderung auf dem PlayReady-Header und der ALGID basiert.

Content Flow mit angegebener ALGID

Fehlende ALGIDs

Ab der PlayReady-Header-Version 4.3 fehlt möglicherweise die ALGID. Das folgende Beispiel zeigt eine PlayReady-Header-Version 4.3 mit fehlenden ALGID-Werten.

<WRMHEADER
          version="4.3.0.0"
          xmlns="http://schemas.microsoft.com/DRM/2007/03/PlayReadyHeader">
  <DATA>
    <PROTECTINFO>
      <KIDS>
        <KID VALUE="PV1LM/VEVk+kEOB8qqcWDg=="/>
      </KIDS>
    </PROTECTINFO>
    <LA_URL>http://rm.contoso.com/rightsmanager.asmx</LA_URL>
    <DS_ID>AH+03juKbUGbHl1V/QIwRA==</DS_ID>
    <DECRYPTORSETUP>ONDEMAND</DECRYPTORSETUP>
  </DATA>
</WRMHEADER>

Die folgende Abbildung zeigt einen Inhaltsfluss, in dem die Lizenzanforderung das CDMi-Modul verwendet, und die ALGID fehlt.

Inhaltsfluss mit fehlendem ALGID

Hinweis

Jede PlayReady-Kopfzeile kann Folgendes haben:

  • Nur ein Verschlüsselungstyp. Wenn beispielsweise ALGID="AESCTR" verwendet wird, werden alle Schlüssel für den Header im CTR-Modus verwendet. Wenn ALGID="AESCBC" verwendet wird, werden alle Schlüssel für diesen Header im CBC-Modus verwendet.
  • Wenn die ALGID fehlt, werden alle Schlüssel für diesen Header im Counter Mode oder Cipher Block Chaining verwendet, aber der Wert wird nicht in den Header eingefügt.
  • Wenn Sie eine Lizenzerwerbsanforderung mit einem PlayReady Header v4.3 an einen Lizenzserver unter v4.0 vornehmen, wird eine Ausnahme ausgelöst.
  • Eine Lizenzantwort kann eine oder mehrere Lizenzen enthalten, wobei jede Lizenz einen Schlüssel und eine beliebige Anzahl von Richtlinien enthält.

Warum der ALGID-Wert fehlt

Microsoft empfiehlt, dass Verschlüsselungen immer den gleichen ALGID-Wert in den PlayReady-Header einschließen, den sie beim Verarbeiten des Inhalts enthalten haben.

In einer Standardsituation verschlüsselt der Verschlüssler Inhalte und generiert den PlayReady-Header innerhalb des Inhalts. Der Verschlüsselnder weiß, welcher AES-Modus für die Verschlüsselung verwendet wird; Daher enthält sie diese Informationen in der ALGID-Eigenschaft des PlayReady-Headers. Clients initiieren Lizenzanforderungen basierend auf PlayReady-Headern, die aus echten Inhalten analysiert wurden, sodass der ALGID-Wert vorhanden und gültig ist.

In einigen Szenarien initiiert der Client eine Lizenzanforderung basierend auf einem einfachen KID-Wert (einer 128-Bit-GUID). In diesem Fall fehlt der ALGID-Wert im in der Lizenzanforderung eingefügten PlayReady-Header (auch als nicht angegeben bezeichnet). Ein Beispiel ist, wenn der Client eine Lizenzanforderung mithilfe von HTML5 EME-APIs sendet.

So behandelt der Client eine fehlende ALGID

Wenn der Client eine Lizenzanforderung basierend auf einem eingehenden PlayReady-Header initiiert, wird der ALGID-Wert in der Lizenzanforderung den Wert im Header widerspiegeln, da die Lizenzerwerbsabfrage eine Kopie des PlayReady-Headers enthält. In diesem Fall:

  • Für alle PlayReady-Header v4.2 oder niedriger ist der ALGID-Wert erforderlich und muss gültig sein.
  • Bei PlayReady-Headers ab Version 4.3 kann der ALGID-Wert entweder vorhanden und gültig sein oder fehlen.

So behandelt das Server-SDK eine fehlende ALGID

Alle lizenzen, die über eine Lizenzantwort übermittelt werden, MÜSSEN einen gültigen ALGID-Wert enthalten.

Wenn ALGID in der eingehenden Lizenzanforderung nicht angegeben ist, muss der Lizenzserver diese Informationen aus dem Back-End des Diensts abrufen und den richtigen Wert in die Lizenzantwort setzen.

Initialisierungs-Vektoren (IVs)

In PlayReady-Versionen 3.3 und früher werden nur 64-Bit-IVs (8-Byte-IVs) im CTR-Modus unterstützt. Ab PlayReady, Version 4.0, werden sowohl 64-Bit- als auch 128-Bit-IVs (8-Byte- und 16-Byte-IVs) sowohl im CTR- als auch im CBC-Modus unterstützt.

Beispiele

  • HLS-kompatible Datenströme, die häufig 128-Bit-IVs im CBC-Modus verwenden, werden jetzt unterstützt.
  • Einige HbbTV-konformen Streams, die 128-Bit-IVs im CTR-Modus verwenden, werden jetzt unterstützt.

Einschränkungen

  • Ein PlayReady-Header darf nur einen ALGID-Wert für alle KID-Elemente verwenden. Anders ausgedrückt: Alle Schlüssel, die zum Verschlüsseln der verschiedenen Spuren und Eigenschaften eines Asset verwendet werden, müssen AES CTR oder AES CBC sein. Fehlt das ALGID bei einem KID-Element, muss es bei allen KID-Elementen fehlen.
  • Vor PlayReady Version 4.4 löst das Generieren einer Lizenz mit einem CBC-Schlüssel eine Ausnahme aus, wenn das eingehende Client Zertifikat Windows und SL2000 ist. Dies liegt daran, dass Windows-Clients CBC nur auf SL3000-Einheiten unterstützen. Es kann jedoch möglich sein, eine Lizenz mit einem CBC-Schlüssel an einen SL2000-Client zu übermitteln, wenn dieser Client mindestens PlayReady Version 4.0 ist und die Unterstützung für den CBC-Modus deklariert.
  • Das Generieren einer Lizenz mit einem CBC-Schlüssel, wenn das eingehende Clientzertifikat ein Gerät ist, das eine Porting Kit-Version vor 4.0 verwendet, löst eine Ausnahme aus.
  • Das Generieren einer Lizenz mit einem CBC-Schlüssel, wenn die eingehende Lizenzanforderung keine Unterstützung für AES CBC angibt, löst eine Ausnahme aus.

Von Bedeutung

Dienste dürfen keine einzelnen Inhalte im CTR-Modus und im CBC-Modus mit demselben {KID, Ck}verschlüsseln.

  • Aus funktionalen Gründen würde ein Client, der sowohl eine Lizenz für {KID, Ck, AESCTR} als auch für {KID, Ck, AESCBC} erwirbt, nicht funktionieren.
  • Aus Gründen der Robustheit könnte ein Angreifer, der Zugriff auf denselben Inhalt hat, der mit demselben Schlüssel verschlüsselt ist, sowohl im CBC- als auch im CTR-Modus, inhalte einfacher entschlüsseln, ohne dass dies autorisierungsfrei ist.