Résumé

  • SFrame permet à un relais de sélectionner des médias sans en lire le contenu. La confidentialité ne supprime donc pas les arbitrages de diffusion.
  • Une image vidéo peut être déchiffrée sans être décodable si la référence dont elle dépend a été perdue avant l’arrivée de la bonne clé.
  • L’évaluation d’un service doit distinguer protection du contenu, choix des flux et participation effective, sans transformer toute adaptation de qualité en soupçon d’ingérence.

Lorsqu’un participant ne voit rien, trois équipes peuvent avoir raison simultanément. La connexion fonctionne. La clé est disponible. Le déchiffrement des images reçues réussit. Pourtant, la vidéo reste inutilisable. Ce paradoxe apparent tient à une propriété banale de la compression : une image peut dépendre d’une autre qui n’est jamais parvenue jusqu’au décodeur.

Le RFC 9605, consacré à SFrame, décrit précisément une telle difficulté lors d’un changement de membres. L’image de référence et la clé ne circulent pas forcément par le même chemin. Si l’image arrive sous une clé encore inconnue et est rejetée, la réception ultérieure de la clé ne la fait pas réapparaître. Les images dépendantes suivantes peuvent alors être déchiffrées, mais pas décodées.

Il ne s’agit pas d’un incident documenté chez un fournisseur. C’est une possibilité architecturale explicitement examinée par la norme. Elle invite à abandonner une équivalence commode : une réunion correctement chiffrée n’est pas, pour cette seule raison, une réunion dont chacun reçoit une vue exploitable.

Diagnostiquer sans confondre les couches

Le cas de l’image de référence manquante pose une question de coordination. Qui sait que le nouvel arrivant dispose désormais de la clé ? Qui demande une image indépendante ? Qui la produit, puis décide de la transmettre à ce destinataire ?

La section 6.2 du RFC 9605 évoque la production d’une image de référence après la mise en service de la nouvelle clé pour éviter ce décalage particulier. Cela ne fixe aucun délai universel d’entrée dans une réunion. La possibilité de conserver temporairement un objet chiffré dont la clé manque, prévue ailleurs dans le texte, n’est pas une obligation de mise en œuvre. La perte réseau et les capacités du terminal ne disparaissent pas non plus.

Le découpage retenu pour le chiffrement a sa propre conséquence. Quand une image entière constitue l’objet protégé par SFrame, il faut la recevoir au complet, puis la déchiffrer, avant de la décoder. Le décodage partiel anticipé n’est pas disponible dans cette configuration. Un traitement au niveau des paquets présente d’autres coûts et contraintes d’intégration. On ne peut en déduire un classement général des performances.

La bonne enquête ne cherche donc pas un voyant unique capable d’expliquer tous les écrans noirs. Elle identifie la condition absente. Ajouter des images dépendantes n’équivaut pas à restituer leur référence ; accélérer le déchiffrement ne livre pas une clé qui manque ; confirmer le débit global ne prouve pas qu’un destinataire reçoit le bon flux.

Le relais n’a pas besoin de voir pour choisir

Ce rôle du destinataire serait facile à oublier si l’on représentait le relais comme un tuyau devenu passif grâce au chiffrement. Une unité de transfert sélectif, ou SFU, est au contraire conçue pour effectuer des choix.

La topologie décrite dans le RFC 7667, section 3.7, permet des ensembles de sources différents selon les récepteurs. Le relais peut sélectionner des variantes adaptées au débit ou à la disposition des fenêtres. Il peut aussi traiter localement un retour de contrôle RTCP ou le faire suivre vers la source. Le besoin exprimé par un terminal ne traverse donc pas nécessairement une chaîne sans décision intermédiaire.

Cette latitude sert le fonctionnement normal d’une conférence. Une vignette et une présentation agrandie n’ont pas les mêmes besoins. Un terminal contraint peut gagner en continuité en recevant moins de médias. Imposer une diffusion identique à tous n’est ni une conclusion du standard ni une définition suffisante de l’équité.

SFrame, publié en août 2024 avec le statut de Proposed Standard, retire au SFU l’accès au contenu lorsque les clés nécessaires lui restent inaccessibles. Il lui laisse la sélection que l’application rend possible. Ce partage est le résultat recherché, pas une contradiction interne du protocole.

Les variantes vidéo rendent ce partage tangible. En simulcast, les versions encodées séparément donnent lieu à des objets chiffrés distincts, avec des valeurs de compteur uniques pour les opérations de chiffrement. En codage vidéo scalable, une couche que le SFU doit pouvoir retirer doit être portée par un objet SFrame distinct. Le relais ne reçoit pas pour autant le droit de découper arbitrairement un contenu authentifié.

Le choix s’exerce donc entre des unités définies par l’émetteur et l’application. La protection limite certaines modifications indétectables ; elle n’oblige pas à transmettre toutes les unités valides à chacun. Une preuve d’intégrité ne peut raconter à elle seule l’histoire des objets non livrés.

Ce qui reste visible mérite aussi une décision

Le contenu protégé n’est pas toute l’information utile au transfert. L’identifiant de clé et le compteur SFrame sont protégés en intégrité, mais ne sont pas confidentiels pour les intermédiaires concernés. L’application peut également fournir des métadonnées authentifiées que le relais peut lire sans pouvoir les modifier discrètement.

Cette propriété dépend du périmètre effectivement authentifié. Toute métadonnée de l’application ne bénéficie pas automatiquement de la même couverture. Le récepteur ne doit pas en faire un usage sémantique avant authentification, sauf les opérations nécessaires à la préparation du déchiffrement. Et une application qui place des significations superflues dans un identifiant visible peut divulguer ces significations malgré le secret des images.

Les noms du transport ont une autre limite. Un SSRC ou un MID peut être réutilisé pour des médias provenant de participants différents. L’association authentifiée par l’identifiant SFrame peut protéger contre certaines manipulations d’attribution par le SFU ; le mécanisme symétrique ne fournit pas, en revanche, une authentification individuelle contre un participant malveillant détenteur des clés. Ni le relais ni le transport ne doivent être crédités de garanties plus larges que celles décrites.

Enfin, le terminal reste dans le raisonnement de confiance. Le RFC 8827 sur la sécurité de WebRTC place le navigateur dans la base informatique de confiance et impose un socle de transport chiffré. Ajouter une protection SFrame ne démontre pas l’intégrité d’un navigateur compromis. Cela ne rend pas non plus identiques les différents rapports de confiance entre application, service d’appel et extrémités.

Les errata officiels du RFC 9605 ont été consultés : trois corrections vérifiées portent sur une variable de construction du nonce, la qualification non authentifiée d’AES-CTR et la description d’une sous-clé d’authentification. Elles ne suppriment pas les considérations de sélection ou d’image de référence exposées ici. Aucun constat de déploiement, de censure ou de performance mesurée n’en est tiré.

La conclusion publique est simple mais exigeante : le secret du contenu constitue un gain réel. Pour savoir si la réunion fonctionne, il faut encore regarder ce que le service choisit d’acheminer et ce que chaque terminal peut effectivement présenter.