Résumé

  • RFC 5159, publié à titre informatif en mars 2008, enregistrait quatre attributs SDP issus des travaux OMA BCAST.
  • stkmstream indiquait quels flux de Short Term Key Messages un terminal devait traiter pour un média protégé.
  • Une déclaration au niveau du média remplaçait la liste de niveau session au lieu de simplement la compléter.
  • Plusieurs occurrences pouvaient désigner des solutions de rechange ou plusieurs flux nécessaires.
  • Le bon identifiant ne livrait aucune clé et ne démontrait ni droit d’accès, ni déchiffrement, ni lecture.
  • Les identifiants étaient uniques dans une session SDP seulement ; ils perdaient leur sens sans cette enveloppe.
  • bcastversion annonçait une version, mais une valeur sans intégrité pouvait servir à provoquer un retour en arrière.
  • SRTPAuthentication choisissait RCCm1, RCCm2 ou RCCm3 sans authentifier à lui seul un paquet.
  • SRTPROCTxRate déclarait la fréquence de transmission du compteur de cycles, avec un défaut égal à un.
  • La cadence annoncée ne démontrait pas la réception authentifiée du compteur ni la synchronisation du récepteur.
  • L’IETF enregistrait les noms tandis que l’OMA conservait la maîtrise de leur interprétation technique.
  • La preuve doit distinguer description reçue, portée effective, message de clé, droit, état installé, authentification, déchiffrement et lecture.

Une règle de portée pouvait décider de tout

Une session de diffusion peut contenir plusieurs médias et plusieurs flux de contrôle. Il serait coûteux pour un terminal d’écouter l’ensemble du multiplexe afin de découvrir les messages de clés utiles. L’attribut stkmstream fournissait donc une carte : telle piste protégée dépend de tel flux de messages de clés à court terme.

Au niveau session, cette carte servait de valeur commune. Au niveau média, une nouvelle déclaration la remplaçait pour la section concernée. Le verbe important est « remplacer ». Un logiciel qui fusionnait les deux listes n’exécutait pas la même politique qu’un logiciel qui appliquait la surcharge. Un collecteur qui ne gardait que les attributs globaux pouvait produire une preuve propre, mais fausse, du chemin cryptographique attendu.

Cette nuance devient critique lors d’une mise à jour. Le diffuseur peut publier une nouvelle description dans laquelle une piste passe du flux 3 au flux 8. Le terminal peut continuer d’utiliser une description mise en cache, recevoir la nouvelle description sans l’appliquer, ou résoudre la portée de travers. Dans les trois cas, le serveur a émis une instruction valide ; dans aucun cas cette émission ne prouve que le récepteur a suivi la nouvelle instruction.

La preuve minimale doit donc lier le média, la version exacte de la description, la portée retenue et la décision locale d’abonnement. La configuration d’origine et l’état effectif du terminal sont deux objets distincts.

Plusieurs références n’étaient pas plusieurs succès

RFC 5159 autorisait plusieurs attributs stkmstream. Selon le dispositif, ils pouvaient offrir des flux de remplacement ou indiquer que plusieurs flux devaient être traités. Cette expressivité évitait de figer un seul chemin. Elle interdisait aussi une conclusion trop rapide : voir trois références n’équivaut ni à trois clés reçues, ni même à une clé utilisable.

Pour chaque référence, il faut observer l’abonnement, l’arrivée des paquets, leur intégrité, le traitement du message, la décision d’autorisation, le déballage de la clé et son installation dans le contexte correspondant. Une solution de rechange choisie doit être identifiée. Si plusieurs flux sont obligatoires, leur réunion doit être démontrée. Sans cette cardinalité, le rapport peut qualifier la session de complète après le succès d’une seule branche.

L’attribut restait facultatif pour un média non chiffré. Son absence pouvait donc être correcte, ou révéler une description incomplète d’un média protégé. Seul le contexte permettait de trancher. Une règle d’audit qui transforme toute absence en erreur fabrique des alarmes ; une règle qui transforme toute absence en « non applicable » masque les pannes.

La version annoncée pouvait devenir un levier de dégradation

bcastversion portait une chaîne décrivant la version BCAST. Cela ressemble à une étiquette de compatibilité. Le chapitre de sécurité soulignait pourtant qu’une modification non détectée pouvait forcer l’usage d’une version antérieure. Le champ n’avait pas besoin de contenir un secret : il orientait le choix d’un comportement susceptible d’être moins protecteur.

La bonne question n’est donc pas seulement « quelle valeur figurait dans le document source ? ». Il faut savoir quelle valeur a été reçue, si l’intégrité de la description a été vérifiée, quelle pile logicielle l’a interprétée et quelle politique en a résulté. Une capture du serveur et un journal du terminal peuvent tous deux être exacts tout en décrivant deux réalités différentes.

La falsification de stkmstream avait une autre conséquence : détourner le terminal du flux nécessaire ou l’obliger à traiter du trafic inutile. Le résultat pouvait être un refus de service, sans rupture visible de l’algorithme cryptographique. La sécurité dépendait de l’intégrité de la carte qui alimentait cet algorithme.

Déclarer RCCm2 n’authentifiait aucun paquet

L’attribut SRTPAuthentication associait des valeurs numériques aux modes RCCm1, RCCm2 et RCCm3. Cette sélection précisait une règle partagée entre émetteur et récepteur. Elle ne produisait pas le verdict d’authentification sur un paquet donné.

De même, SRTPROCTxRate indiquait la fréquence de transmission du rollover counter et prévoyait la valeur un lorsque l’attribut était absent. Le compteur étend l’espace des numéros de séquence. Si son état diffère entre les extrémités, les deux parties peuvent avoir la même configuration statique et néanmoins ne plus interpréter le paquet dans le même contexte.

Il faut conserver la valeur annoncée, les transmissions réellement observées, l’acceptation authentifiée par le récepteur et le compteur installé. Puis il faut rattacher cet état au verdict SRTP et au résultat de déchiffrement. Le fait qu’un paramètre soit conforme à sa grammaire ne constitue qu’un reçu de syntaxe.

Le registre ne détenait pas toute la sémantique

Le statut informatif du RFC n’était pas un accident administratif. Les attributs provenaient de l’Open Mobile Alliance. L’enregistrement IANA leur donnait des noms stables dans l’espace SDP, tandis que l’OMA gardait la maîtrise des spécifications qui définissaient leur usage. Une organisation coordonnait le vocabulaire ; l’autre conservait l’autorité sémantique.

Cette séparation protège contre les collisions mais complique l’archivage. Une entrée de registre actuelle ne suffit pas à reconstruire la version OMA appliquée par un équipement historique. Il faut conserver la référence normative, la version, les profils du fournisseur et, si possible, le comportement observé.

Les classifications de multiplexage publiées plus tard placent bcastversion et stkmstream dans la catégorie NORMAL et laissent les deux attributs SRTP à déterminer. Ce tableau répond à une question de copie dans des sessions groupées. Il ne certifie ni la sûreté, ni l’adoption, ni le bon fonctionnement d’un déploiement.

Une destination prévue ne prouvait pas un déploiement

Le texte évoquait l’usage attendu avec 3GPP MBMS, 3GPP2 BCMCS et DVB-H. C’est une indication historique sur le milieu visé en 2008, pas une liste d’opérateurs ni un inventaire de services effectivement lancés. Employer cette phrase comme preuve de production confondrait intention de conception et fait d’exploitation.

Pour établir un déploiement, il faudrait des descriptions capturées, des paquets, des journaux d’équipement, une documentation de version ou une attestation d’opérateur. Pour établir la lecture d’un contenu protégé, il faudrait encore relier droit, clé, contexte cryptographique et rendu. Le nom du système dans un RFC ne franchit aucune de ces frontières.

RFC 5159 demeure précieux parce qu’il rend la frontière visible : le plan de signalisation coordonne, mais le terminal produit le reçu d’exécution.

Sources

  1. RFC 5159, HTML
  2. RFC 5159, texte
  3. Notice du RFC Editor
  4. Notice IETF Datatracker
  5. Historique de RFC 5159
  6. Références de RFC 5159
  7. Errata de RFC 5159
  8. RFC 4566
  9. RFC 8866
  10. RFC 4771
  11. RFC 3711
  12. RFC 8859
  13. RFC 5761
  14. RFC 7201
  15. RFC 5764
  16. RFC 8126
  17. Paramètres SDP de l’IANA
  18. Déclaration IPR 2092
  19. RFC 2119
  20. RFC 8174
  21. RFC 3264
  22. Spécification initiale minimale
  23. Sur les couches de réalité
  24. Primauté du code en fonctionnement