Partager via


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 du chiffrement de contenu et playReady, consultez PlayReady Content Encryption. Consultez glossaire pour connaître 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 du contenu AES-128 CTR utilise des clés AES, d'une longueur de 128 bits, appliquées aux fichiers de contenu en mode compteur (CTR).

À compter de la version 4.0, les systèmes PlayReady prennent en charge les clés 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 format de flux et de fichier unique 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/IEC 23001-7 définit quatre modes de chiffrement communs.

Modes de chiffrement courants

Les clients PlayReady commençant par 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 chiffrement commun « cenc ». Avant la version 4.0, AES CTR était le mode qui avait été principalement pris en charge par les clients PlayReady, ce qui permet la prise en charge du mode de chiffrement commun « cenc ». Notez que les modes de chiffrement courants « cens » et « cbc1 » sont autorisés et techniquement doables dans un écosystème PlayReady, mais pas pris en charge.

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

Tous les clients construits à partir de la version 4.0 de PlayReady PK peuvent prendre en charge les clés CBC. La prise en charge est facultative pour les clients, cependant, et signalée aux serveurs de licence par le biais d’une propriété supplémentaire dans le protocole d’acquisition de licence.

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

Remarque

  • 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 pour qu’un client déchiffre ce contenu. L’en-tête PlayReady a sa propre spécification et sa gestion des versions. Pour plus d’informations, consultez Spécification de l’en-tête PlayReady.

Version En-tête PlayReady 4.3 En-tête PlayReady 4.2 En-tête PlayReady 4.1 En-tête PlayReady 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)

Remarque

  • (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 inférieure sont les clients PlayReady 3.X. Les nouveaux appareils non-Windows (par exemple, les téléviseurs intelligents) publiés après 2017 sont des 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, les téléviseurs intelligents) publiés entre 2011 et 2017 sont des clients PlayReady 2.X.
  • (1) La plupart des appareils non-Windows (par exemple, les téléviseurs intelligents) 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 utilisé pour chiffrer le contenu. À compter de PlayReady Header version 4.2, l’ALGID est obligatoire 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 l’ALGID est spécifié.

Flux de contenu avec ALGID spécifié

ALGID manquants

À partir de l'en-tête PlayReady 4.3, l'ALGID peut être absent. 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 l’ALGID est manquant.

Flux de contenu avec ALGID manquant

Remarque

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.
  • La création d'une demande d'acquisition de licence avec un en-tête PlayReady v4.3 vers un serveur de licences dont la version est inférieure à 4.0 entraînera 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 aux encrypteurs d’inclure toujours la même valeur ALGID dans l’en-tête PlayReady qu’ils incluaient lorsqu’ils ont traité le 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 ; Ainsi, 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 les en-têtes PlayReady analysés en dehors 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 en fonction d’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 sera manquante (également appelée non spécifiée). Par exemple, lorsque 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 en fonction d’un en-tête PlayReady entrant, la valeur ALGID dans la demande de licence reflète la valeur trouvée dans l’en-tête, car le défi 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 inférieurs, la valeur ALGID est requise et doit être valide.
  • Pour playReady Headers 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 fournies par le biais d’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 à partir du serveur principal du service et placer la valeur appropriée dans la réponse de la licence.

Vecteurs d'initialisation (IV)

Dans les versions PlayReady 3.3 et antérieures, seules les IV de 64 bits (IV de 8 octets) sont prises en charge en mode CTR. À compter de PlayReady version 4.0, les IVs 64 bits et 128 bits (8 octets et 16 octets) sont prises en charge dans les modes CTR et CBC.

Exemples:

  • Les flux compatibles HLS qui utilisent fréquemment des IV 128 bits en mode CBC sont désormais pris en charge.
  • Certains flux conformes à la norme HbbTV qui utilisent des IV 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 n’importe quel élément KID, il doit être absent de 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. Il peut être possible de fournir une licence avec une clé CBC à un client SL2000, toutefois, si ce client est PlayReady version 4.0 minimale et déclare la prise en charge du mode CBC.
  • La génération d’une licence avec une clé CBC lorsque le certificat client correspond à un appareil utilisant 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 de l'AES CBC provoquera une exception.

Importante

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 {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 peut plus facilement déchiffrer le contenu sans autorisation.