Sécuriser la diffusion d'une vidéo en ligne : chiffrement, DRM, contrôle d'accès et filigrane

Une vidéo de formation interne, un webinaire réservé aux clients ou un cours payant ont un point commun : leur diffuseur veut qu’ils soient vus par certaines personnes, et par elles seules. Trois risques distincts menacent cet objectif. Le flux peut être intercepté pendant son transport, la vidéo peut être consultée par quelqu’un qui n’y a pas droit (un lien transféré, un lecteur intégré sur un autre site), et une personne autorisée peut la copier pour la rediffuser. Chaque protection répond à l’un de ces risques, aucune ne les couvre tous, et le dernier ne peut être que freiné et tracé.

La première version de cet article, publiée en janvier 2023, présentait une liste de techniques dont certaines avaient déjà disparu, comme les protocoles liés à Flash, et attribuait à d’autres une efficacité trop absolue. Cette version, réécrite le 20 octobre 2026 à partir des spécifications techniques, des documentations officielles et des textes juridiques, décrit pour chaque mesure la menace qu’elle couvre et ses limites, puis propose des combinaisons adaptées à la valeur du contenu.

Associer chaque protection à la menace qu’elle couvre

Le choix des protections commence par la question de savoir contre qui l’on protège la vidéo, car les trois risques appellent des réponses différentes :

• l’interception pendant le transport, sur un réseau wifi public ou un équipement réseau compromis, se traite par le chiffrement du canal (HTTPS) ;
• l’accès par une personne non autorisée se traite par l’authentification, les URL signées à durée limitée et le chiffrement des segments vidéo dont la clé n’est remise qu’aux spectateurs identifiés ;
• la redistribution par un spectateur autorisé se freine avec les systèmes de gestion des droits numériques (DRM), qui empêchent de récupérer un fichier lisible, et se trace avec un filigrane qui identifie la source d’une fuite.

Ce dernier risque n’a pas de parade complète. La spécification de protection des contenus publiée par MovieLabs, coentreprise de recherche à but non lucratif dont les recommandations s’adressent aux studios de cinéma, le reconnaît explicitement : l’enregistrement de l’écran avec une caméra ne peut pas être empêché, et seul le filigrane permet d’y répondre. Le niveau de protection se proportionne donc à la valeur du contenu et au préjudice qu’une fuite causerait, chaque couche ajoutant un coût et des contraintes pour les spectateurs légitimes.

Chiffrer le transport avec HTTPS

Sans chiffrement, un attaquant placé entre le spectateur et le serveur, par exemple sur un point d’accès wifi qu’il contrôle, peut lire et modifier le trafic : c’est l’attaque dite de l’homme du milieu (man-in-the-middle). HTTPS, c’est-à-dire HTTP transporté dans une connexion TLS, rend le flux illisible et infalsifiable pour cet intermédiaire, à condition que le navigateur vérifie le certificat du serveur. La version 1.3 de TLS est spécifiée depuis juillet 2026 par la RFC 9846, qui remplace la RFC 8446 de 2018, et l’ANSSI recommande dans son guide sur TLS de privilégier TLS 1.3 tout en acceptant TLS 1.2. L’en-tête HSTS (RFC 6797) permet en outre à un site de se déclarer accessible uniquement par une connexion sécurisée, ce qui empêche un attaquant de faire basculer le spectateur vers une version non chiffrée.

HTTPS protège le canal et non le contenu. Une fois arrivée chez le spectateur, la vidéo est déchiffrée par la couche TLS et redevient un fichier ordinaire, et toute personne qui connaît l’adresse du fichier peut l’obtenir par une connexion HTTPS tout aussi valide. HTTPS ne protège pas non plus contre un attaquant qui contrôle déjà le terminal, ni contre un utilisateur qui passe outre un avertissement de certificat. Il constitue la base indispensable de toute diffusion, sans suffire à en réserver l’accès.

Chiffrer les segments vidéo : HLS et Common Encryption

La diffusion en continu découpe aujourd’hui la vidéo en courts segments, décrits dans une liste de lecture que le lecteur parcourt : c’est le principe du protocole HLS d’Apple, publié comme RFC 8216, et de la norme MPEG-DASH (ISO/IEC 23009-1). La RFC 8216 prévoit trois méthodes pour la balise EXT-X-KEY : NONE, AES-128 et SAMPLE-AES. Avec AES-128, chaque segment est entièrement chiffré avec l’algorithme AES et une clé de 128 bits en mode CBC (notre article sur le chiffrement AES en détaille le fonctionnement).

La sécurité de ce dispositif tient entièrement à la remise de la clé. La liste de lecture indique une adresse (URI) à laquelle le lecteur télécharge la clé, et un serveur de clés qui la remet à quiconque connaît cette adresse annule la protection : le chiffrement ne sert que si ce serveur vérifie l’identité ou le jeton du demandeur. Même dans ce cas, la clé parvient au lecteur sous une forme utilisable, si bien qu’un spectateur autorisé et techniquement averti peut s’en servir pour reconstituer la vidéo. C’est la principale différence avec les DRM, qui confinent les clés dans un module protégé.

Pour éviter de produire une version chiffrée par système, la norme Common Encryption (ISO/IEC 23001-7) définit des formats de chiffrement communs qui permettent à plusieurs systèmes de DRM d’accéder au même fichier chiffré ; elle précise elle-même qu’elle ne définit pas de DRM. Elle prévoit plusieurs schémas, dont cenc (AES en mode compteur) et cbcs (AES en mode CBC avec un chiffrement partiel par motif). Le format CMAF (ISO/IEC 23000-19) organise de son côté les segments pour qu’un même jeu de fichiers serve à HLS et à DASH. La documentation d’Apple indique que HLS accepte les fichiers CMAF non chiffrés ou chiffrés avec le schéma cbcs, ce qui oriente le choix lorsqu’on veut un seul jeu de fichiers pour tous les appareils.

Les DRM et l’interface Encrypted Media Extensions

Un système de gestion des droits numériques (DRM) associe trois éléments : le contenu chiffré, un serveur de licences qui délivre les clés avec des règles d’usage (durée de validité, lecture hors ligne, restrictions de sortie), et un module de déchiffrement installé sur l’appareil, qui déchiffre la vidéo sans exposer la clé à l’application. Dans les navigateurs, ce module est appelé par l’interface Encrypted Media Extensions (EME), devenue une recommandation du W3C le 18 septembre 2017. EME définit une interface commune pour découvrir et utiliser ces systèmes, appelés Content Decryption Modules (CDM), et précise qu’elle ne définit elle-même aucun système de protection des contenus ni de DRM. La « norme DRM HTML5 » que citait la première version de cet article désignait en réalité cette interface.

Les éditeurs des principaux navigateurs et systèmes d’exploitation proposent chacun le leur :

• Widevine, que Google présente comme son système de protection des contenus pour les médias premium, repose sur EME et sur Common Encryption ; le tableau de compatibilité publié par Google l’indique comme non pris en charge par Safari sur ordinateur ;
• PlayReady, la technologie de Microsoft, gère selon sa documentation des dates d’expiration, des niveaux de sécurité et des restrictions de sortie ; son niveau SL3000 est réservé aux appareils dont la protection repose sur le matériel ;
• FairPlay Streaming, le système d’Apple, protège la diffusion par HLS sur les plateformes Apple ; le chiffrement par échantillon de HLS sur lequel il s’appuie correspond, selon Apple, au schéma cbcs de Common Encryption.

Atteindre l’ensemble des navigateurs et des appareils suppose donc de gérer plusieurs DRM à la fois, avec un serveur de licences pour chacun ou un service qui les regroupe. Le niveau de protection varie aussi selon l’appareil : Android distingue les terminaux où les clés et le déchiffrement sont traités dans un environnement d’exécution matériel de confiance et ceux où ils reposent sur une protection logicielle. Les restrictions de sortie complètent le dispositif : PlayReady peut par exemple n’envoyer l’image vers un port HDMI ou DisplayPort que si la protection HDCP y est active, ce qui empêche une capture directe par un enregistreur branché sur la sortie vidéo.

Les protocoles RTMPE et RTMFP, que la première version de cet article recommandait, étaient liés à Flash Player, qu’Adobe a cessé de prendre en charge le 31 décembre 2020 et dont il bloque l’exécution des contenus depuis le 12 janvier 2021.

En droit, les DRM relèvent des mesures techniques de protection. L’article 6 de la directive 2001/29/CE impose aux États membres une protection juridique contre le contournement des mesures techniques efficaces ; en France, l’article L. 331-5 du code de la propriété intellectuelle protège les mesures techniques efficaces, c’est-à-dire celles qui contrôlent l’usage d’une œuvre par un code d’accès, un procédé de protection comme le cryptage ou le brouillage, ou un mécanisme de contrôle de la copie ; il précise qu’un protocole, un format ou une méthode de cryptage ne constitue pas, en tant que tel, une mesure technique. L’article L. 335-3-1 punit de 3 750 euros d’amende le contournement délibéré d’une telle mesure et de six mois d’emprisonnement et 30 000 euros d’amende la fourniture de moyens de contournement, sauf pour les actes réalisés à des fins de sécurité informatique.

Contrôler qui accède à la vidéo

Le mot de passe partagé et l’authentification

Un mot de passe commun à tous les spectateurs est simple à mettre en place, mais il circule dès qu’il est transmis, il ne dit pas qui a regardé la vidéo, et le changer coupe l’accès à tout le monde. Pour un contenu interne, l’authentification des collaborateurs par le fournisseur d’identité de l’organisation est préférable : l’accès suit alors les arrivées et les départs, et chaque visionnage est rattaché à une personne.

Les URL signées et les jetons à durée limitée

Une fois le spectateur authentifié, l’application lui remet une adresse de lecture signée et valable peu de temps ; le réseau de diffusion de contenu (CDN) refuse toute requête dont la signature est absente, expirée ou invalide. Amazon CloudFront décrit ainsi des URL et des cookies signés qui portent une date et une heure d’expiration, et, avec une politique personnalisée, une adresse IP ou une plage d’adresses autorisées. La documentation de Cloudflare Stream rappelle qu’une vidéo y est visible par défaut par quiconque connaît son identifiant, et que les jetons signés, valables une heure par défaut, ne peuvent pas expirer plus de 24 heures après leur signature ; ils acceptent aussi des règles d’accès par adresse IP ou par pays.

Ces jetons rendent l’accès traçable, puisque chaque émission de jeton correspond à un utilisateur identifié, et limitent l’intérêt d’un lien transféré, qui expire rapidement. La clé de signature doit rester sur le serveur ; si elle fuit, n’importe qui peut fabriquer des adresses valides.

La restriction par site d’origine

Limiter la lecture aux pages d’un domaine donné repose sur l’en-tête HTTP Referer, que le navigateur envoie pour indiquer la page d’origine d’une requête. La RFC 9110, qui définit HTTP, note que certains serveurs utilisent cet en-tête pour refuser les liens provenant d’autres sites, mais que toutes les requêtes ne le contiennent pas : le navigateur peut le tronquer, des intermédiaires le suppriment, et la spécification Referrer Policy du W3C admet que l’utilisateur puisse le supprimer entièrement. Un serveur qui accepte les requêtes sans référent pour ne pas bloquer ces spectateurs laisse passer une requête directe, et un serveur qui les refuse écarte des spectateurs légitimes. Cette restriction empêche surtout l’intégration de la vidéo dans le lecteur d’un autre site ; elle ne remplace pas un contrôle d’accès.

La restriction géographique

Le filtrage par pays s’appuie sur la géolocalisation de l’adresse IP, approximative et contournable par un réseau privé virtuel (VPN). Il répond surtout aux contraintes de droits de diffusion par territoire. Le règlement (UE) 2018/302 sur le blocage géographique injustifié ne s’applique pas aux services audiovisuels, exclus de son champ par renvoi à la directive 2006/123/CE. En revanche, le règlement (UE) 2017/1128, applicable depuis le 20 mars 2018, oblige le fournisseur d’un service de contenu en ligne payant à permettre à un abonné présent temporairement dans un autre État membre d’y accéder : un filtrage géographique ne doit pas priver de leur service les abonnés européens en déplacement.

Identifier l’origine d’une fuite avec un filigrane

Un filigrane visible, comme le nom ou l’adresse électronique du spectateur incrusté dans l’image, dissuade la rediffusion d’une vidéo interne. Un filigrane invisible, dit médico-légal (forensic watermarking), insère dans l’image une marque imperceptible qui résiste à la recompression et permet, en analysant une copie trouvée en ligne, de retrouver le compte ou la session d’origine. La spécification de MovieLabs (version 1.4, août 2024) exige pour les contenus les plus précieux la capacité de marquer la vidéo de façon sécurisée, côté serveur ou côté client, et des tests de robustesse menés par un tiers. Le filigrane n’empêche pas la fuite ; il en identifie la source une fois la copie repérée.

Lorsqu’il contient l’identité du spectateur, le filigrane est un traitement de données personnelles. Le RGPD impose alors d’en informer les spectateurs (article 13) et de limiter les données incrustées à ce qui est nécessaire (principe de minimisation, article 5) : un identifiant de session suffit, et la géolocalisation que suggérait la première version de cet article n’a pas lieu d’y figurer. La correspondance entre marques et utilisateurs doit avoir une durée de conservation définie.

Une fois une copie repérée sur une plateforme, le Digital Services Act (règlement (UE) 2022/2065) oblige les hébergeurs à mettre en place un mécanisme permettant à tout particulier ou à toute entité de leur signaler un contenu illicite (article 16). Un signalement suffisamment précis leur donne connaissance du contenu au sens de l’article 6, ce qui les conduit à le retirer promptement pour conserver leur exemption de responsabilité.

Trois niveaux de protection selon la valeur du contenu

Pour une vidéo de formation ou de communication interne, l’enjeu est d’éviter qu’elle circule hors de l’organisation. HTTPS, l’authentification par le fournisseur d’identité de l’entreprise et des URL signées de courte durée y suffisent dans la plupart des cas, complétés par un filigrane visible portant le nom du spectateur. Les DRM y apportent peu, au regard de leur coût et des difficultés de compatibilité qu’ils créent sur les postes de travail.

Pour un cours ou un webinaire payant, la perte de revenus justifie une couche de plus. Le chiffrement des segments en AES-128 avec un serveur de clés placé derrière l’authentification empêche la récupération directe des fichiers, la limitation du nombre de sessions simultanées par compte freine le partage d’identifiants, et un filigrane invisible devient utile dès que des copies apparaissent en ligne.

Pour un contenu de grande valeur, comme une avant-première ou des droits sportifs, la protection passe par plusieurs DRM appelés par EME (Widevine, PlayReady, FairPlay Streaming), un niveau de sécurité matériel et la protection HDCP des sorties pour la haute définition, un filigrane médico-légal et une surveillance des plateformes suivie de signalements. Dans les trois cas, la journalisation des accès et des émissions de jetons fournit la trace qui permettra de comprendre une fuite ; notre article sur la gestion de la sécurité des données replace ces mesures dans une politique de sécurité d’ensemble.

Sources et références 28 sources

Normes et spécifications

1. [1] W3C - Encrypted Media Extensions, recommandation du 18 septembre 2017
2. [2] RFC 8216 - HTTP Live Streaming (août 2017)
3. [3] RFC 9846 - The Transport Layer Security (TLS) Protocol Version 1.3 (juillet 2026)
4. [4] RFC 6797 - HTTP Strict Transport Security (HSTS)
5. [5] RFC 9110 - HTTP Semantics, section 10.1.3 (Referer)
6. [6] W3C - Referrer Policy
7. [7] ISO/IEC 23001-7:2023 - Common encryption in ISO base media file format files
8. [8] ISO/IEC 23000-19:2024 - Common media application format (CMAF) for segmented media
9. [9] MovieLabs - Specification for Enhanced Content Protection, version 1.4 (août 2024)

Documentation des éditeurs

1. [10] Apple - FairPlay Streaming
2. [11] Apple - Using content protection systems with HLS
3. [12] Apple - About the Common Media Application Format with HTTP Live Streaming
4. [13] Google - Widevine DRM overview
5. [14] Microsoft - PlayReady overview
6. [15] Microsoft - PlayReady security levels
7. [16] Microsoft - PlayReady output protection levels
8. [17] Android - MediaDrm (niveaux de sécurité matériel et logiciel)
9. [18] Adobe - Flash Player end of life
10. [19] Amazon CloudFront - Serve private content with signed URLs and signed cookies
11. [20] Cloudflare Stream - Secure your Stream

ANSSI

1. [21] Recommandations de sécurité relatives à TLS, version 1.2 (26 mars 2020)

Textes juridiques

1. [22] Légifrance - Article L. 331-5 du code de la propriété intellectuelle (mesures techniques de protection)
2. [23] Légifrance - Article L. 335-3-1 du code de la propriété intellectuelle (contournement)
3. [24] Directive 2001/29/CE sur le droit d'auteur dans la société de l'information
4. [25] Règlement (UE) 2017/1128 relatif à la portabilité transfrontière des services de contenu en ligne
5. [26] Règlement (UE) 2018/302 visant à contrer le blocage géographique injustifié
6. [27] Règlement (UE) 2022/2065 (Digital Services Act)
7. [28] Règlement (UE) 2016/679 (RGPD)