Empaquetage et remise de contenu

La fonctionnalité de base de PlayReady consiste à protéger le contenu contre une utilisation non autorisée. Pour ce faire, votre contenu doit d’abord être chiffré et un en-tête PlayReady associé doit être inséré dans le contenu. Le système qui effectue cette opération est le packager, également appelé chiffreur, qui est parfois intégré à l’encodeur.

Cette rubrique décrit différentes façons de chiffrer et de distribuer votre contenu à l’aide de PlayReady.

Empaquetage du contenu PlayReady : chiffrement et insertion de l’en-tête DRM

Le processus de chiffrement du contenu clair consiste à définir une ou plusieurs clés de chiffrement, en utilisant ces clés pour chiffrer les octets qui constituent le contenu lui-même et en insérant un en-tête DRM dans le contenu (dans les fichiers du contenu, ou dans le manifeste si le contenu en a un).

Tout le contenu chiffré protégé par PlayReady doit avoir un en-tête PlayReady inséré dans le fichier chiffré. Cet en-tête PlayReady est utilisé par un client PlayReady pour localiser ou acquérir une licence pour ce contenu particulier. Un en-tête PlayReady est composé de XML encodé en UTF-16. Il inclut les identificateurs de clé (KID) utilisés pour chiffrer le contenu, une URL par défaut que le client utilisera pour acquérir une licence à partir de laquelle aucun autre élément n’est fourni et d’attributs personnalisés.  

Tout outil d'empaquetage qui empaquette du contenu clair doit implémenter un générateur d'en-tête PlayReady afin de créer l'en-tête et de l'intégrer au contenu chiffré. L’en-tête PlayReady doit être implémenté en fonction de la spécification de l’en-tête PlayReady. Il existe plusieurs façons de créer un générateur d’en-tête PlayReady dans votre packager :

• Développez-le vous-même en fonction de la spécification de l’en-tête PlayReady. 
• Utilisez l’API du Kit de développement logiciel (SDK) PlayReady Server qui génère un en-tête PlayReady. 
• Utilisez l’API Windows 10 qui génère un en-tête PlayReady. 

Votre contenu chiffré peut contenir plusieurs en-têtes DRM, y compris les en-têtes PlayReady, ainsi que les en-têtes DRM tiers. Pour plus d’informations sur le fonctionnement de ce processus, consultez Utilisation des outils de chiffrement.

Type de contenu

PlayReady peut être utilisé pour protéger le contenu audio et vidéo. Les types d’encodage les plus courants utilisés avec PlayReady sont MPEG-4 AVC (H.264), le codage vidéo haute efficacité (HEVC) H.265 et la norme AV1. PlayReady n’est pas limité à ces normes et peut être utilisé avec n’importe quel format audio et vidéo pris en charge sur l’appareil client.

PlayReady version 1 et 2 vous permet de créer un package protégé contenant du contenu qui n’est pas limité aux charges utiles audio ou vidéo. Ces packages, appelés enveloppes, peuvent contenir des fichiers tels qu’une collection de fichiers de données et d’exécutables (par exemple, une application distribuée par un magasin d’applications), des images (par exemple, papier peint à l’écran) ou des livres électroniques. Ce contenu est empaqueté encapsulant les fichiers dans un fichier d’enveloppe, qui peut être déchiffré d’une manière similaire au contenu audio/vidéo.

Ces types de contenu non audio/vidéo ne sont plus pris en charge dans PlayReady 3.0 et versions ultérieures. 

Outils de chiffrement

Microsoft n’inclut pas de système de conditionnement dans le cadre des livrables PlayReady. PlayReady fournit à la place des spécifications basées sur les normes de chiffrement courantes à utiliser par les encodeurs. Par conséquent, le format de chiffrement n’est pas spécifique à PlayReady, mais il s’agit d’une fonction du format de fichier. Le format de chiffrement le plus largement utilisé aujourd’hui est le format standard ISO de chiffrement commun, ISO/IEC 23001-7.

En fait, vous pouvez créer votre propre packager ou utiliser n’importe quel type de chiffrement open source (par exemple, ffmpeg). En outre, vous pouvez travailler avec une entreprise d’encodeur professionnelle si vous souhaitez chiffrer du contenu avec PlayReady (par exemple, Harmonique, Elemental, Ericsson, Wowza, Allegro).

Utilisation des outils de chiffrement

PlayReady prend en charge la norme de chiffrement commun ISO IEC. Ce processus est identique à celui décrit dans la section Processus de chiffrement et de licence de base, à ceci près que les en-têtes seront inclus pour d'autres les autres DRM, chacun en tant que charge utile de la boîte d'en-tête spécifique au système de protection (« pssh »), identifiée par l'ID système de ce DRM. Tous ces en-têtes auront leur propre syntaxe qui désigne les KID ou les informations requises pour accéder finalement aux clés de contenu. Et les clés de contenu de cet élément seront identiques pour tous les systèmes de gestion des droits numériques.

Utilisation de clés de chiffrement

Il existe de nombreuses façons de chiffrer vos ressources. Le plus simple pour le plus sophistiqué dépend de la complexité que vous souhaitez concevoir dans le système et des besoins du service.

Prenons par exemple une ressource de diffusion en continu adaptative, comme illustré dans la figure ci-dessous. Il a quatre qualités vidéo différentes, une piste audio et une piste de sous-titre. Il est encodé dans des fichiers MP4 segmentés, avec des segments de 2,0 secondes chacun. Il s’agit d’une ressource qui est disponible dans plusieurs formats en fonction de ce que le client préfère écouter ou regarder. Smooth Streaming, HLS et DASH sont les variantes les plus courantes. Pendant la lecture, le client (le lecteur vidéo) va télécharger successivement les segments de la ressource sur le réseau, en sélectionnant pour chaque lecture le segment vidéo à partir de la piste vidéo appropriée, afin de maintenir la qualité de lecture aussi élevée que possible, compte tenu des contraintes de bande passante réseau, de la vitesse de lecture et d’autres ressources limitées comme les fonctionnalités du lecteur. Cette logique est appelée lecture en streaming adaptative, régie par certaines règles heuristiques implémentées dans le lecteur. 

Chiffrement de la ressource avec une seule clé

La façon la plus simple de chiffrer ces ressources consisterait à utiliser une clé de contenu unique pour chiffrer l'ensemble (généralement les sous-titres ne sont pas chiffrés, ce n’est pas contre une règle, mais ils sont généralement conservés en clair). L’utilisation d’une clé de contenu facilite la vie du serveur de licences, car le serveur de licences doit fournir une clé {KID, CK}. Cette clé serait généralement acquise par le client avant la lecture.

Chiffrement de la ressource avec deux clés, en réservant une à la meilleure qualité

Il y a eu des améliorations au cours des dernières années pour utiliser plusieurs clés par ressource, principalement pilotées par l’exigence d’autoriser uniquement certains clients les plus robustes à consommer le contenu de la plus haute qualité. Avec l’arrivée du contenu Ultra HD (4K) et avec l’ajout d’une plage dynamique élevée (HDR) pour un contenu de couleur plus élevé, il y avait besoin de studios et de services pour permettre la qualité la plus élevée uniquement sur certains clients, qui ont généralement des DRM matérielles intégrées. Dans ce scénario, la ressource est chiffrée à l’aide d’une clé de contenu {kid1, ck1} pour toutes les pistes, à l’exception de la piste 4K chiffrée à l’aide d’une autre clé de contenu {kid2, ck2}. Plus précisément :

• Un client autorisé à jouer uniquement jusqu'à la Full HD (et non la piste 4K) recevra une licence PlayReady comprenant uniquement {kid1, ck1}. 
• Un client autorisé à jouer jusqu'en 4K recevra une licence PlayReady, incluant {kid1, ck1} et {kid2, ck2}.

À l’aide de cette complexité supplémentaire, le service peut s’assurer que certains clients ne pourront pas déchiffrer la piste 4K et que la piste 4K peut être réservée uniquement aux clients auxquels le service fait le plus confiance. 

Chiffrement de la ressource avec une clé par piste

Le service peut avoir une carte plus complexe des droits à appliquer. Certains clients, selon leur taille d’écran, leur robustesse, leurs sorties et leur emplacement, peuvent être autorisés à accéder uniquement à certaines pistes vidéo, certaines qualités vidéo et certaines pistes audio. Pour garantir que le service dispose d’une flexibilité totale pour appliquer un ensemble arbitraire de restrictions à l’avenir, il peut chiffrer une ressource avec une clé de contenu spécifique à chaque piste. Par exemple:

• Un client autorisé à lire des contenus uniquement en 720p se verra délivrer une licence PlayReady, y compris {kid1, ck1}, {kid2, ck2} et {kidA, ckA}. 
• Un client autorisé à jouer jusqu’à 4K sera remis une licence PlayReady, y compris {kid1, ck1}, {kid2, ck2}, {kid3, ck3}, {kid4, ck4} et {kidA, ckA}. 
• Un client qui lit hors ligne la version 4K de la ressource (préalablement téléchargée) recevra une licence PlayReady comprenant {kid4, ck4} et {kidA, ckA}. 

Modification périodique des clés de chiffrement (ressource multi-périodes) : rotation des licences

Dans certains scénarios, le service souhaite modifier les clés de chiffrement occasionnellement, généralement aux limites du programme. Par exemple, un flux linéaire en direct a plusieurs périodes avec du contenu libre à air auquel vous souhaitez que tout le monde ait accès, suivi d’un contenu limité aux abonnés. La modification des clés de chiffrement aux limites du programme permet au service de fournir les clés gratuites pour la diffusion en clair {KIDi1, CKi1} à tous les utilisateurs sans aucune restriction, et de remettre les clés de contenu {kidi2, cki2} uniquement aux abonnés qui ont réussi à se connecter au service.

Notez que cette rotation de licence n’est pas très évolutive : chaque fois que les clés de chiffrement changent, tous les clients demandent les nouvelles clés de chiffrement à l’aide de leur propre demande de licence. Cela peut entraîner un pic élevé de demandes de licence dans les systèmes avec un grand nombre de clients. 

Modification fréquente des clés de chiffrement : rotation évolutive des clés

Il existe un mécanisme avancé dans PlayReady appelé rotation de clé évolutive (par opposition à la rotation des licences). Cette méthode stocke un magasin de licences incorporé (ELS) dans le flux du contenu réel. Dans ce mécanisme, la clé utilisée pour chiffrer le segment A2 lui-même est appelée clé feuille {kidA2, ckA2}, et est fournie dans l’ELS du segment A2, étant elle-même chiffrée avec une clé distincte qui est la même pour tous les segments de la piste A, appelée clé racine {kidRA, ckRA}. Si vous êtes familiarisé avec MPEG-2 TS et le chiffrement du mot de contrôle, il s'agit d'un mécanisme similaire, sauf que le chiffrement est beaucoup plus fort et plus flexible.

Supposons que cette ressource soit la télévision linéaire en direct. Lorsque le client tente de lire le contenu, il trouve kidRA dans l'en-tête PlayReady du manifeste du flux et demande une licence pour kidRA. Le serveur de licences retourne une licence racine pour la clé racine {kidRA, ckRA}. Ensuite, le client analyse le segment A1 et découvre l’ELS dans l’en-tête du segment. En analysant cet ELS, il trouve la licence feuille {kidA1, ckA1} dans cet ELS. À l’aide de la clé racine {kidRA, ckRA} et de la licence feuille {kidA1, ckA1}, elle peut obtenir la valeur de ckA1, et déchiffrer et afficher le segment A1. 

La fonctionnalité de rotation de clé évolutive PlayReady est extrêmement évolutive, car elle ne nécessite pas que les clients contactent le serveur de licences chaque fois que les clés de chiffrement sont modifiées. Il conserve le volume de demandes de licence au niveau le plus bas possible, car le client a simplement besoin d'une seule licence racine à partir du serveur de licences par flux ou piste. Cela permet aux clés de chiffrement de changer aussi fréquemment que chaque segment, généralement toutes les deux secondes si nécessaire. 

Voir aussi

Clés et identifiants de clés (KIDs)