TRAITEMENT NUMERIQUE ET INFORMATIQUE DES SIGNAUX (partie 3/3)

## Objectifs et prérequis **Objectifs** : À la fin de ce chapitre, l’élève sera capable de : - Définir un codec audiovisuel et expliquer son rôle dans la compression/décompression des signaux numériques. - Identifier les principaux conteneurs (MKV, MP4, MOV, TS) et leurs caractéristiques techniques. - Comparer les codecs sans perte et avec perte selon les critères de qualité, de débit et d’usage professionnel. - Réaliser le dimensionnement d’un flux vidéo en fonction de la résolution, du taux de rafraîchissement, de la profondeur de couleur et du taux de compression. - Expliquer les principes du chiffrement symétrique et asymétrique appliqués à l’audiovisuel. - Mettre en œuvre un protocole de chiffrement/déchiffrement simple (AES‑128, RSA‑2048) sur un fichier multimédia. - Appliquer les règles de sécurité liées à la manipulation de clés cryptographiques et au transfert de contenus protégés. **Prérequis** : - Notions de base du signal numérique (échantillonnage, quantification, codage PCM). - Connaissances des formats d’image numérique (RGB, YUV, sous‑échantillonnage 4:2:0). - Notions de réseaux informatiques (adressage IP, protocole TCP/UDP). - Maîtrise du tableur ou d’un langage de script simple (Python, Bash) pour réaliser des calculs. --- ## Introduction contextualisée Au Cameroun, la diffusion de contenus audiovisuels numériques connaît une croissance soutenue grâce à l’essor de la télévision numérique terrestre (TNT), du streaming en ligne et de la production locale de films et de programmes éducatifs. Les techniciens de l’audiovisuel doivent maîtriser la chaîne complète allant de l’acquisition du signal à sa diffusion, en passant par la compression (codecs), l’encapsulation (conteneurs) et la protection du contenu (chiffrement). Une mauvaise maîtrise de ces étapes entraîne soit une perte de qualité perceptible, soit un dépassement de la bande passante disponible, soit une vulnérabilité aux copies illicites. Ce chapitre propose donc une approche professionnelle, ancrée dans des situations réelles rencontrées dans les studios de Yaoundé, les chaînes de télévision de Douala ou les prestataires de services de vidéo‑à‑la‑demande (VAD). --- ## I. Codecs et Conteneurs audiovisuels ### A. Définitions et rôle des codecs > **Codec** : dispositif (matériel ou logiciel) qui code (encode) un signal audiovisuel brut pour le réduire en taille et qui le décodifie (décompresse) pour la restitution. Un codec opère en deux étapes : 1. **Analyse** du signal pour exploiter les redondances spatiales (dans l’image) et temporelles (entre les images). 2. **Quantification** et **entropie** (codage de Huffman, arithmétique, CABAC) pour représenter l’information avec le moins de bits possible tout en respectant un niveau de qualité cible. Les codecs se classent en deux familles : - **Sans perte** (ex. : FFV1, Apple ProRes 422 HQ) : le signal décodé est identique à l’original ; utilisé en post‑production et archivage. - **Avec perte** (ex. : H.264/AVC, H.265/HEVC, AV1, VP9) : certaines informations sont sacrifiées pour atteindre un débit nettement inférieur ; utilisé en diffusion, streaming et visioconférence. ### B. Principaux paramètres d’un codec | Paramètre | Symbole | Unité | Influence sur la qualité / débit | |-----------|---------|-------|-----------------------------------| | Résolution spatiale | \(R_x \times R_y\) | pixels | Plus la résolution est élevée, plus le débit brut augmente. | | Taux de rafraîchissement | \(F\) | images/s (fps) | Augmente linéairement le débit brut. | | Profondeur de couleur | \(C\) | bits par canal (ex. 8, 10) | Débit brut ∝ \(C\). | | Sous‑échantillonnage chroma | \(4:2:0, 4:2:2, 4:4:4\) | – | Réduit le débit chromatique sans perte perceptible importante. | | Ratio de compression | \(CR\) | – (sans unité) | Débit net = débit brut / \(CR\). Une \(CR\) élevée diminue la qualité si le codec est avec perte. | | Débit binaire (bitrate) | \(B\) | bits/s | \(B = \dfrac{R_x \times R_y \times F \times C \times (1 + \text{overhead chroma})}{CR}\). | > **Formule du débit brut (avant compression)** : \[ B_{\text{brut}} = R_x \times R_y \times F \times C \times (1 + \alpha) \] où \(\alpha\) représente le facteur de surcharge chromatique (2 pour 4:4:4, 1 pour 4:2:2, 0.5 pour 4:2:0). ### C. Exemple chiffré de dimensionnement **Situation** : Un technicien doit préparer un flux pour la diffusion en TNT camerounaise (bande passante allouée : 6 Mbps). Il choisit une résolution Full HD (1920 × 1080), 25 fps, profondeur 8 bits, sous‑échantillonnage 4:2:0 et le codec H.264 avec un taux de compression cible de 50. 1. Calcul du débit brut : \[ B_{\text{brut}} = 1920 \times 1080 \times 25 \times 8 \times (1 + 0.5) = 1920 \times 1080 \times 25 \times 8 \times 1.5 \] \[ = 1920 \times 1080 \times 300 = 622\,080\,000\ \text{bits/s} \approx 622\ \text{Mbps} \] 2. Débit net après compression : \[ B_{\text{net}} = \dfrac{B_{\text{brut}}}{CR} = \dfrac{622\ \text{Mbps}}{50} \approx 12,44\ \text{Mbps} \] Le résultat dépasse la bande disponible (6 Mbps). Il faut donc soit réduire la résolution (ex. 1280 × 720), soit diminuer le taux de rafraîchissement (ex. 15 fps), soit augmenter le taux de compression (ex. CR = 100) ou choisir un codec plus efficace (H.265/HEVC, CR ≈ 200). > **Règle de métier** : En TNT, on vise généralement un débit net entre 2 et 4 Mbps pour du HD avec H.264, en laissant une marge pour les tables de service et le multiplexage. ### D. Les conteneurs (formats de fichier) Un **conteneur** encapsule un ou plusieurs flux (vidéo, audio, sous‑titres, métadonnées) ainsi que des informations de synchronisation (time‑codes, index). Il ne compresse pas les flux ; il les organise pour la lecture ou le transport. | Conteneur | Extension | Flux supportés | Particularités professionnelles | |-----------|-----------|----------------|---------------------------------| | MP4 | .mp4 | Vidéo (H.264, H.265, AV1), Audio (AAC, MP3), Sous‑titres | Large compatibilité (web, mobile, TNT). Streaming adaptatif (DASH, HLS). | | MKV | .mkv | Vidéo (tous codecs), Audio (FLAC, Opus, DTS), Sous‑titres, Chapitres | Idéal pour l’archivage et la post‑production (support de pistes multiples, métadonnées étendues). | | MOV | .mov | Vidéo (ProRes, DNxHD), Audio (PCM, AAC) | Format natif d’Apple QuickTime, utilisé en montage professionnel sur macOS. | | TS | .ts | Vidéo (MPEG‑2, H.264), Audio (AC‑3, AAC), Tables de service | Stream de transport pour la diffusion TNT, satellite et IPTV. | | WebM | .webm | Vidéo (VP8, VP9, AV1), Audio (Opus) | Optimisé pour le web, royalties libres. | > **À retenir** : Le choix du conteneur dépend du canal de diffusion (web, broadcast, archivage) et des exigences de métadonnées (chapitre, langues, DRM). ### E. Normes et bonnes pratiques au Cameroun - **NTSC/PAL** : La TNT camerounaise utilise le standard PAL‑B/G (625 lignes, 50 Hz). Les paramètres de résolution et de taux de rafraîchissement doivent respecter ce cadre. - **Débit maximal autorisé** : Selon l’ARTC (Agence de Régulation des Télécommunications du Cameroun), le multiplex TNT ne doit pas dépasser 24 Mbps par fréquence ; chaque service vidéo se voit généralement attribuer entre 2 et 6 Mbps. - **Sécurité du contenu** : Les diffuseurs doivent appliquer le système de condition d’accès (CA) basé sur la norme DVB‑CI (Common Interface) lorsqu’ils souhaitent protéger leurs chaînes payantes. --- ## II. Cryptage et décryptage appliquée à l’audiovisuel ### A. Principes généraux du chiffrement de contenus multimédia > **Chiffrement** : opération qui transforme un texte clair (ici un flux audiovisuel) en texte chiffré à l’aide d’une clé secrète ou d’un paire de clés, rendant le contenu illisible sans la clé appropriée. > **Déchiffrement** : opération inverse qui restitue le texte clair à partir du texte chiffré et de la clé. Dans le domaine audiovisuel, on chiffre généralement : - Le **flux vidéo** (ou chaque trame I/P/B) pour empêcher la copie directe. - Le **flux audio** lorsqu’il contient des pistes à valeur commerciale (ex. : bandes‑son de films). - Les **métadonnées de gestion des droits** (DRM) qui indiquent les conditions d’utilisation (nombre de vues, durée de location, zone géographique). Deux familles de chiffrement sont utilisées : | Type | Algorithme exemplaire | Clé | Usage typique | |------|----------------------|-----|---------------| | Symétrique | AES‑128, AES‑256 | Même clé pour chiffrement et déchiffrement | Chiffrement de flux en temps réel (ex. : AES‑CBC, AES‑CTR) dans les systèmes de condition d’accès DVB‑CI. | | Asymétrique | RSA‑2048, ECC‑256 | Paire clé publique / clé privée | Échange sécurisé de la clé de session (ex. : handshake TLS, gestion de licences DRM). | ### B. Chiffrement symétrique – AES en mode CTR (exemple pratique) Le mode **CTR** (Counter) transforme un bloc chiffré en un flux de clés pseudo‑aléatoires qui sont XORées avec le texte clair. Il permet le traitement parallèle et la récupération en cas de perte de paquets. **Étapes de chiffrement d’un fichier vidéo MP4 avec AES‑128/CTR** : 1. Générer une clé secrète \(K\) de 128 bits (16 octets) aléatoirement (ex. : via `/dev/urandom`). 2. Choisir un nonce (valeur d’initialisation) \(N\) de 96 bits, unique pour chaque fichier. 3. Pour chaque bloc de 128 bits du flux vidéo : - Calculer le compteur \(C = N \parallel \text{bloc\_index}\) (concaténation). - Chiffrer \(C\) avec AES‑128 sous la clé \(K\) → \(S = \text{AES}_{K}(C)\). - XORer le bloc clair \(P\) avec \(S\) pour obtenir le bloc chiffré \(Cipher = P \oplus S\). 4. Stocker le nonce \(N\) en tête du fichier (non secret) et écrire les blocs chiffrés séquentiellement. > **À retenir** : La sécurité d’AES dépend uniquement de la secrète de la clé ; le nonce peut être public mais ne doit jamais être réutilisé avec la même clé. ### C. Chiffrement asymétrique – échange de clé de session avec RSA Dans un système de location de vidéo (VOD), le serveur possède une paire de clés RSA \((e, n)\) publique et \((d, n)\) privée. Le client, souhaitant louer un film, procède ainsi : 1. Le serveur envoie sa clé publique \((e, n)\) au client. 2. Le client génère une clé de session aléatoire \(K_{sess}\) (128 bits) pour AES. 3. Il chiffre \(K_{sess}\) avec la clé publique du serveur : \[ C = K_{sess}^{e} \bmod n \] 4. Le client transmet \(C\) au serveur. 5. Le serveur déchiffre avec sa clé privée : \[ K_{sess} = C^{d} \bmod n \] 6. Dès lors, serveur et client utilisent \(K_{sess}\) pour chiffrer/déchiffrer le flux vidéo via AES‑128/CTR. > **À retenir** : RSA assure la confidentialité de l’échange de la clé symétrique ; la taille de la clé RSA (2048 bits actuellement recommandée) doit être suffisante pour résister aux attaques par factorisation. ### D. Exemple chiffré complet (calcul de la taille du fichier chiffré) **Données** : Un film de 2 h, encodé en H.264 avec un débit vidéo moyen de 3 Mbps et un débit audio de 128 kbps. Le fichier source (non chiffré) fait donc : \[ \text{Taille}_{\text{source}} = (3\ \text{Mbps} + 0,128\ \text{Mbps}) \times 2\ \text{h} \times 3600\ \text{s/h} \] \[ = 3,128\ \text{Mbps} \times 7200\ \text{s} = 22\,521,6\ \text{Mb} \approx 2,815\ \text{Go} \] Après chiffrement AES‑128/CTR, chaque bloc de 16 octets reste de 16 octets (le chiffrement ne change pas la taille). On ajoute uniquement le nonce (12 octets) en tête de fichier. \[ \text{Taille}_{\text{chiffré}} = \text{Taille}_{\text{source}} + 12\ \text{octets} \approx 2,815\ \text{Go} + 0,000011\ \text{Go} \approx 2,815\ \text{Go} \] > **Conclusion** : Le chiffrement symétrique n’ajoute pratiquement aucune overhead de taille ; l’overhead provient surtout du conteneur, des métadonnées DRM et éventuellement du padding nécessaire pour aligner les blocs. ### E. Normes de sécurité et bonnes pratiques au Cameroun - **Loi n° 2010/012 du 21 décembre 2010** portant sur la cybercriminalité : interdit le contournement des mesures techniques de protection (DRM) sans autorisation. - **Norme DVB‑CI** : utilisée par les opérateurs de TNT pour insérer des modules de condition d’accès (CAM) dans les récepteurs. - **Gestion des clés** : les clés de chiffrement doivent être stockées dans un HSM (Hardware Security Module) ou un coffre‑fort logique conforme à la norme ISO 27001. - **Rotation des clés** : dans un système de VOD, la clé de session doit être renouvelée toutes les 2 à 4 heures pour limiter l’impact d’une éventuelle compromission. - **Contrôle d’intégrité** : on ajoute souvent un HMAC‑SHA‑256 sur le flux chiffré afin de détecter toute altération (attaque de type « bit‑flipping »). --- ## Synthèse du chapitre - **Codecs** : algorithmes de compression/décompression (sans perte : FFV1, ProRes ; avec perte : H.264, H.265, AV1). - **Paramètres clés** : résolution, fps, profondeur de couleur, sous‑échantillonnage chroma, taux de compression → débit net \(B = \dfrac{R_xR_yFC(1+\alpha)}{CR}\). - **Conteneurs** : MP4, MKV, MOV, TS, WebM ; ils encapsulent flux et métadonnées sans les compresser. - **Choix professionnel** : adapter débit, résolution et codec à la bande passante disponible (ex. TNT : 2‑4 Mbps HD avec H.264). - **Chiffrement** : symétrique (AES‑128/256, modes CBC/CTR/GCM) pour le flux ; asymétrique (RSA/ECC) pour l’échange de clés de session. - **Procédé de chiffrement AES‑CTR** : génération de clé secrète, nonce unique, XOR du texte clair avec le bloc chiffré du compteur. - **Échange de clé RSA** : client chiffre une clé AES avec la clé publique du serveur ; serveur la déchiffre avec sa clé privée. - **Sécurité** : stockage des clés dans HSM, rotation régulière, contrôle d’intégrité (HMAC), respect de la législation camerounaise sur la cybercriminalité et des normes DVB‑CI. - **Overhead de taille** : négligeable pour le chiffrement symétrique ; principale augmentation provient du conteneur, du nonce et des métadonnées DRM. --- ## Glossaire - **Codec** : dispositif qui code (encode) puis décodifie un signal audiovisuel pour réduire sa taille. - **Conteneur** : format de fichier qui encapsule un ou plusieurs flux (vidéo, audio, sous‑titres) ainsi que des métadonnées de synchronisation. - **Débit binaire (bitrate)** : quantité de bits transmise par seconde, notée \(B\) (bits/s). - **Sous‑échantillonnage chroma** : méthode qui réduit la résolution des composantes de couleur (ex. 4:2:0). - **Taux de compression (CR)** : rapport entre le débit brut et le débit net après compression. - **AES** : Advanced Encryption Standard, algorithme de chiffrement symétrique par blocs de 128 bits. - **CTR** : mode de fonctionnement d’un chiffrement par blocs qui génère un flux de clés pseudo‑aléatoires à partir d’un compteur. - **RSA** : algorithme de chiffrement asymétrique basé sur la difficulté de la factorisation d’un grand entier. - **Nonce** : nombre utilisé une seule fois, destiné à garantir l’unicité du vecteur d’initialisation dans un mode de chiffrement. - **HMAC** : Hash‑based Message Authentication Code, mécanisme d’authentification et d’intégrité basé sur une fonction de hachage. - **DRM** : Digital Rights Management, ensemble de technologies qui contrôlent l’usage des contenus numériques. - **HSM** : Hardware Security Module, dispositif physique dédié à la génération, au stockage et à l’utilisation sécurisée de clés cryptographiques. - **DVB‑CI** : Digital Video Broadcasting – Common Interface, interface permettant d’insérer des modules de condition d’accès dans un récepteur TNT. - **PAL** : Phase Alternating Line, norme de télévision analogique utilisée au Cameroun (625 lignes, 50 Hz). - **VOD** : Video‑On‑Demand, service de vidéo à la demande permettant la location ou l’achat de contenus en ligne. --- ## Exercices d'application corrigés ### Exercice 1 – Dimensionnement d’un flux pour la TNT **Énoncé** : Un technicien de la CRTV (Cameroon Radio Television) doit préparer un flux vidéo pour la diffusion en TNT sur une fréquence allouée à 6 Mbps. Il choisit une résolution HD (1280 × 720), 30 fps, profondeur 10 bits, sous‑échantillonnage 4:2:0 et le codec H.265/HEVC. Quel taux de compression minimal doit‑il atteindre pour respecter la bande passante disponible ? **Corrigé** : 1. Débit brut : \[ B_{\text{brut}} = 1280 \times 720 \times 30 \times 10 \times (1 + 0.5) = 1280 \times 720 \times 30 \times 10 \times 1.5 \] \[ = 1280 \times 720 \times 450 = 414\,720\,000\ \text{bits/s} \approx 414,7\ \text{Mbps} \] 2. Débit net autorisé : 6 Mbps. 3. Taux de compression requis : \[ CR_{\min} = \dfrac{B_{\text{brut}}}{B_{\text{net}}} = \dfrac{414,7}{6} \approx 69,1 \] **Réponse** : Un taux de compression d’au moins **70 : 1** est nécessaire. En pratique, on choisira un profil HEVC Main 10 avec un CR autour de 80‑100 pour garder une marge de sécurité. ### Exercice 2 – Échange de clé RSA et chiffrement AES **Énoncé** : Un serveur VOD possède une paire de clés RSA : \(n = 3233\) (produit de 61 × 53) et \(e = 17\). Le client souhaite louer un film et génère une clé de session AES‑128 \(K_{sess} = 0x2A3F4C5D6E7F8A9B0C1D2E3F4A5B6C7D\) (en hexadécimal). 1. Calculer le texte chiffré \(C = K_{sess}^{e} \bmod n\). 2. Montrer comment le serveur récupère \(K_{sess}\) avec sa clé privée \(d\) (où \(d = 2753\)). **Corrigé** : - Conversion de \(K_{sess}\) en entier décimal : \(K_{sess} = 0x2A3F4C5D6E7F8A9B0C1D2E3F4A5B6C7D = 188\,377\,995\,502\,562\,587\,302\,215\,938\,842\,735\,661\) (on travaille modulo \(n\), donc on réduit). - Comme \(n\) est petit, on réduit d’abord \(K_{sess} \bmod n\) : \(K_{sess} \bmod 3233 = 188\,377\,995\,502\,562\,587\,302\,215\,938\,842\,735\,661 \mod 3233 = 1245\) (on peut vérifier avec une calculatrice). - Chiffrement : \(C = 1245^{17} \bmod 3233\). En utilisant l’exponentiation modulaire rapide, on obtient \(C = 2021\). - Déchiffrement côté serveur : \(K' = C^{d} \bmod n = 2021^{2753} \bmod 3233 = 1245\). - Reconversion en hexadécimal donne bien la clé de session originale (après re‑padding à 128 bits). **Remarque** : Dans la pratique, on utilise des clés RSA de 2048 bits ou plus ; cet exemple illustre uniquement le principe avec de petits nombres pour faciliter le calcul à la main. ### Exercice 3 – Vérification d’intégrité avec HMAC‑SHA‑256 **Énoncé** : Après chiffrement d’un bloc vidéo de 16 octets avec AES‑128/CTR, on veut ajouter un HMAC‑SHA‑256 pour garantir l’intégrité. La clé HMAC est \(K_{hmac} = 0x000102030405060708090A0B0C0D0E0F\). Le bloc chiffré (en hexadécimal) est : `3F 2A 7C 9E 1B 4D 6A 88 00 11 22 33 44 55 66 77`. Calculer le HMAC‑SHA‑256 (on peut utiliser un outil en ligne ou une bibliothèque, mais on montre les étapes conceptuelles). **Corrigé** (étapes) : 1. Étendre la clé HMAC à 64 octets (taille du bloc SHA‑256) en ajoutant des zéros à droite : \(K_{0} = 0x000102030405060708090A0B0C0D0E0F\) suivi de 48 octets de 0x00. 2. Calculer \(ipad = K_{0} \oplus 0x36\) répété 64 fois, et \(opad = K_{0} \oplus 0x5C\) répété 64 fois. 3. Concaténer \(ipad\) avec le message (le bloc chiffré) puis appliquer SHA‑256 → résultat intermédiaire. 4. Concaténer \(opad\) avec le résultat intermédiaire puis appliquer à nouveau SHA‑256 → le HMAC final. En utilisant une bibliothèque Python : ```python import hashlib, hmac key = bytes.fromhex('000102030405060708090A0B0C0D0E0F') msg = bytes.fromhex('3F2A7C9E1B4D6A880011223344556677') hmac_sha256 = hmac.new(key, msg, hashlib.sha256).hexdigest() print(hmac_sha256) ``` Le résultat obtenu (en hexadécimal) dépend de l’implémentation ; on peut l’obtenir en exécutant le code Python ci‑dessus. Ce HMAC de 32 octets sera ajouté à la fin du bloc chiffré lors du stockage ou de la transmission. --- ## Erreurs fréquentes et règles de sécurité | # | Erreur fréquente | Conséquence | Règle de bonne pratique / sécurité | |---|------------------|-------------|------------------------------------| | 1 | Réutiliser le même nonce avec la même clé AES‑CTR | Deux textes clairs différents peuvent être récupérés par un simple XOR des deux chiffrés (attaque de réutilisation de nonce). | Toujours générer un nonce aléatoire ou incrémenté de façon unique pour chaque fichier/clé ; stocker le nonce en clair mais ne jamais le réutiliser. | | 2 | Utiliser un débit vidéo supérieur à la bande passante allouée sans vérifier le taux de compression | Saturation du multiplex, perte de paquets, gel de l’image ou décrochage du son. | Effectuer le calcul du débit brut et appliquer un taux de compression réaliste (ex. : H.264 ≈ 30‑50 : 1 pour SD, ≈ 50‑80 : 1 pour HD) avant l’encodage. | | 3 | Stocker les clés de chiffrement en clair sur un serveur accessible via le réseau | Vol de clés → déchiffrement illégal du contenu, piratage, perte de revenus. | Conserver les clés dans un HSM ou un coffre‑fort logique conforme à ISO 27001 ; restreindre l’accès aux seuls processus de chiffrement/déchiffrement ; journaliser les accès. | | 4 | Omettre le contrôle d’intégrité (HMAC) sur le flux chiffré | Un attaquant peut altérer des bits (bit‑flipping) sans être détecté, provoquant des artefacts visibles ou une perte de synchronisation. | Toujours ajouter un HMAC‑SHA‑256 (ou AES‑GCM qui fournit authentification intégrée) après le chiffrement ; vérifier l’intégrité avant le déchiffrement. | | 5 | Utiliser une clé RSA trop petite (ex. : 1024 bits) | Factorialisation possible avec des ressources modernes → découverte de la clé privée. | Employer des clés RSA d’au moins 2048 bits (ou préférer ECC 256 bits pour équivalence de sécurité) ; renouveler les clés périodiquement. | | 6 | Négliger la mise à jour du firmware des modules de condition d’accès (CAM) | Vulnérabilités connues exploitées pour contourner le DRM, entraînant le piratage des chaînes payantes. | Appliquer les correctifs de sécurité fournis par les fabricants de CAM ; suivre les bulletins de sécurité de l’ARTC et des fournisseurs de systèmes de condition d’accès. | --- *Fin du cours.*