Qu’est-ce que le chiffrement DRM ?

Le chiffrement DRM transforme les médias encodés en données chiffrées qu’un lecteur ne peut déchiffrer qu’avec la clé de contenu correspondante. Un système de licences transmet cette clé et ses règles d’utilisation aux clients qu’il autorise.

Le chiffrement est appliqué par l’outil de conditionnement, après l’encodage. Avec Common Encryption (ISO/IEC 23001-7), utilisé par les flux MP4 fragmentés pour DASH et HLS, les échantillons chiffrés utilisent une clé AES de 128 bits selon l’un des quatre schémas de la norme ; les deux schémas autorisés par le format de flux du W3C pour Encrypted Media Extensions sont cenc (mode compteur) et cbcs (chaînage des blocs chiffrés, avec un motif qui ne chiffre qu’une partie de chaque échantillon vidéo). Un flux protégé peut aussi contenir des échantillons non chiffrés, par exemple une portion initiale en clair. Le média n’expose pas la clé de contenu en clair. Il contient un identifiant de clé, par défaut dans la boîte de chiffrement de piste (tenc). Pour demander une licence, le client d’un système DRM a besoin des données d’initialisation de ce système, dont l’emplacement dépend du format de diffusion. Pour DASH, le DASH-IF décrit un en-tête spécifique à chaque système de protection (pssh), présent dans le média, dans le manifeste sous forme d’élément cenc:pssh, ou dans les deux ; le manifeste indique aussi l’identifiant de clé sous la forme cenc:default_KID. Une liste de lecture HLS signale les clés dans des balises EXT-X-KEY, dont l’attribut URI précise comment obtenir la clé ; le contenu FairPlay doit utiliser le format de clé com.apple.streamingkeydelivery dans cette balise. Le lecteur transmet les données d’initialisation au module de déchiffrement de contenu de l’appareil, relaie la demande de licence du module au service de licences, puis renvoie la licence au module ; le déchiffrement s’effectue ensuite à l’intérieur du module. Les échantillons sont chiffrés une seule fois et seule la licence est émise pour chaque client ; chaque spectateur télécharge donc les mêmes segments chiffrés, qui peuvent être partagés et mis en cache comme des segments non chiffrés.

cenc ou cbcs ? Les deux schémas ne sont pas interchangeables, et un appareil doit prendre en charge celui utilisé pour conditionner le contenu. Le contenu FairPlay doit utiliser la méthode HLS SAMPLE-AES, que la RFC 8216 définit pour le MP4 fragmenté comme le schéma cbcs, et la spécification de création de contenu d’Apple stipule que SAMPLE-AES-CTR ne doit pas être utilisé sur les appareils Apple. La RFC 8216 ne définit aucune méthode en mode compteur, mais la documentation Media3 d’Android répertorie le HLS en MP4 fragmenté comme format pris en charge pour Widevine avec cenc et, sur Android TV, pour PlayReady avec cenc. Cette même documentation indique la prise en charge de Widevine avec cenc à partir d’Android 4.4, mais avec cbcs seulement à partir d’Android 7.1 (le tableau des plateformes de Widevine indique Android 7.x et versions ultérieures), et PlayReady a ajouté cbcs dans la version 4.0 du client, où sa prise en charge reste facultative. Une seule copie en cbcs peut donc servir aux clients FairPlay, Widevine et PlayReady qui prennent en charge ce schéma, ce qu’un numéro de version PlayReady 4.0 ne garantit pas à lui seul, et les anciens clients Android ou PlayReady ont besoin d’une seconde copie en cenc. Si vous conditionnez le contenu dans les deux schémas, Microsoft précise qu’un service ne doit pas chiffrer le même contenu dans les deux modes avec le même identifiant de clé et la même clé.
L’identifiant de clé est-il secret, et à quoi doit-il correspondre ? Non, c’est une étiquette. L’identifiant de clé est transmis sans chiffrement dans la boîte tenc, dans les données pssh et dans les manifestes DASH, et indique au client et au service de licences quelle clé est nécessaire ; seule la clé elle-même est secrète et elle est transmise au sein d’une licence. Les identifiants doivent correspondre à tous les niveaux : le DASH-IF exige que la valeur cenc:default_KID du manifeste corresponde à celle de la boîte tenc, qu’il considère comme la source de vérité, et une licence qui fournit une clé sous un identifiant différent laisse les échantillons impossibles à déchiffrer, même si le flux se charge.
Une seule copie chiffrée fonctionne-t-elle avec plusieurs systèmes DRM ? Oui, pour les systèmes qui prennent en charge le schéma utilisé : Common Encryption permet à plusieurs systèmes de clés de déchiffrer les mêmes médias. Chaque système a néanmoins besoin de sa propre signalisation et d’un service de licences capable de renvoyer la même clé. Les outils de conditionnement génèrent cette signalisation pour chaque système ; Shaka Packager, par exemple, peut produire la signalisation Widevine, PlayReady et FairPlay pour un seul ensemble de clés. L’emplacement de la signalisation compte pour les navigateurs : le DASH-IF déconseille les boîtes pssh dans les segments d’initialisation, car chaque boîte traitée par un navigateur peut déclencher une nouvelle demande de licence, sauf si le lecteur détecte et bloque les doublons, et précise qu’inclure les données pssh dans le manifeste permet d’ajouter un système DRM sans modifier le contenu.
Quand la rotation des clés justifie-t-elle sa complexité ? Le DASH-IF décrit son objectif principal comme l’obligation d’obtenir périodiquement une nouvelle autorisation pour les contenus diffusés en direct en continu, par exemple aux changements de programme, et précise explicitement que le but n’est pas de renforcer le chiffrement. Dans Common Encryption, les identifiants de clé changeants sont signalés pour chaque échantillon au moyen de groupes d’échantillons seig, éventuellement accompagnés de données de licence dans des boîtes pssh à l’intérieur des fragments vidéo ; en HLS, chaque balise EXT-X-KEY s’applique aux segments qui la suivent jusqu’à la prochaine balise ayant le même KEYFORMAT ou jusqu’à la fin de la liste de lecture. La rotation nécessite une prise en charge par le lecteur (Media3 d’Android exige son mode multisession pour les flux à rotation de clés), des changements de clé alignés sur les limites des segments et des demandes de licence réparties dans le temps pour éviter que tous les clients ne les envoient au même instant. Le DASH-IF décrit une méthode de répartition qui en confie la responsabilité au système DRM : les clés actuelles et à venir sont annoncées dans les données pssh, et chaque client choisit un instant aléatoire pour demander sa licence.

Configurez le chiffrement lors du conditionnement des flux destinés à une lecture contrôlée et protégez les clés séparément. Un identifiant de clé, un schéma ou une configuration de licence qui ne correspond pas rend illisibles des médias pourtant correctement encodés.

Qu’est-ce que le chiffrement DRM ?

Comment fonctionne le chiffrement DRM

Points clés

Quand le chiffrement DRM est important

Références

Transformer vos connaissances sur les médias en une chaîne de traitement opérationnelle