Modes de chiffrement de contenu PlayReady

Cette rubrique fournit une vue d’ensemble des modes de chiffrement de contenu dans les systèmes PlayReady. Pour obtenir une vue d’ensemble de PlayReady et du chiffrement de contenu, consultez Chiffrement de contenu PlayReady. Consultez Glossaire pour les termes et définitions de chiffrement.

PlayReady version 1.0 a introduit le mode de chiffrement de contenu CTR AES-128, en plus du mode de chiffrement COCKTAIL spécifique à Microsoft précédemment utilisé dans WMDRM (Windows Media Digital Rights Management). Le mode de chiffrement de contenu CTR AES-128 utilise des clés AES, avec une longueur de 128 bits utilisée sur les fichiers de contenu en mode compteur (CTR).

À compter de la version 4.0, les systèmes PlayReady prennent en charge les touches AES 128 bits en mode compteur (CTR) et en mode de chaînage de blocs de chiffrement (CBC).

Cette modification garantit que les services utilisant PlayReady peuvent tirer pleinement parti d’un flux et d’un format de fichier uniques sur tous les appareils. En outre, Microsoft prend en charge la norme CMAF (Common Media Application Format), telle que définie dans ISO/IEC FDIS 23000-19.

Modes de chiffrement courants

La norme ISO ISO/IEC 23001-7 définit quatre modes de chiffrement courants.

Les clients PlayReady à partir de la version 4.0 prennent en charge les clés CBC AES, ce qui permet la prise en charge du mode de chiffrement commun « cbcs », en plus des clés CTR AES pour le mode de chiffrement commun « cenc ». Avant la version 4.0, le CTR AES était le mode qui était principalement pris en charge par les clients PlayReady, ce qui permettait la prise en charge du mode de chiffrement commun « cenc ». Notez que les modes de chiffrement commun « cens » et « cbc1 » sont autorisés et techniquement faisables dans un écosystème PlayReady, mais pas pris en charge.

Prise en charge du schéma de chiffrement AES-CBC « cbcs »

Tous les clients basés sur ou après PlayReady PK version 4.0 peuvent prendre en charge les clés CBC. La prise en charge est facultative pour les clients, mais elle est signalée aux serveurs de licences via une propriété supplémentaire dans le protocole d’acquisition de licence.

Version	COCKTAIL	'cenc'	'cbcs'
PlayReady Client 1.0	supported	supported	non pris en charge
PlayReady Client 2.0	supported	supported	non pris en charge
PlayReady Client 2.5	supported	supported	non pris en charge
PlayReady Client 3.0	non pris en charge	supported	non pris en charge
PlayReady Client 3.3	non pris en charge	supported	non pris en charge
PlayReady Client 4.0	non pris en charge	supported	supported

Notes

• Toutes les unités Xbox One mises à niveau avec la version 1709 ou ultérieure prennent en charge « cbcs ».
• Tous les serveurs de licences PlayReady à compter de la version 4.0 prennent en charge l’émission de licences avec des clés CBC.

Signalisation de l’ALGID dans l’en-tête PlayReady

L’en-tête PlayReady est un document XML généralement inclus dans l’en-tête d’un fichier de contenu ou d’un flux. Il décrit les attributs PlayReady nécessaires à un client pour déchiffrer ce contenu. L’en-tête PlayReady a sa propre spécification et son propre contrôle de version. Pour plus d’informations, consultez Spécification de l’en-tête PlayReady.

Version	PlayReady Header 4.3	PlayReady Header 4.2	PlayReady Header 4.1	PlayReady Header 4.0
PlayReady Client 4.0 (voir la note 4)	✔	✔	✔	✔
PlayReady Client 3.3 (voir la note 3)		✔	✔	✔
PlayReady Client 3.0 (voir la note 3)		✔	✔	✔
PlayReady Client 2.5 (voir la note 2)			✔	✔
PlayReady Client 2.0 (voir la note 2)			✔	✔
PlayReady Client 1.0 (voir la note 1)				✔

Notes

• (4) Xbox One version 1709 ou ultérieure sont des clients PlayReady 4.X.
• (3) Windows 10 toutes les versions et Xbox One version 1703 ou antérieure sont des clients PlayReady 3.X. Les derniers appareils non-Windows (par exemple, les téléviseurs intelligents) publiés après 2017 sont les clients PlayReady 3.X.
• (2) Silverlight et Windows 8, 8.1 sont des clients PlayReady 2.X. La plupart des appareils non Windows (par exemple, smart TV) publiés entre 2011 et 2017 sont des clients PlayReady 2.X.
• (1) La plupart des appareils non Windows (par exemple, smart TV) publiés entre 2008 et 2011 sont des clients PlayReady 1.X.

Voici un exemple d’en-tête PlayReady 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>

L’ALGID (identificateur d’algorithme) est une propriété de l’élément KID et spécifie l’algorithme de chiffrement qui a été utilisé pour chiffrer le contenu. À compter de la version 4.2 de l’en-tête PlayReady, l’ALGID est requis et doit être défini sur « AESCTR » ou « COCKTAIL ». Toutefois, à compter de la version 4.3, l’ALGID peut également être défini sur la valeur « AESCBC ». L’exemple suivant montre un en-tête PlayReady version 4.3 avec les valeurs ALGID définies sur « AESCBC ».

<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>

La figure suivante montre un flux de contenu, où la demande de licence est basée sur l’en-tête PlayReady et où l’ALGID est spécifié.

ALGID manquants

À compter de l’en-tête PlayReady version 4.3, l’ALGID peut être manquant. L’exemple suivant montre un en-tête PlayReady version 4.3 avec des valeurs ALGID manquantes.

<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>

La figure suivante montre un flux de contenu, où la demande de licence utilise le module CDMi et où l’ALGID est manquant.

Notes

Chaque en-tête PlayReady peut avoir :

• Un seul type de chiffrement. Par exemple, si ALGID="AESCTR », toutes les clés de l’en-tête sont utilisées en mode CTR. Quand ALGID="AESCBC », toutes les clés de cet en-tête sont utilisées en mode CBC.
• Lorsque l’ALGID est manquant, toutes les clés de cet en-tête sont utilisées en mode compteur ou chaînage de blocs de chiffrement, mais la valeur n’est pas insérée dans l’en-tête.
• Le fait d’envoyer une demande d’acquisition de licence avec un en-tête PlayReady v4.3 à un serveur de licences inférieur à la version 4.0 lève une exception.
• Une réponse de licence peut inclure une ou plusieurs licences, où chaque licence contient une clé et un nombre quelconque de stratégies.

Pourquoi la valeur ALGID est manquante

Microsoft recommande que les encrypteurs incluent toujours la même valeur ALGID dans l’en-tête PlayReady qu’ils ont incluse lors du traitement du contenu.

Dans un scénario standard, le chiffreur chiffre le contenu et génère l’en-tête PlayReady dans le contenu. Le chiffreur sait quel mode AES il a utilisé pour le chiffrement ; par conséquent, il inclut ces informations dans la propriété ALGID de l’en-tête PlayReady. Les clients lancent des demandes de licence basées sur des en-têtes PlayReady analysés à partir du contenu réel, de sorte que la valeur ALGID est présente et valide.

Dans certains scénarios, le client lance une demande de licence basée sur une valeur KID simple (guid 128 bits). Dans ce cas, la valeur ALGID dans l’en-tête PlayReady inséré dans la demande de licence va être manquante (également appelée non spécifié). Par exemple, le client effectue une demande de licence à l’aide des API EME HTML5.

Comment le client gère un ALGID manquant

Si le client lance une demande de licence basée sur un en-tête PlayReady entrant, la valeur ALGID dans la demande de licence va refléter la valeur trouvée dans l’en-tête, car la demande d’acquisition de licence inclut une copie de l’en-tête PlayReady. Dans ce cas :

• Pour tous les en-têtes PlayReady v4.2 ou version antérieure, la valeur ALGID est requise et doit être valide.
• Pour les en-têtes PlayReady v4.3 ou version ultérieure, la valeur ALGID peut être présente et valide, ou manquante.

Comment le Kit de développement logiciel (SDK) serveur gère un ALGID manquant

Toutes les licences remises via une réponse de licence DOIVENT inclure une valeur ALGID valide.

Si ALGID n’est pas spécifié dans la demande de licence entrante, le serveur de licences doit obtenir ces informations auprès du serveur principal du service et mettre la valeur appropriée dans la réponse de licence.

Vecteurs d’initialisation (IV)

Dans PlayReady versions 3.3 et antérieures, seules les IV 64 bits (8 octets) sont prises en charge en mode CTR. À compter de PlayReady version 4.0, les volumes d’adresses ip 64 bits et 128 bits (8 octets et 16 octets) sont pris en charge à la fois dans les modes CTR et CBC.

Exemples :

• Les flux conformes HLS qui utilisent fréquemment des IV 128 bits en mode CBC sont désormais pris en charge.
• Certains flux conformes HbbTV qui utilisent des volumes d’identité 128 bits en mode CTR sont désormais pris en charge.

Limites

• Un en-tête PlayReady ne doit utiliser qu’une seule valeur ALGID pour tous les éléments KID. En d’autres termes, toutes les clés utilisées pour chiffrer les différentes pistes et qualités d’une ressource doivent être AES CTR ou AES CBC. Si l’ALGID est manquant sur un élément KID, il doit l’être dans tous les éléments KID.
• Avant PlayReady version 4.4, la génération d’une licence avec une clé CBC lorsque le certificat client entrant est Windows et SL2000 lève une exception. Cela est dû au fait que les clients Windows prennent en charge CBC uniquement sur les unités SL3000. Toutefois, il peut être possible de fournir une licence avec une clé CBC à un client SL2000, si ce client est PlayReady version 4.0 minimale et déclare prendre en charge le mode CBC.
• La génération d’une licence avec une clé CBC lorsque le certificat client entrant est un appareil qui utilise une version du kit de portage antérieure à la version 4.0 lève une exception.
• La génération d’une licence avec une clé CBC lorsque la demande de licence entrante n’indique pas la prise en charge d’AES CBC lève une exception.

Important

Les services ne doivent pas chiffrer un seul élément de contenu en mode CTR et en mode CBC à l’aide du même {KID, Ck}.

• Pour des raisons fonctionnelles, un client qui acquiert une licence pour {KID, Ck, AESCTR} et pour {KID, Ck, AESCBC} ne fonctionne pas.
• Pour des raisons de robustesse, un attaquant ayant accès au même contenu chiffré avec la même clé dans les modes CBC et CTR pourrait plus facilement déchiffrer du contenu sans autorisation.