Empaquetage et livraison de contenu

La fonctionnalité de base de PlayReady consiste à protéger le contenu contre toute 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 si aucun autre élément n’est fourni et tous les attributs personnalisés.  

Tout packager qui empaquet le contenu clair doit implémenter un générateur d’en-tête PlayReady pour générer l’en-tête et l’incorporer dans le contenu chiffré. L’en-tête PlayReady doit être implémenté conformément à 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 cette fonctionnalité, 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), HEVC (High Efficiency Video Coding) H.265 et av1 standard. 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 packager 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 plutôt 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 travailler avec n’importe quel type de chiffreur open source (par exemple ffmpeg). En outre, vous pouvez travailler avec une entreprise d’encodeur professionnel si vous souhaitez chiffrer du contenu avec PlayReady (par exemple, Harmonique, Elemental, Ericsson, Wowza, Allegro). Azure Media Services fournit également une fonctionnalité d’empaquetage pour le contenu clair.

Utilisation des outils de chiffrement

PlayReady prend en charge la norme de chiffrement commune ISO IEC. Ce processus est identique à celui décrit dans le processus de chiffrement et de licence de base, à l’exception des en-têtes inclus pour d’autres drMS , chacun comme charge utile de la zone d’en-tête spécifique du système de protection ('pssh'), identifié par le SystemID de cette DRM. Tous ces en-têtes auront leur propre syntaxe qui désigne les KID ou les informations nécessaires pour accéder finalement aux clés de contenu. Et les clés de contenu de cette ressource vont être identiques pour toutes les machines virtuelles de récupération d’urgence.

Utilisation de clés de chiffrement

Il existe de nombreuses façons de chiffrer vos ressources. Le plus simple à celui le plus sophistiqué dépend de la complexité que vous souhaitez concevoir dans le système et quels sont les 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 servie dans plusieurs formats en fonction de ce que le client préférerait lire. 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, en fonction des contraintes de la 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 continu 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 tout (en général, les sous-titres ne sont pas chiffrés , ce n’est pas contre une règle, mais ils sont généralement conservés dans l’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é est généralement acquise par le client avant la lecture.

Chiffrement de la ressource avec deux clés, dédicant une à la meilleure qualité

Au cours des dernières années, certaines améliorations ont été apporté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 était nécessaire par les studios et les services d’autoriser la qualité la plus élevée uniquement sur certains clients, qui ont généralement une gestion des droits numériques matériel intégrée. 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 clé de contenu différente {kid2, ck2}. Plus précisément :

• Un client autorisé à jouer uniquement jusqu’à Full HD (pas la piste 4K) sera remis une licence PlayReady incluant uniquement {kid1, ck1}. 
• Un client autorisé à jouer jusqu’à 4K sera remis 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 le suivi 4K et que le suivi 4K peut être réservé uniquement aux clients que le service approuve le plus. 

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é à jouer uniquement à 720p sera remis une licence PlayReady incluant {kid1, ck1}, {kid2, ck2} et {kidA, ckA}. 
• Un client autorisé à jouer jusqu’à 4K sera remis une licence PlayReady incluant {kid1, ck1}, {kid2, ck2}, {kid3, ck3}, {kid4, ck4}, et {kidA, ckA}. 
• Un client jouant hors connexion de la version 4K de la ressource (précédemment téléchargée) sera remis une licence PlayReady, y compris {kid4, ck4} et {kidA, ckA}. 

Modification périodique des clés de chiffrement (ressource multi-période) : 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 comporte 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 d’air gratuites {KIDi1, CKi1} à tous les utilisateurs sans aucune restriction, et de remettre les clés de contenu {kidi2, cki2} uniquement aux abonnés qui ont correctement connecté le 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 la clé racine {kidRA, ckRA}. Si vous êtes familiarisé avec MPEG-2 TS et le chiffrement Word de contrôle, il s’agit d’un mécanisme similaire, à l’exception du chiffrement est beaucoup plus fort et est également plus flexible.

Supposons que cette ressource soit une télévision linéaire en direct. Lorsque le client tente de lire, il trouve kidRA dans l’en-tête PlayReady du manifeste de 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. L’analyse de cet ELS 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 plus bas possible, car un client n’a besoin qu’d’une licence racine à partir du serveur de licences par flux ou d’un suivi. Il permet aux clés de chiffrement de faire pivoter aussi fréquemment que chaque segment, généralement toutes les deux secondes si nécessaire. 

Voir aussi

ID de clé et de clé (KID)