PlayReady-Inhaltsverschlüsselungsmodi

Dieses Thema bietet eine Übersicht über die Inhaltsverschlüsselungsmodi in PlayReady-Systemen. Eine Übersicht über PlayReady und Inhaltsverschlüsselung finden Sie unter PlayReady Content Encryption. Unter Glossar finden Sie Verschlüsselungsbegriffe und -definitionen.

PlayReady Version 1.0 führte den AES-128 CTR-Inhaltsverschlüsselungsmodus zusätzlich zum Microsoft-spezifischen 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 Bit, die für die Inhaltsdateien im Zählermodus (CTR) verwendet werden.

Ab Version 4.0 unterstützen PlayReady-Systeme AES-128-Bit-Schlüssel sowohl im Counter Mode (CTR) als auch im Cipher Block Chaining Mode (CBC).

Durch diese Änderung wird sichergestellt, dass Dienste, die PlayReady verwenden, auf allen Geräten ein eindeutiges Stream- und Dateiformat nutzen können. Darüber hinaus unterstützt Microsoft den CMAF-Standard (Common Media Application Format), der in ISO/IEC FDIS 23000-19 definiert ist.

Allgemeine Verschlüsselungsmodi

Die ISO-Norm ISO/IEC 23001-7 definiert vier allgemeine Verschlüsselungsmodi.

PlayReady-Clients ab Version 4.0 unterstützen AES-CBC-Schlüssel, was die Unterstützung für den allgemeinen Verschlüsselungsmodus "cbcs" ermöglicht, zusätzlich zu AES CTR-Schlüsseln für den allgemeinen Verschlüsselungsmodus "cenc". 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 die allgemeinen 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. Der Support ist jedoch für Clients optional und wird ü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 die Ausgabe von Lizenzen mit CBC-Schlüsseln.

Signalisieren der ALGID im PlayReady-Header

Der PlayReady-Header ist ein XML-Dokument, das normalerweise im Header einer Inhaltsdatei oder eines Datenstroms enthalten ist. Sie beschreibt die PlayReady-Attribute, die ein Client zum Entschlüsseln dieses Inhalts benötigt. Der PlayReady-Header verfügt über eine eigene Spezifikation und Versionsverwaltung. Weitere Informationen finden Sie unter PlayReady-Headerspezifikation.

Version	PlayReady Header 4.3	PlayReady Header 4.2	PlayReady Header 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 wurden, sind PlayReady 2.X-Clients.
• (1) Die meisten Nicht-Windows-Geräte (z. B. Smart-TVs), die zwischen 2008 und 2011 veröffentlicht wurden, sind PlayReady 1.X-Clients.

Es folgt 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, bei dem die Lizenzanforderung auf dem PlayReady-Header basiert und die ALGID angegeben ist.

Fehlende ALGIDs

Ab Version 4.3 des PlayReady-Headers fehlt die ALGID möglicherweise. 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, bei dem die Lizenzanforderung das CDMi-Modul verwendet und die ALGID fehlt.

Hinweis

Jeder PlayReady-Header kann Folgendes aufweisen:

• Nur ein Verschlüsselungstyp. Wenn beispielsweise ALGID="AESCTR" verwendet wird, werden alle Schlüssel für den Header im CTR-Modus verwendet. Bei ALGID="AESCBC" 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 Zählermodus oder im Verschlüsselungsblockketten verwendet, aber der Wert wird nicht in den Header eingefügt.
• Eine Lizenzerwerbsanforderung mit einem PlayReady-Header v4.3 an einen Lizenzserver unter v4.0 löst eine Ausnahme aus.
• 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 im PlayReady-Header enthalten, den sie bei der Verarbeitung des Inhalts enthalten haben.

In einem Standardszenario verschlüsselt der Verschlüsselnder Inhalt und generiert den PlayReady-Header im Inhalt. Der Verschlüsselnde weiß, welchen AES-Modus er für die Verschlüsselung verwendet hat. Daher schließt sie diese Informationen in die ALGID-Eigenschaft des PlayReady-Headers ein. 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 PlayReady-Header, der in die Lizenzanforderung eingefügt wurde (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, spiegelt der ALGID-Wert in der Lizenzanforderung den im Header gefundenen Wert wider, da die Lizenzerwerbsanforderung 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 v4.3 oder höher kann der ALGID-Wert vorhanden und gültig sein oder fehlt.

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 vom Back-End des Diensts abrufen und den richtigen Wert in der Lizenzantwort angeben.

Initialisierungsvektoren (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-konforme 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 Qualitäten eines Medienobjekts verwendet werden, müssen AES CTR oder AES CBC sein. Wenn die ALGID in einem KID-Element fehlt, muss sie in 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 Clientzertifikat Windows ist und SL2000 eine Ausnahme auslöst. 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 aufweist und 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.

Wichtig

Dienste dürfen keinen einzelnen Inhalt 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 Stabilität könnte ein Angreifer, der Zugriff auf denselben Inhalt hat, der sowohl im CBC- als auch im CTR-Modus mit demselben Schlüssel verschlüsselt ist, Inhalte einfacher ohne Autorisierung entschlüsseln.