Entrée glossaire · Chiffrement

AES-128 (Chiffrement des flux HLS)

Le chiffrement le plus couramment utilisé pour protéger les segments HLS. Léger, facile à déployer, et ce n'est pas du DRM. AES-128 protège du scraping occasionnel mais pas d'un client déterminé qui possède la clé.

Définition

AES (Advanced Encryption Standard) est un chiffrement par blocs symétrique standardisé en 2001 par le NIST sous la référence FIPS 197. Le nombre 128 spécifie la longueur de la clé en bits. AES-128 est la longueur de clé par défaut prise en charge par le chiffrement et est largement considéré comme sûr pour la protection de données généraliste.

Quand la spécification HLS mentionne AES-128, elle fait référence à une construction très précise : AES-128 en mode CBC avec un vecteur d'initialisation de 16 octets et un padding PKCS#7 appliqué à chaque segment. La mécanique complète est décrite dans la section 4.3.2.4 du RFC 8216.

Comment AES-128 protège les segments HLS

Le modèle de protection est direct. Chaque segment .ts ou .m4s d'une media playlist est chiffré indépendamment. Le chiffrement est appliqué à la totalité des octets du segment avant qu'ils soient écrits sur le disque du serveur d'origine. Le segment chiffré est ce que le CDN met en cache et ce qu'un client télécharge. Le déchiffrement a lieu à l'intérieur du lecteur après que le segment a fini de se télécharger et avant qu'il soit poussé au décodeur.

La clé n'est pas embarquée dans le segment. La playlist référence la clé via un attribut URI, et le lecteur récupère la clé avec une requête HTTP normale. Le contrôle d'accès est appliqué par le serveur qui héberge la clé : un token, une URL signée ou un cookie de session protège typiquement le téléchargement de la clé. Cette séparation est tout le modèle de sécurité. Si l'URL de la clé n'est pas protégée, quiconque lit la playlist peut déchiffrer le flux.

La balise EXT-X-KEY et le format du fichier clé

La balise EXT-X-KEY apparaît dans la media playlist avant les segments auxquels elle s'applique. Une déclaration typique ressemble à ceci :

#EXT-X-KEY:METHOD=AES-128,URI="https://example.com/keys/master.key",IV=0x00000000000000000000000000000001

Les attributs se décomposent ainsi :

METHOD : la méthode de chiffrement. La seule valeur pratique ici est AES-128. NONE signifie que les segments suivants ne sont pas chiffrés, ce qui permet aux playlists de basculer entre des plages chiffrées et en clair.
URI : l'URL absolue ou relative du fichier clé. Le fichier clé est un fichier binaire contenant exactement 16 octets, la clé AES brute. Pas d'en-tête, pas de JSON, pas de base64. Juste les octets.
IV : le vecteur d'initialisation pour le mode CBC, exprimé en chaîne hexa de 32 caractères préfixée par 0x. Optionnel ; s'il est omis, le lecteur dérive l'IV du numéro de séquence du segment.
KEYFORMAT : identifie le système de clés. Vaut identity par défaut (la simple clé binaire décrite plus haut). D'autres valeurs comme com.apple.streamingkeydelivery indiquent un DRM FairPlay et requièrent un échange avec un serveur de licences.

Quand un lecteur rencontre une balise EXT-X-KEY, il récupère le fichier clé une fois (mis en cache pour le reste de la session par défaut) puis déchiffre chaque segment suivant avec cette clé jusqu'à ce qu'une autre balise EXT-X-KEY la remplace.

Mode CBC et IV

AES en mode Cipher Block Chaining (CBC) chiffre les données par blocs de 16 octets. Chaque bloc est combiné par XOR avec le chiffré du bloc précédent avant chiffrement. Le tout premier bloc n'a pas de chiffré précédent, il est donc combiné par XOR avec un vecteur d'initialisation à la place.

Pour HLS, l'IV est soit déclaré explicitement dans la playlist, soit dérivé implicitement comme la représentation big-endian sur 16 octets du numéro de séquence média du segment. La dérivation implicite a la propriété pratique que chaque segment utilise un IV unique sans que la playlist ait à le spécifier pour chaque segment.

Le padding PKCS#7 est appliqué pour que la longueur du segment devienne un multiple de 16 octets. Le décodeur retire le padding après déchiffrement. Si vous tentez de déchiffrer un segment HLS à la main et que le résultat est corrompu, la gestion du padding est généralement le bug.

Limites face au DRM (pas de Widevine)

AES-128 dans HLS est du chiffrement, pas du DRM. La différence tient à l'application. Un système DRM comme Widevine, PlayReady ou FairPlay s'appuie sur un environnement d'exécution de confiance sur l'appareil client : une puce ou un module noyau qui manipule la clé de déchiffrement sans jamais l'exposer à du code applicatif ordinaire. L'échange de licence est signé par des certificats enracinés dans le matériel.

AES-128 simple n'a rien de tout cela. La clé est un fichier plat de 16 octets récupéré en HTTP. Si un client a la permission de lire la vidéo, il peut lire la clé en mémoire et déchiffrer les segments. C'est pour cela qu'AES-128 est acceptable pour les plateformes de cours avec accès payant (le coût du vol est supérieur à celui de l'achat d'accès) mais inadéquat pour le contenu Hollywood premium qui exige une protection de niveau DRM.

En pratique, si votre playlist HLS utilise METHOD=AES-128 et une URL de clé que vous pouvez récupérer, un outil comme Vidora peut déchiffrer et télécharger le flux. Notre walkthrough orienté action sur le téléchargement d'un M3U8 chiffré couvre le workflow utilisateur final. Si la playlist utilise plutôt METHOD=SAMPLE-AES avec un keyformat FairPlay ou si vous voyez des boîtes PSSH Widevine dans un manifeste DASH, vous avez croisé du DRM et les outils grand public ne peuvent pas aider.