Chiffrement SRT : AES-128 vs AES-256 pour le streaming sécurisé

Pourquoi le chiffrement est essentiel pour le streaming en direct

Tout flux vidéo en direct qui transite par l’internet public peut être intercepté. Ce n’est pas théorique — des outils de capture de paquets comme Wireshark peuvent reconstituer un flux vidéo non chiffré à partir du trafic réseau capturé en quelques secondes. Si votre flux transporte du contenu propriétaire, des communications d’entreprise privées, des événements payants en direct ou des images d’actualité sensibles, le transport non chiffré est un risque.

RTMP ne dispose d’aucun chiffrement natif. Le palliatif est RTMPS, qui encapsule RTMP dans TLS, mais cela ajoute de la complexité de gestion des certificats et ne résout pas les autres limitations de RTMP (blocage de tête de ligne TCP, pas de récupération des paquets perdus, pas de diagnostics en temps réel).

SRT a été conçu avec le chiffrement intégré au protocole dès l’origine. Ce n’est ni un ajout tardif ni un encapsulage — le chiffrement AES fait partie de la spécification SRT, implémenté au niveau des paquets et disponible dans toute implémentation SRT.

Cet article couvre le fonctionnement du chiffrement SRT en profondeur, les différences pratiques entre AES-128 et AES-256, les bonnes pratiques de gestion des phrases secrètes et la configuration de l’ensemble dans un environnement de production.

Fonctionnement du chiffrement SRT

Comprendre le mécanisme vous aide à prendre des décisions éclairées concernant les paramètres de sécurité.

Dérivation de clé

SRT n’envoie pas votre phrase secrète sur le réseau. Il utilise plutôt PBKDF2 (Password-Based Key Derivation Function 2) pour dériver la clé de chiffrement réelle :

1. Le listener génère un sel aléatoire (unique par session)
2. Le listener envoie le sel au caller pendant la poignée de main SRT (en clair — c’est sûr ; les sels ne sont pas des secrets)
3. Les deux côtés calculent indépendamment : AES_Key = PBKDF2(passphrase, salt, iterations, key_length)
4. La clé dérivée est utilisée pour le chiffrement AES de tous les paquets suivants

Cela signifie :

• La phrase secrète ne transite jamais sur le réseau
• Chaque session utilise une clé dérivée différente (car le sel est aléatoire)
• Un attaquant qui capture le trafic d’une session ne peut pas dériver les clés d’autres sessions (même avec la même phrase secrète)

Ce qui est chiffré

SRT chiffre la charge utile (vos données vidéo/audio) mais pas les en-têtes SRT. C’est voulu :

• Chiffré : Toutes les données de charge utile MPEG-TS (vidéo, audio, métadonnées)
• Non chiffré : Les en-têtes de paquets SRT (numéros de séquence, horodatages, informations de contrôle)

Les en-têtes doivent rester non chiffrés car les équipements réseau intermédiaires (routeurs, dispositifs NAT) ont besoin de router les paquets, et SRT lui-même a besoin des en-têtes pour gérer la retransmission, la synchronisation et le contrôle de flux.

Un attaquant qui capture du trafic SRT chiffré peut voir :

• Que du trafic SRT circule entre deux adresses IP
• Le débit de paquets et le bitrate approximatif (à partir des tailles de paquets et du timing)
• Les métadonnées du protocole SRT (paramètres de latence, paramètres de connexion)

Il ne peut pas voir :

• Le contenu vidéo ou audio
• Les métadonnées ou sous-titres intégrés
• La phrase secrète ou la clé dérivée

Renégociation de clé

SRT implémente une renégociation périodique des clés (également appelée rotation de clé au niveau du protocole). La clé de chiffrement est rafraîchie automatiquement pendant les sessions de longue durée :

1. Après un nombre configurable de paquets, le listener génère un nouveau sel
2. Une nouvelle clé est dérivée à partir de la même phrase secrète + nouveau sel
3. Les deux côtés basculent simultanément vers la nouvelle clé
4. Cela se produit de manière transparente — aucune interruption du flux

Cela fournit un degré de confidentialité persistante. Même si un attaquant parvient à compromettre une clé dérivée, il n’obtient accès qu’à une portion du flux, pas à l’historique complet de la session.

AES-128 vs AES-256 : les vraies différences

SRT prend en charge trois longueurs de clé AES : 128 bits, 192 bits et 256 bits. AES-192 est rarement utilisé en pratique, cette comparaison se concentre donc sur AES-128 et AES-256.

Force de sécurité

*L’algorithme de Grover réduit théoriquement de moitié la longueur effective de la clé sur un ordinateur quantique. AES-256 affaibli à 128 bits de force effective reste incassable. AES-128 affaibli à 64 bits est théoriquement vulnérable — bien que des ordinateurs quantiques capables de cela n’existent pas encore.

En résumé : Les deux sont incassables avec la technologie actuelle. AES-256 offre une marge plus importante contre les menaces futures, y compris l’informatique quantique.

Impact sur les performances

C’est là où les idées fausses abondent. Beaucoup supposent que AES-256 est nettement plus lent que AES-128. En pratique :

La raison pour laquelle l’impact réel est si faible : chaque processeur x86 moderne depuis Intel Westmere (2010) et AMD Bulldozer (2011) inclut AES-NI — des instructions matérielles dédiées au chiffrement et au déchiffrement AES. Avec AES-NI, le chiffrement se fait dans le silicium à la vitesse du lien. La différence entre 10 et 14 tours se mesure en nanosecondes, pas en millisecondes.

Vérification : Vérifiez si votre processeur prend en charge AES-NI :

# Linux
grep -o aes /proc/cpuinfo | head -1

# macOS
sysctl -a | grep -i aes

Si la sortie inclut aes, l’accélération matérielle est disponible.

Recommandation : Utilisez AES-256 pour tout. La différence de performance est imperceptible dans un contexte de streaming, et vous obtenez une sécurité à l’épreuve du futur. Il n’y a aucune raison pratique de choisir AES-128 en 2026.

Quand AES-128 pourrait encore avoir du sens

Le seul scénario où AES-128 est un choix défensable : les appareils embarqués sans AES-NI (très vieux processeurs ARM, certains encodeurs IoT). Sur ces appareils, le chiffrement AES s’effectue en logiciel, et les 40 % de calcul supplémentaire pour AES-256 peuvent être significatifs à haut débit. Même dans ce cas, les processeurs ARM modernes (ARMv8+) incluent des extensions matérielles AES.

Gestion des phrases secrètes

Le chiffrement n’est aussi fort que la gestion de vos phrases secrètes. Une implémentation AES-256 parfaite avec une phrase secrète faible ou compromise n’offre aucune sécurité.

Exigences relatives aux phrases secrètes

SRT impose ces contraintes :

• Longueur minimale : 10 caractères
• Longueur maximale : 79 caractères

Au-delà du minimum, la force de la phrase secrète dépend de l’entropie. PBKDF2 dérive la clé en utilisant plusieurs itérations, ce qui offre une certaine protection contre les phrases secrètes faibles, mais ce n’est pas un substitut à une phrase secrète robuste.

Générer des phrases secrètes robustes

Utilisez un générateur aléatoire cryptographiquement sûr :

# Générer une phrase secrète aléatoire de 32 caractères
openssl rand -base64 32
# Sortie : K7xPq2mN8vR3wY6tA1cF5hJ9dL0gS4bU+eI7oW=

# Générer une phrase secrète de 44 caractères (plus d'entropie)
openssl rand -base64 44
# Sortie : 8Fp3Kx7NqR2mWvY6tA1cF5hJ9dL0gS4bUeI7oWzXpQ3nM==

# Ou utiliser /dev/urandom directement
head -c 32 /dev/urandom | base64

À éviter :

• Les mots ou expressions du dictionnaire
• Les phrases secrètes de moins de 20 caractères
• La réutilisation de phrases secrètes entre les flux
• Les phrases secrètes incluant le nom du flux, la date ou tout autre contexte devinable

Distribution des phrases secrètes

La phrase secrète doit être partagée entre le listener SRT et le caller. C’est le point le plus vulnérable du système. Méthodes de distribution sécurisées :

Bonne pratique :

• Messagerie chiffrée (Signal, courriel chiffré)
• Coffres-forts partagés de gestionnaires de mots de passe (1Password, Bitwarden)
• Appel API sécurisé entre systèmes automatisés (HTTPS avec TLS mutuel)
• En personne ou par téléphone (pour une configuration ponctuelle)

À éviter :

• Courriel non chiffré
• Messages Slack / Teams / Discord (stockés dans le cloud, accessibles aux administrateurs)
• Documents partagés (Google Docs, Notion, Confluence)
• Intégration dans des scripts commités dans le contrôle de version

Pour les déploiements automatisés, stockez les phrases secrètes dans un gestionnaire de secrets (HashiCorp Vault, AWS Secrets Manager, Kubernetes Secrets avec chiffrement au repos) et injectez-les au moment de l’exécution.

Rotation des phrases secrètes

Pour les déploiements de longue durée, effectuez une rotation périodique des phrases secrètes :

Calendrier de rotation recommandé :

• Flux événementiels : Nouvelle phrase secrète par événement
• Flux quotidiens : Rotation hebdomadaire
• Flux 24h/24 : Rotation mensuelle
• Après le départ de tout membre de l’équipe : Rotation immédiate

Processus de rotation avec Vajra Cast :

1. Créez un nouvel ingest SRT avec la nouvelle phrase secrète (Vajra Cast prend en charge plusieurs ingests simultanément)
2. Partagez la nouvelle phrase secrète avec l’opérateur de l’encodeur distant
3. L’encodeur bascule vers le nouvel ingest
4. Vérifiez que la nouvelle connexion fonctionne
5. Désactivez ou supprimez l’ancien ingest

Comme Vajra Cast prend en charge la gestion à chaud, la création et la suppression d’ingests n’affectent aucun autre flux en cours. La rotation est transparente.

Configuration du chiffrement dans Vajra Cast

Chiffrement par ingest

Chaque ingest SRT dans Vajra Cast dispose de paramètres de chiffrement indépendants :

1. Créez ou modifiez un ingest SRT
2. Activez le Chiffrement
3. Sélectionnez la longueur de clé : AES-256 (recommandé)
4. Entrez votre phrase secrète
5. Enregistrez

L’URL SRT correspondante pour les encodeurs :

srt://your-server:9000?passphrase=VotrePhrasseSecreteSecurisee&pbkeylen=32

Paramètres :

• pbkeylen=16 pour AES-128
• pbkeylen=24 pour AES-192
• pbkeylen=32 pour AES-256

Chiffrement par sortie

Les sorties SRT peuvent avoir leurs propres paramètres de chiffrement, indépendants de l’ingest :

• Ingest chiffré, sortie non chiffrée : Utile lorsque la sortie est sur un réseau de confiance (ex. même LAN)
• Ingest non chiffré, sortie chiffrée : Utile lorsque l’ingest est local mais la sortie traverse l’internet
• Les deux chiffrés avec des phrases secrètes différentes : Isolation maximale entre les opérateurs d’ingest et de sortie

Cette flexibilité signifie que la frontière de chiffrement est par connexion, pas par flux. Vous pouvez chiffrer exactement les segments réseau qui nécessitent une protection sans chiffrer les connexions locales de confiance.

Vérification de l’état du chiffrement

Dans le tableau de bord Vajra Cast, chaque flux actif affiche son état de chiffrement :

• AES-256 SÉCURISÉ — chiffrement actif avec AES-256
• AES-128 SÉCURISÉ — chiffrement actif avec AES-128
• NON SÉCURISÉ — pas de chiffrement

Vous pouvez également vérifier via l’API REST :

curl -H "Authorization: Bearer VOTRE_TOKEN" \
  https://your-server:8080/api/v1/ingests/1/stats

La réponse inclut l’état du chiffrement dans le bloc de statistiques SRT.

Vérification avec Wireshark

Pour une certitude absolue, capturez et inspectez le trafic :

# Capturer 10 secondes de trafic SRT
tcpdump -i eth0 -w capture.pcap udp port 9000 -c 1000

Ouvrez dans Wireshark et examinez les charges utiles UDP. Avec le chiffrement activé, la charge utile est constituée de données binaires d’apparence aléatoire. Sans chiffrement, vous pouvez identifier les octets de synchronisation MPEG-TS (0x47) et potentiellement reconstituer la vidéo.

Considérations de conformité

Selon votre secteur d’activité, le chiffrement peut être une exigence plutôt qu’une bonne pratique.

Audiovisuel

• L’UER (Union Européenne de Radio-Télévision) recommande le chiffrement pour toutes les contributions sur les réseaux publics
• SMPTE ST 2022-7 (commutation de protection transparente) est complémentaire au chiffrement SRT pour la contribution audiovisuelle

Entreprise

• La conformité SOC 2 exige généralement le chiffrement des données en transit
• ISO 27001 impose la protection des informations pendant le transfert électronique
• Le RGPD exige des mesures techniques appropriées pour les données personnelles — si votre flux contient des individus identifiables, le chiffrement est de fait requis

Gouvernement

• FedRAMP exige un chiffrement valide FIPS 140-2. AES-128 et AES-256 sont tous deux des algorithmes approuvés FIPS. Cependant, l’implémentation SRT doit utiliser une bibliothèque cryptographique validée FIPS pour une conformité complète.
• ITAR/EAR — le chiffrement pour le contenu contrôlé peut avoir des exigences spécifiques

Santé

• HIPAA exige le chiffrement des informations de santé protégées (PHI) en transit. Le streaming médical (télémédecine, diffusions chirurgicales) doit être chiffré.

Finance

• PCI DSS exige un chiffrement fort pour les données de porteurs de carte en transit. Les diffusions d’événements financiers peuvent contenir des informations matérielles non publiques nécessitant une protection.

Dans tous les cas, AES-256 satisfait ou dépasse les exigences de chiffrement. AES-128 satisfait également toutes les normes actuelles, mais AES-256 offre la marge maximale.

Chiffrement et performances : impact de bout en bout

Quantifions l’impact total de l’activation du chiffrement AES-256 sur un flux de travail de streaming typique :

Scénario : 1080p30 H.264 à 6 Mbps

*Le chiffrement SRT n’augmente pas le bitrate du flux. La taille de la charge utile reste identique car AES est un chiffrement par blocs opérant sur des blocs de taille fixe. Les en-têtes SRT (qui ne sont pas chiffrés) conservent également la même taille.

L’impact total sur le système de l’activation du chiffrement AES-256 est inférieur à 1 % du CPU. Sur tout matériel produit au cours de la dernière décennie, c’est indétectable.

Problèmes courants de chiffrement

Échec de connexion silencieux

Le problème de chiffrement le plus courant : la connexion SRT ne s’établit tout simplement pas, sans message d’erreur.

Cause : Discordance de phrase secrète ou de longueur de clé entre le caller et le listener.

Étapes de diagnostic :

1. Vérifiez la phrase secrète exacte des deux côtés (copier-coller, ne pas retaper)
2. Vérifiez que pbkeylen correspond des deux côtés (les deux doivent être 16, 24 ou 32)
3. Recherchez les espaces de fin ou les caractères de retour à la ligne dans la phrase secrète
4. Désactivez temporairement le chiffrement des deux côtés pour confirmer que la connectivité de base fonctionne

Erreur “Encryption not available”

Cause : La bibliothèque SRT a été compilée sans prise en charge du chiffrement.

Solution : Installez la bibliothèque SRT avec le chiffrement activé. Sous Linux :

# Vérifier que SRT a été compilé avec le chiffrement
srt-live-transmit --version
# Devrait afficher "encryption: AES-CTR" ou similaire

Si le chiffrement est absent, réinstallez SRT avec le support OpenSSL :

# Compiler SRT depuis les sources avec le chiffrement
git clone https://github.com/Haivision/srt.git
cd srt
mkdir build && cd build
cmake .. -DENABLE_ENCRYPTION=ON -DUSE_OPENSSL=ON
make
sudo make install

Dégradation des performances sur du matériel ancien

Cause : Le processeur ne dispose pas de l’accélération matérielle AES-NI.

Symptômes : L’utilisation CPU augmente significativement (10-20 %) lorsque le chiffrement est activé, surtout à haut débit.

Solution : Mettez à niveau le matériel. Tout processeur Intel depuis 2010+ ou AMD depuis 2011+ dispose d’AES-NI. Si la mise à niveau n’est pas possible, utilisez AES-128 pour réduire la charge de calcul d’environ 30 % par rapport à AES-256.

Anomalies lors de la renégociation de clé

Symptômes : Brève anomalie audio/vidéo à intervalles réguliers pendant les flux de longue durée.

Cause : Rare problème de synchronisation lors de la renégociation de clé SRT.

Solution : Mettez à jour vers la dernière version de la bibliothèque SRT. Ce problème a été corrigé dans les versions récentes. Dans Vajra Cast, assurez-vous d’utiliser la dernière version.

Résumé des bonnes pratiques

1. Chiffrez toujours les flux qui traversent l’internet public. Il n’y a aucune raison valable de ne pas le faire.
2. Utilisez AES-256 pour tout. Le coût en performances est négligeable.
3. Générez les phrases secrètes avec openssl rand -base64 32 ou équivalent. N’utilisez jamais de mots du dictionnaire.
4. Utilisez des phrases secrètes uniques par flux. Une phrase secrète compromise ne devrait pas exposer les autres flux.
5. Distribuez les phrases secrètes de manière sécurisée — messagerie chiffrée ou gestionnaires de secrets, jamais par courriel en clair.
6. Effectuez la rotation des phrases secrètes périodiquement et après tout changement d’équipe.
7. Vérifiez que le chiffrement est actif dans le tableau de bord de votre passerelle. Ne supposez rien.
8. Documentez votre politique de chiffrement — quels flux sont chiffrés, quelle longueur de clé, quel calendrier de rotation.
9. Testez la rotation des phrases secrètes avant d’avoir à le faire en production.
10. Maintenez les bibliothèques SRT à jour pour les derniers correctifs de sécurité et améliorations du chiffrement.

Pour le guide complet de configuration SRT incluant le chiffrement, la latence et la surveillance, consultez notre guide SRT Streaming Gateway. Pour la configuration pas à pas du chiffrement, lisez Configuration du chiffrement SRT.