FR 2825222 A1 20021129 FR 0106771 A 20010523 La présente invention se rapporte à la transmission et à la mise en #uvre d'instructions de contrôle pour accès à des fonctionnalités de récepteurs, ainsi qu'à des dispositifs correspondants. Afin de pouvoir contrôler le degré d'accessibilité à un récepteur à travers un réseau, il est connu de déterminer un ensemble de manoeuvres autorisées ou interdites et de les communiquer au récepteur. Pour ce faire, on transmet une liste de permissions appelée liste blanche (white list) ou inversement, une liste d'opérations interdites appelée liste noire (black list). Le récepteur enregistre ces informations en mémoire et les utilise ensuite pour établir à la réception de chaque message à travers le réseau s'il doit donner suite à des man#uvres requises par ce message. Cette technique permet ainsi d'attribuer des droits variables à un ensemble de récepteurs, puis d'émettre collectivement des messages, notamment par diffusion générale (broadcasting). L'expression diffusion générale désigne la transmission de données identiques vers un ensemble de destinations, que celle-ci soit effectuée notamment par radiodiffusion, par le câble ou par Internet. Le filtrage des opérations envoyées dans les messages est alors effectué directement au niveau des récepteurs, ce qui autorise en particulier la prise en compte de diverses catégories de récepteurs (par exemple selon des types d'abonnements distincts à des programmes de radio ou audiovisuels) sans avoir à s'en préoccuper lors de l'émission des messages. Un autre avantage des listes blanches ou noires est qu'elles permettent de réduire les risques de man#uvres frauduleuses via le réseau, qui pourraient porter préjudice au fonctionnement correct des récepteurs. On peut en effet n'autoriser que des accès à des fonctionnalités requises pour le fonctionnement courant du récepteur, en verrouillant les accès à toutes autres fonctionnalités sensibles. Par la suite et pour simplifier, on désignera par listes de permissions des listes blanches ou noires, les interdictions d'accès d'une liste noire étant considérées comme définissant implicitement des permissions (opérations complémentaires autorisées). De telles listes de permissions sont en particulier utilisées pour l'envoi de services à des téléviseurs interactifs. Cependant, même si les récepteurs sont fournis avec des listes de permissions en mémoire permanente, il est souhaitable et le plus souvent nécessaire de modifier ces listes ultérieurement. Pour éviter des déplacements de personnel et des opérations manuelles, on rend donc généralement possible leurs mises à jour à distance. Une telle modalité de mise à jour devient d'ailleurs inévitable dès lors que qu'un récepteur reçoit alternativement plusieurs types de services répondant à des permissions distinctes. Les modifications sont alors effectuées par l'envoi de nouvelles listes de permissions, transmises de manière sélective (au moyen d'identificateurs locaux) via le réseau de transmission des messages. Un inconvénient de ces envois de permissions via le réseau est qu'ils exposent à des risques de piratage des listes, ainsi qu'à la production frauduleuse de fausses listes de permissions visant à contrôler à distance des fonctionnalités normalement inaccessibles de récepteurs. De plus, chaque mise à jour de listes requiert un ensemble d'opérations fastidieuses, tant à l'émission qu'à la réception, qui doivent dans certaines circonstances être répétées souvent. La présente invention a pour objet un dispositif de transmission d'instructions de contrôle pour accès à des fonctionnalités d'un ou plusieurs récepteur, qui rend possible une mise à jour simplifiée des permissions accordées aux récepteurs, tant au niveau de l'émission que de la réception. De plus, le dispositif de transmission selon l'invention autorise une sécurité accrue de telles mises à jour vis-à-vis d'éventuelles manoeuvres frauduleuses. L'invention concerne aussi un dispositif de mise en #uvre d'instructions de contrôle apte à modifier les permissions au sein d'un récepteur, adapté au dispositif de transmission de l'invention. L'invention, qui s'applique en particulier au domaine de la télévision interactive, est également relative à un émetteur et un récepteur comprenant respectivement des dispositifs de transmission et de mise en oeuvre conformes à l'invention, et à des procédés, un programme d'ordinateur et un message correspondant. A cet effet, l'invention a pour objet un dispositif de transmission d'instructions de contrôle pour accès à des fonctionnalités d'au moins un récepteur. Ce dispositif de transmission comprend des moyens d'inscription d'identificateurs de permissions dans des messages destinés à ce récepteur. Selon l'invention, les moyens d'inscription sont prévus pour inscrire les identificateurs de permissions dans des messages d'annonce de services (announcements). Par message d'annonce de service , on entend un message envoyé en amont dans le cadre d'un service, donnant des informations et des instructions relatives à l'envoi ultérieur d'un ou plusieurs autres messages de ce service. Ces autres messages sont porteurs de contenu ( messages de contenu ) ou d'instructions de déclenchement immédiat ( déclencheurs ou triggers ). Le message d'annonce de service comprend un en-tête au format SAP (pour Session Announcement Protocol) et une charge utile au format SDP (pour Session Description Protocol). De manière surprenante, les permissions ne sont donc pas envoyées de manière centralisée, sous forme de listes blanches ou noires, mais spécifiquement pour chaque service concerné, au sein même du message d'annonce de service. Cette réalisation offre une grande souplesse de manoeuvre, car elle permet de s'adapter spécifiquement et en temps réel à chaque service. De plus, elle autorise une fiabilité accrue, car elle évite l'envoi de listes contenant par essence l'ensemble des informations de contrôle d'accès. Dans une forme avantageuse d'implémentation des permissions, chacun des messages d'annonce de services comprenant un champ d'authentification de longueur variable, les moyens d'inscription sont prévus pour inscrire les identificateurs de permissions dans ce champ d'authentification. Cette réalisation est intéressante par sa simplicité, car elle permet d'exploiter de manière très souple un champ déjà prévu dans le message d'annonce de service, sans avoir à ajouter un champ spécifique. Dans une autre forme avantageuse d'implémentation des permissions, chacun des messages d'annonce comprenant un champ de charge utile, les moyens d'inscription sont prévus pour inscrire les identificateurs de permissions dans ce champ de charge utile. De cette manière, on dispose de plus de souplesse dans la définition des permissions. Le dispositif de l'invention rend aussi possible une sécurisation accrue, comme exposé ci-après. Dans ce qui suit, on désigne par : - authentification , un processus relatif à une garantie d'origine et d'intégrité de messages transitant par un réseau, reposant sur l'utilisation de signatures numériques contenues dans les messages et produites au moyen de clés avant émission des messages, - cryptage (encryption), un processus de substitution à un texte en clair, d'un texte inintelligible et inexploitable en tant que tel, - décryptage , un processus de remplacement d'un texte crypté par un texte en clair, obtenu en ramenant le texte crypté à sa forme initiale, - chiffrement (encipherment), un processus de détermination d'un texte crypté à partir d'un message ou d'une portion d'un message, ce texte crypté étant utilisé soit en remplacement d'un texte en clair (cryptage), soit en tant que signature (authentification), - déchiffrement , un processus de reconstitution au moins partiel d'un texte en clair à partir d'un texte crypté, soit pour l'attestation de l'origine et de l'intégrité du message contenant le texte (authentification), soit pour le remplacement du texte crypté par le texte en clair (décryptage), - sécurisation , un processus de chiffrement d'un message ou d'une partie d'un message, à des fins d'authentification ou de cryptage, - identification , un processus d'utilisation d'un texte crypté reçu dans un message pour identifier ce message, soit par son origine et son intégrité (authentification), soit par son contenu (décryptage) ; pour l'authentification, l'identification peut comprendre un déchiffrement de la signature, ou un chiffrement de la partie du message ayant servi à la signature afin de comparer le résultat à la signature reçue. Le dispositif de transmission comprend de préférence des moyens de commande de chiffrement pour signature, d'au moins une partie de chacun des messages, cette partie incluant les identificateurs de permissions. On peut ainsi authentifier l'origine et le contenu des messages d'annonce, y compris en ce qui concerne les permissions, ce qui permet de réduire considérablement les risques d'interception d'un tel message d'annonce et de modification frauduleuse des permissions qu'il contient De préférence, les identificateurs de permissions du message d'annonce ne sont pas cryptés, de manière à autoriser une identification rapide des informations de contrôle. Ceci rend d'autant plus avantageux leur prise en compte dans la signature numérique apposée dans le message. Préférentiellement, les messages d'annonce sont des messages d'annonce de services ATVEF (c'est-à-dire selon la norme Advanced Television Enhancement Forum) et/ou de services système. Chaque message d'annonce ATVEF d'un service est suivi d'au moins un message de contenu HTTP (selon la méthode HyperText Transfer Protocol) puis d'un ou plusieurs déclencheurs du service. Les messages d'annonce système d'un service, généralement privé et en mutidiffusion (multicasting), sont quant à eux suivis d'un fichier binaire du service. Ces derniers messages d'annonce ont avantageusement une forme similaire à celle des messages d'annonce ATVEF. On trouvera une description détaillée portant sur l'utilisation de messages d'annonces de services autres que des messages d'annonce ATVEF, dans la demande de brevet européen déposée le 23 octobre 2000 ayant pour numéro de dépôt 00402921.1. Selon une première forme des permissions, au moins un des identificateurs de permissions porte sur des fonctionnalités d'accès, préférentiellement automatique, à un modem pour initier une connexion à un serveur en ligne d'un opérateur de services. Cet opérateur de services est avantageusement connecté au dispositif de transmission. Selon une deuxième forme des permissions, au moins un des identificateurs de permissions porte sur des fonctionnalités d'utilisation d'une connexion sécurisée à un serveur en ligne. Selon une troisième forme des permissions, au moins un des identificateurs de permissions porte sur des fonctionnalités d'accès, préférentiellement automatique, à au moins un espace de stockage pour lire des données ou écrire des données de manière permanente dans cet espace de stockage. Le ou les espaces de stockage sont de préférence un disque dur, une mémoire flash et/ou une carte à puce. Selon une quatrième forme des permissions, au moins un des identificateurs de permissions porte sur des fonctionnalités d'accès à un syntoniseur du récepteur pour modifier une chaîne courante. Les différentes formes des permissions sont avantageusement combinées dans les messages d'annonce. L'invention est également relative à un émetteur de messages, caractérisé en ce qu'il comporte un dispositif de transmission selon l'un quelconque des modes de réalisation de l'invention. Elle s'applique aussi à un dispositif de mise en #uvre d'instructions de contrôle pour accès à des fonctionnalités d'un récepteur. Ce dispositif de mise en #uvre comprend des moyens de lecture d'identificateurs de permissions dans des messages reçus par lui. Selon l'invention, les moyens de lecture sont prévus pour lire les identificateurs de permissions dans des messages d'annonce de services. De plus, le dispositif de mise en #uvre d'instructions est préférentiellement prévu pour recevoir les instructions de contrôle transmises par un dispositif de transmission d'instructions de contrôle conforme à l'un quelconque des modes de réalisation de l'invention. L'invention concerne aussi un récepteur de messages, caractérisé en ce qu'il comporte un dispositif de mise en #uvre selon l'invention. Ce récepteur est préférentiellement prévu pour recevoir les messages en provenance d'un émetteur de messages conforme à l'invention. L'invention a de plus pour objet un produit programme d'ordinateur. Selon l'invention, celui-ci comprend des fonctionnalités de mise en #uvre des moyens du dispositif de transmission, ou du dispositif de mise en #uvre, d'instructions de contrôle, conformes à l'un quelconque des modes de réalisation de l'invention. Par produit programme d'ordinateur , on entend un support de programme d'ordinateur, qui peut consister non seulement en un espace de stockage contenant le programme, tel qu'une disquette ou une cassette, mais aussi en un signal, tel qu'un signal électrique ou optique. L'invention s'applique également à un message destiné à être envoyé sur un réseau vers au moins un récepteur, ce message incluant au moins un identificateur de permission. Selon l'invention, ce message est un message d'annonce de service. De plus, il est de préférence obtenu par un dispositif de transmission conforme à l'un quelconque des modes de réalisation de l'invention. Un autre aspect de l'invention est un procédé de transmission d'instructions de contrôle pour accès à des fonctionnalités d'au moins un récepteur. Dans ce procédé, on inscrit des identificateurs de permissions dans des messages destinés au récepteur. Selon l'invention, on inscrit les identificateurs de permissions dans des messages d'annonce de services. De plus, ce procédé de transmission d'instructions de contrôle est préférentiellement mis en oeuvre au moyen d'un dispositif de transmission conforme à l'un quelconque des modes de réalisation de l'invention. Encore un autre aspect de l'invention est un procédé de mise en oeuvre d'instructions de contrôle pour accès à des fonctionnalités d'un récepteur. Dans ce procédé, on lit des identificateurs de permissions dans des messages reçus par le récepteur. Selon l'invention, on lit les identificateurs de permissions dans des messages d'annonce de services. De plus, ce procédé de mise en #uvre d'instructions de contrôle est préférentiellement mis en #uvre au moyen d'un dispositif de mise en #uvre conforme à l'invention. L'invention sera mieux comprise et illustrée au moyen des exemples suivants de réalisation et de mise en #uvre, nullement limitatifs, en référence aux figures annexées sur lesquelles : - la Figure 1 est un schéma de principe montrant un émetteur et un récepteur de messages conformes à l'invention, mettant en #uvre une transmission de permissions avec une première forme de sélection des clés de chiffrement / d'identification ; - la Figure 2 représente plus en détail un premier mode de réalisation de l'émetteur de la Figure 1, utilisable pour de l'authentification ; - la Figure 3 illustre le contenu d'un message d'annonce de service ATVEF contenant un champ d'authentification avec des identificateurs de permissions, envoyé par l'émetteur de la Figure 2 ; - la Figure 4 détaille le contenu du champ d'authentification de la Figure 3 ; - la Figure 5 illustre le contenu d'une version intermédiaire du message produit par l'émetteur de la Figure 2, avant remplissage du champ d'authentification ; - la Figure 6 montre des ensembles de diffusion générale (broadcasters) du type radiodiffuseurs, commandés par un serveur central, mettant en jeu des émetteurs conformes à celui de la Figure 2 ; - la Figure 7 représente plus en détail un premier mode de réalisation du récepteur de la Figure 1, utilisable pour l'authentification de messages de services ATVEF ou de services système envoyés par l'émetteur de la Figure 2 et pour la mise en #uvre de permissions correspondantes, et pour le décryptage de ces messages ; - la Figure 8 représente plus en détail un deuxième mode de réalisation de l'émetteur de la Figure 1, utilisable pour la transmission de permissions avec du cryptage et de l'authentification combinés ; - la Figure 9 illustre le contenu d'un message d'annonce de service ATVEF contenant un champ d'authentification contenant des permissions et un champ de cryptage, envoyé par l'émetteur de la Figure 8 ; - la Figure 10 schématise une bibliothèque de signature mettant en #uvre une deuxième forme de sélection des clés, avec blocs de clés, utilisée en variante dans l'émetteur de la Figure 1 ; - la Figure 11 schématise une bibliothèque d'authentification avec blocs de clés correspondant à la bibliothèque de la Figure 10, utilisée en variante dans le récepteur de la Figure 1 ; - la Figure 12 illustre le contenu d'une variante d'un message d'annonce de service ATVEF contenant un champ d'authentification avec des identificateurs de permissions, envoyé par l'émetteur de la Figure 2 ; - et la Figure 13 détaille le contenu du champ d'authentification de la Figure 12. Les figures sont considérées comme faisant partie intégrante de la divulgation. Sur les figures, des éléments identiques ou similaires sont désignés par les mêmes références. De plus, les entités fonctionnelles décrites et illustrées ne correspondent pas nécessairement à des entités physiquement distinctes des systèmes, mais peuvent par exemple consister en des fonctionnalités d'un même logiciel ou en des circuits d'un même composant. Sur les figures 3 à 5,9, 12 et 13, les nombres indiqués donnent, en bits, les répartitions de champs dans les messages représentés. Par ailleurs, les suffixes A et C sont utilisés pour désigner des entités d'authentification, le suffixe B pour des entités de cryptage et le suffixe A' pour des entités d'authentification après cryptage. Un ensemble d'émission et de réception comprend (Figure 1) un ou plusieurs émetteurs 1 de messages MSG via un réseau 5 vers un ou plusieurs récepteurs 2. Dans l'exemple détaillé ci-après, le réseau 5 est un réseau unidirectionnel de transmission par diffusion générale (broadcasting) et on s'intéresse à un serveur de diffusion général (associé à l'émetteur 1) émettant vers une pluralité de clients (associés respectivement aux récepteurs 2). Pour simplifier, on s'intéresse à un unique des émetteurs 1 et un unique des récepteurs 2. De façon très schématique, l'émetteur 1 est prévu pour recevoir un message MO et le transformer en le message MSG à émettre, par ajout de diverses informations destinées au transfert sur le réseau 5 et à la lecture du message MSG et d'éventuels messages ultérieurs par les récepteurs 2 appropriés. De manière correspondante, le récepteur 2 est prévu pour extraire du message MSG reçu le contenu signifiant représenté par le message MO. Le message MO est de préférence un message d'un type particulier (message d'annonce de service), comme détaillé plus bas, l'émetteur 1 et le récepteur 2 ne traitant pas tous les types de messages de la même manière. L'émetteur 1 comprend en particulier (Figure 1) divers éléments destinés à cette transformation du message MO, tels que notamment : - une unité d'inscription 14 de permissions, prévue pour insérer dans les messages MO des identificateurs de permissions PERM ; ces identificateurs PERM permettent de transmettre au récepteur 2 des instructions de contrôle pour accès à diverses fonctionnalités de ce dernier ; - un dispositif de sécurisation 3 de messages, pour définir des modalités judicieuses de chiffrement (signature ou cryptage) d'au moins une partie du message MO, déclencher ce chiffrement et insérer dans le message MO des informations d'exploitation des parties chiffrées, destinées au récepteur 2 ; dansl'exemple choisi, l'unité d'inscription 14 est en amont du dispositif de sécurisation 3, dans l'émetteur 1 ;en variantes, leurs positions sont inversées, ou au moins l'un de ces deux sous-ensembles est en amont de l'émetteur 1 ; - et une bibliothèque de chiffrement 15, par exemple une bibliothèque de liens dynamiques ou DLL (Dynamic Link Library), comprenant un module de chiffrement 17 ; convention, cette bibliothèque 15 est attribuée à l'émetteur 1, bien qu'en pratique il puisse s'agir d'un programme simplement accessible par l'émetteur au sens strict. Plus précisément, la bibliothèque de chiffrement 15 dispose d'une table indexée 16 de clés de chiffrement K,, K2...Kn' le module de chiffrement 17 étant prévu pour effectuer le chiffrement selon l'une des clés de chiffrement K,, en fonction d'instructions données par le dispositif de sécurisation 3 de messages. De plus, ce dernier comprend : - une unité de commande de chiffrement 11, capable de déclencher le module de chiffrement 17 en lui communiquant les informations nécessaires, en particulier sur le choix de la clé de chiffrement K, à utiliser ; - une unité de changement 12 de clé courante, permettant de modifier la clé courante K, à utiliser en envoyant des informations correspondantes à l'unité de commande de chiffrement 11 ; unité 12 repose par exemple sur des modifications aléatoires (tant en ce qui concerne les occurrences que les valeurs choisies) de la clé courante K,, avec possibilité d'intervention directe d'un utilisateur ; - et une unité d'inscription 13 dans le message MO d'un identificateur de clé KeyID, permettant d'indiquer à l'attention du récepteur 2 la clé courante de chiffrement K, choisie ; dans l'exemple présenté, cette unité d'inscription 13 effectue systématiquement l'enregistrement de l'identificateur de clé KeylD dans les messages MO du type concerné. De manière similaire, le récepteur 2 comprend en particulier : - une unité de lecture 24 des identificateurs de permissions PERM dans le message MSG reçu ; - un dispositif d'identification 4 de messages, pour définir les modalités pertinentes d'identification (par déchiffrement/chiffrement pour authentification ou décryptage) de la partie chiffrée du message MSG et déclencher cette identification ; - et une bibliothèque d'identification 25 comprenant un module d'identification 27, attribuée par convention au récepteur 2. Plus précisément, la bibliothèque d'identification 25 dispose d'une table indexée 26 de clés d'identification K'1, K'2.. K'n, correspondant une à une aux clés de chiffrement K1, K2...Kn de la bibliothèque de chiffrement 15. Le module d'identification 27 est prévu pour effectuer l'identification selon l'une des clés d'identification K'1, en fonction d'instructions données par le dispositif d'identification 4 de messages. De plus, ce dernier comprend : - une unité de commande d'identification 21, capable de déclencher le module d'identification 27 en lui communiquant les informations nécessaires, en particulier sur le choix de la clé d'identification K', à utiliser ; - et une unité d'extraction 23 dans le message MSG de l'identificateur de clé KeyID, donnant la clé courante d'identification K', choisie en correspondance avec la clé courante de chiffrement K', de l'émetteur 2. Le descriptif succinct fait précédemment est essentiellement fonctionnel, et il est exclusivement centré sur des spécificités en relation avec un ensemble particulier de sécurisation et d'identification de messages. L'émetteur 1 peut en réalité comprendre plusieurs dispositifs de sécurisation tels que celui référencé 15, pouvant être combinés. Par exemple, la sécurisation des messages combine cryptage et signature, et/ou des dispositifs distincts s'appliquent respectivement à différents types de messages. De façon similaire, le récepteur 2 peut comprendre plusieurs dispositifs d'identification. De telles possibilités apparaîtront plus clairement à la lumière des exemples ci-dessous de réalisations particulières. Une première modalité de réalisation de l'émetteur 1, référencée 1A (Figure 2), est appliquée à de l'authentification. Dans cette réalisation, l'émetteur 1A ne soumet aux opérations de sécurisation et d'inscription des identificateurs de permissions PERM que les messages MO d'annonce de service, les autres types de messages (tels que messages de contenus et triggers) n'y étant pas soumis. Les messages d'annonce de service considérés sont à titre d'illustration des messages d'annonce ATVEF ou d'annonce système, ces deux types de messages ayant une structure similaire dans les exemples considérés. Les messages MSG produits, notés MSG-A, sont soumis à une diffusion générale via le réseau 5. Dans l'exemple exposé, les clés de chiffrement K, (clés de signature) sont par ailleurs des clés privées, et les clés d'identification K', (clés d'authentification), des clés publiques qui peuvent être distribuées aux clients, y compris éventuellement par le réseau 5 (la transmission est alors de préférence sécurisée). A titre d'exemple plus spécifique, les clés de signature K, ont 596 octets chacune et les clés d'identification K', sont des clés de déchiffrement de 148 octets chacune, créées respectivement à partir des clés de signature K, et transférées en résident chez les clients. Les tables indexées 16 et 26 de clés respectivement de signature et d'authentification comprennent par exemple chacune 10 clés correspondantes. L'émetteur 1A comprend essentiellement : - un système de pilotage 31 de serveur, référencé 31A, incluant l'unité de changement 12 de clé courante, l'unité d'inscription 13 de l'identificateur de clé KeylD et l'unité d'inscription 14 des identificateurs de permissions PERM ; ce système de pilotage 31A est prévu pour recevoir d'une source d'informations 10 le message MO et pour produire un message M1, contenant l'identificateur de clé KeylD d'authentification, notée KeyID[SGN], et les identificateurs de permissions PERM mais sans signature ; - un serveur de diffusion générale 32A comportant notamment une unité de commande 37 commandant le fonctionnement de l'ensemble des éléments du serveur 32A (liens non représentés sur la figure 2 pour simplifier) et une base de données 33 prévue pour recueillir les messages M1 en provenance du système de pilotage 31A ; ce serveur de diffusion 32A est destiné à transformer le message M1 en le message MSG-A ; - et la bibliothèque de chiffrement 15, sous forme d'une bibliothèque d'authentification 15A. Le serveur de diffusion 32A comprend aussi deux modules agissant successivement sur le message M1 : un module de complètement 35 et un module d'encapsulation 36. Le module de complètement 35, qui contient l'unité de commande de chiffrement 11sous forme d'une unité de commande d'authentification 11A, est chargé d'inscrire des informations complémentaires (adresses Internet, ports...) dans le message M1 pour produire un message M2, et de faire appel à la bibliothèque d'authentification 15A pour produire une signature SGN et l'intégrer dans le message M2, produisant ainsi un message M3. La présence de l'identificateur de clé d'authentification KeyID[SGN] dans le message M2 envoyé à la bibliothèque 15A permet à cette dernière de sélectionner immédiatement la clé K, souhaitée pour générer la signature SGN. Avantageusement, on conserve en mémoire dans la bibliothèque 15A la clé courante de chiffrement K,. La sous-traitance par le serveur de diffusion 32A de la signature à la bibliothèque 15A, ainsi que l'enregistrement éventuel de la clé courante K, dans la bibliothèque 15A plutôt que dans le serveur 32A, permettent à ce dernier de garder un caractère général. Qui plus est, elles autorisent le système de pilotage 31A et la bibliothèque 15A à garder ensemble la maîtrise des opérations relatives aux identificateurs de clé KeyID[SGN] et de permissions PERM. D'autre part, l'ajout de la signature SGN en fin de chaîne, juste avant diffusion par le serveur de diffusion 32A, est intéressant car ce dernier peut ainsi être alimenté par de nombreux clients sans qu'il soit nécessaire de dupliquer la bibliothèque de signature 15A et les clés de chiffrement K,, et car la modification de l'identificateur de clé KeyID[SGN] peut être centralisée. De plus, en cas de compression et/ou de cryptage, la signature est faite après ces opérations. La signature SGN est calculée de préférence sur l'ensemble du message d'annonce M2, incluant l'en-tête (qui contient notamment les identificateurs KeyID[SGN] et PERM) et la charge utile, ce qui permet en particulier de détecter toute modification externe des données relatives à la clé courante KeyID[SGN] de signature (donc d'authentification par les clients) et aux permissions. Le module d'encapsulation 36 est destiné à transformer le message d'annonce M3 par découpage et ajout de couches pour transport sur le réseau 5. Dans l'exemple présenté, le module 36 génère des paquets IP (Internet Protocol) avec couches UDP (Unidirectional Data Protocol) /IP / SLIP (Serial Line IP). Pour des messages de contenus, le module 36 utilise au préalable le protocole UHTTP (Unidirectional Hypertext Transfer Protocol) et le format MIME (Multipurpose Internet Mail Extensions). Le message MSG-A ainsi signé permet à chacun des clients de vérifier l'authenticité des services fournis : si le client reconnaît la signature SGN comme valide, il ouvre des canaux d'écoute (sockets) pour les messages de contenus et éventuellement les triggers qui doivent suivre. Dans le cas contraire, le client refuse de prendre en considération le message d'annonce MSG-A. Pour authentifier la signature SGN, le client utilise l'identificateur de clé KeyID[SGN], qui lui permet de sélectionner immédiatement la clé d'identification K', appropriée dans la bibliothèque 25 d'identification correspondante (bibliothèque d'authentification). Il est ainsi en mesure de décider rapidement l'ouverture ou non de sockets et ainsi, de ne pas rater tout ou partie des paquets de contenus arrivant par la suite. Par exemple, lorsqu'un premier paquet de contenu est diffusé 500 ms après le message d'annonce, il faut impérativement que toutes les opérations de vérification de signature et d'ouverture de sockets aient été exécutées pendant ce laps de temps. Une mise en #uvre spécifique de l'émetteur 1A est illustrée ciaprès. Dans cet exemple, les messages d'annonce MSG-A du type ATVEF sont diffusés sur une adresse IP multicast 224. 0.1.113, port 2670, et ceux du type système sur une adresse IP multicast 235. 0.1.113, port 32670. Chacun des messages MSG-A (Figure 3) est constitué d'un en-tête au format SAP noté SAP-A et d'une charge utile au format SDP, l'en-tête SAP-A comprenant les champs suivants : - version V de SAP (3 bits, V=1) ; - ARTEC (5 bits) composé de cinq informations : - type d'adresse A (0 pour le protocole IPv4, 1 pour IPv6) ; - champ réservé R (0) ; -type de message T (0 pour un paquet d'annonce de session, 1 pour un paquet d'effacement de session) ; - champ de cryptage E (pour Encryption : pour SDP non crypté, 1 pour SDP crypté) ; - compression C (0 pour charge utile non compressée, 1 pour charge utile compressée) ; - longueur L-AUTH (valeur non signée sur 8 bits) d'un champ d'authentification AUTH référencé AUTH-A et inséré juste avant le SDP, exprimée en nombre de mots de 32 bits ; - identificateur de hash (algorithme de protection utilisé par Internet pour les signatures numériques) MSG ID HASH (sur 16 bits), la valeur de hash devant changer chaque fois qu'un champ du SDP est modifié ; lorsque cet identificateur vaut 0, le client doit toujours soumettre le SDP à une analyse syntaxique (parsing) ; - adresse IP notée ORIG (1 mot de 32 bits) de l'émetteur 1A, donc du serveur de diffusion 32A ; cette adresse peut être mise à 0.0.0.0 pour une valeur nulle de l'identificateur de hash et en l'absence de passage par un serveur mandataire (proxy) ; - et champ AUTH-A d'authentification, dont la longueur est déterminée par le paramètre L-AUTH. Le champ d'authentification AUTH-A (Figure 4) comprend non seulement un champ de signature SGN de 128 octets (taille choisie en fonction de limitation système) mais aussi un en-tête spécifique d'authentification noté ENT-A et occupant quatre octets, qui inclut les souschamps suivants : - version V de protocole utilisé (3 octets, V=1) ; - indicateur de remplissage (padding) P (1 bit), qui sert à signaler la présence de remplissage éventuel afin de parvenir à un champ d'authentification ayant une longueur totale multiple de double-mots (mots de 32 bits) ; dansle cas présent, P=0 (absence de padding) car le champ d'authentification a une longueur totale de 132 octets ; - type de l'authentification utilisée TYPE (4 bits) ; en l'espèce, TYPE=0 (format PGP pour Pretty Good Privacy) ; - drapeaux (flags) de permissions PERM (8 bits) ; - champ réservé (8 bits) pour une utilisation future ; - identificateur de clé KeyID[SGN] (8 bits). L'en-tête ENT-A contient donc deux octets particulièrement utiles pour les clients : ceux des champs KeyID[SGN] et PERM, qui permettent respectivement aux clients de déterminer immédiatement la bonne clé K', d'authentification et de connaître les permissions appropriées pour les messages ultérieurs du service (messages de contenu et triggers). Dans l'exemple présenté, l'octet disponible pour les drapeaux de permissions PERM est exploité sous la forme d'un masque de huit valeurs. Les drapeaux de permissions PERM portent sur les accès aux fonctionnalités suivantes, relatives à des ressources dites critiques du récepteur 2 (on donne au préalable les valeurs d'autorisation en notation hexadécimale) : - 0x0001 : accès à un modem du récepteur 2 pour initier une connexion à un serveur en ligne d'un opérateur de services associé à l'émetteur 1 ; - 0x0002 : accès à un modem du récepteur 2 pour initier une connexion à un serveur en ligne d'un opérateur de services quelconque ; - 0x0004 : utilisation d'une connexion sécurisée à un serveur en ligne ; - 0x0008 : accès à un disque dur du récepteur 2 pour y lire des données ou y écrire des données de manière permanente ; - 0x00010 :accès à une mémoire flash du récepteur 2 pour y lire des données ou y écrire des données de manière permanente ; - 0x00020 : accès à une carte à puce du récepteur 2 pour y lire des données ou y écrire des données de manière permanente ; - 0x00040 : accès à un syntoniseur (tuner) du récepteur 2 pour modifier une chaîne courante. Dans une variante de réalisation, l'octet disponible pour les permissions est utilisé sous la forme d'une table à 256 entrées, chacune des entrées correspondant à un niveau de permission unique. On obtient comme dans l'exemple ci-dessus huit permissions pouvant se combiner entre elles. Le nombre de permissions peut être étendu sans difficulté, notamment en incorporant le champ réservé d'un octet dans le champ de permissions (passage à seize permissions) et/ou en attribuant à l'en-tête ENT-A du champ d'authentification AUTH-A deux double-mots au lieu d'un. En fonctionnement, le système de pilotage 31 ajoute au message MO d'annonce de service un en-tête au format SAP, en y intégrant notamment les drapeaux de permissions PERM pour ce service et éventuellement un identificateur de clé KeyID[SGN] (ce dernier est configurable par le système de pilotage 31, mais par défaut, est déterminé par la bibliothèque 15A). La longueur L-AUTH du champ d'authentification AUTH-A est fixée à un double-mot (L-AUTH=1), de manière à y inscrire l'entête ENT-A sans la signature SGN. Le message M1 obtenu (Figure 5) contient alors dans le champ d'authentification AUTH1 (réduit à un en-tête ENT1) de l'en-tête au format SAP (noté SAP1) uniquement les drapeaux de permissions PERM et un champ réservé, initialisé à zéro. Ce message est reçu dans la base de données 33 du serveur de diffusion 32A Le module de complètement 35 vérifie alors si l'en-tête SAP1 est présent (sinon, il l'ajoute sans signature), inscrit dans M1 les informations complémentaires requises (retouche, dite patch, du SDP avec adresses et ports des messages de contenu et des triggers), et fait appel à la bibliothèque 15A en passant comme arguments une mémoire tampon (buffer) contenant le message M1 et une taille du buffer. La bibliothèque 15A effectue les opérations suivantes : - vérification si les drapeaux de permissions PERM sont présents ; si oui, poursuite normale des opérations ; sinon, retour au serveur de diffusion 32A avec code d'erreur ; dans une version améliorée, en cas d'absence des drapeaux de permissions PERM, attribution d'un masque par défaut ; - vérification si le message d'annonce de service M1 est déjà signé ; si oui, retour au serveur de diffusion 32A ; - sinon, mise à jour de la longueur L-AUTH à 132 octets (Ox21 double-mots), ajout et mise à jour de l'en-tête ENT-A du champ d'authentification AUTH-A, calcul (avec L-AUTH=1) et ajout dans le buffer de la signature SGN et mise à jour de la taille du buffer ; la signature SGN est déterminée à partir de l'ensemble de l'en-tête SAP1 (ne contenant pas le champ de signature SGN, puisque L-AUTH=1) et de la charge utile du message M1 ; elle est obtenue par l'algorithme RSA (Rivest - Shamir Adleman), au moyen du calcul d'un hash MD5 sur cet ensemble, de la récupération de la clé courante de signature K, appropriée et du calcul de la signature RSA sur hash avec cette clé K, ; dans une variante de réalisation, le champ d'authentification AUTH-A n'est pas du tout pris en compte pour la signature (L-AUTH=0 au lieu d'un double-mot) ; - et retour au serveur de diffusion 32A. Puis, le module d'encapsulation 36 encapsule le message M3 ainsi obtenu, avant diffusion générale sur le réseau 5. Avec cette technique, la signature n'est calculée qu'une fois par service (elle est calculée sur le message d'annonce), que ce service soit envoyé en carrousel ou en une occurrence (one shot). Pour modifier l'identificateur de clé KeyID[SGN], on envoie par exemple au serveur de diffusion 32A un message au travers d'une interface pour la programmation d'applications ou API (Application and Programming Interface), le serveur 32A se contentant alors de notifier la bibliothèque 15A de la nouvelle valeur de cet identificateur - la modification est par exemple effectuée systématiquement tous les mois. Dans un exemple illustratif ci-dessous de messages d'annonce de service en entrée (M1) et en sortie (MSG-A) du serveur de diffusion 32A, on indique en caractères gras et entre crochets l'en-tête SAP1, l'en-tête (ENT1, ENT-A) du champ d'authentification (AUTH1, AUTH-A) étant souligné, et en caractères normaux la charge utile (les notations sont hexadécimales). Le message M1, associé à L-AUTH=Ox01, PERM=Ox27 et à trois octets réservés valant 0x00, est le suivant : 00000000[2001 0000 53AA OB8D 2700 0000]763D 300A ...S...'...v=0. 00000010 6F3D 2D20 3935 3530 3035 3931 3320 3935 o=- 955005913 95 00000020 3530 3035 3931 3320 494E 2049 5034 2031 5005913 IN IP4 1 00000030 3732 2E33 302E 3930 2E31 3630 OA73 3D63 72.30.90.160.s=c 00000040 6D6F 6E63 686F 6978 OA65 3D64 7570 6F6E monchoix.e=dupon 00000050 7440 7468 6D75 6C74 692E 636F 6DOA 703D t@thmulti.com.p= 00000060 2B31 2D36 3537 2D34 3733 2D34 3833 300A +1-657-473-4830. 00000070 613D 6C61 6E67 3A65 6EOA 613D 7476 652D a=lang:en.a=tve- 00000080 656E 6473 3A33 3030 OA61 3D74 7665 2D74 ends:300.a=tve-t 00000090 7970 653A 7072 696D 6172 790A 613D 7476 ype:primary.a=tv OOOOOOAO 652D 6964 3A64 3631 3633 6164 612D 3766 e-id:d6163ada-7f OOOOOOBO 6164 2D33 6235 342D 6262 3839 2D66 3166 ad-3b54-bb89-flf OOOOOOCO 6161 3430 3736 6637 620A 613D 7476 652D aa4076f7b.a=tveOOOOOODO 7072 6F66 696C 653A 310A 743D 3020 300A profile:l.t=O 0. OOOOOOEO 6D3D 6461 7461 2032 3238 3530 2074 7665 m=data 22850 tve OOOOOOFO 2D74 7269 6767 6572 OA63 3D49 4E20 4950 -trigger.c=IN IP 00000100 3420 3232 372E 3337 2E33 322E 3433 OA6D 4 227.37.32.43.m 00000110 3D64 6174 6120 3232 3835 3120 7476 652D =data 22851 tve- 00000120 6669 6C65 OA63 3D49 4E20 4950 3420 3232 file.c=IN IP4 22 00000130 342E 3337 2E33 322E 3434 OA 4. 37.32.44. Le message MSG-A obtenu après traitement du message MO par le serveur de diffusion 32A, associé à L-AUTH=Ox21, PERM=Ox27 et KeyID=0x07, est le suivant : 00000000[2021 0000 53AA 0B8D 2027 0007 6797 BE9E !..S... '..g... 00000010 7169 8F8D FDF1 B330 38FF 957C DOA2 B515 qi.....08..#.... 00000020 1F98 DABC CB04 9F03 OEB8 3D27 E5AA 047A ..........='...z 00000030 35AF F2FF DC65 4F04 28E3 CA3F 948D 1D8A 5....e0.(..?.... 00000040 4540 D763 DB68 3ADD CAEF 5EB1 4116 F939 E@.c.h:...^.A..9 00000050 7C29 862F E7B8 75C1 081C 3830 5A55 AEC2 #)./..u...80ZU.. 00000060 1031 62CO E52D AC19 1CCF 7471 D28E 8997 .lb..-....tq.... 00000070 7F46 9473 4F2A B5EF 8047 2DE9 87EF A49E .F.sO*...G-..... 00000080 4E90 5DB7 0981 C001 DB17 F07F]763D 300A N.].........v=0. 00000090 6F3D 2D20 3935 3530 3035 3931 3320 3935 o=- 955005913 95 OOOOOOAO 3530 3035 3931 3320 494E 2049 5034 2031 5005913 IN IP4 1 OOOOOOBO 3732 2E33 302E 3930 2E31 3630 OA73 3D63 72.30.90.160.s=c OOOOOOCO 6D6F 6E63 686F 6978 OA65 3D64 7570 6F6E monchoix.e=dupon OOOOOODO 7440 7468 6D75 6C74 692E 636F 6DOA 703D t@thmulti.com.p= OOOOOOEO 2B31 2D36 3537 2D34 3733 2D34 3833 300A +1-657-473-4830. OOOOOOFO 613D 6C61 6E67 3A65 6EOA 613D 7476 652D a=lang:en.a=tve- 00000100 656E 6473 3A33 3030 OA61 3D74 7665 2D74 ends:300.a=tve-t 00000110 7970 653A 7072 696D 6172 790A 613D 7476 ype:primary.a=tv 00000120 652D 6964 3A64 3631 3633 6164 612D 3766 e-id:d6163ada-7f 00000130 6164 2D33 6235 342D 6262 3839 2D66 3166 ad-3b54-bb89-flf 00000140 6161 3430 3736 6637 620A 613D 7476 652D aa4076f7b.a=tve- 00000150 7072 6F66 696C 653A 310A 743D 3020 300A profile:l.t=0 0. 00000160 6D3D 6461 7461 2032 3238 3530 2074 7665 m=data 22850 tve 00000170 2D74 7269 6767 6572 OA63 3D49 4E20 4950 -trigger.c=IN IP 00000180 3420 3232 372E 3337 2E33 322E 3433 OA6D 4 227.37.32.43.m 00000190 3D64 6174 6120 3232 3835 3120 7476 652D =data 22851 tve- 000001AO 6669 6C65 OA63 3D49 4E20 4950 3420 3232 file.c=IN IP4 22 000001BO 342E 3337 2E33 322E 3434 OA 4.37.32.44. Dans une implémentation particulière d'émetteurs 1A (Figure 6), un système de pilotage central 40 d'un opérateur de service, comprenant un serveur central 45, est connecté à des broadcasters 41,42 et 43 via des liaisons spécialisées (leased lines) 46. Chacun des broadcasters 41-43 comprend un serveur de diffusion 32, du type de celui 32A détaillé plus haut, ainsi qu'un dispositif de diffusion 47 de programmes audiovisuels et un encodeur VBI référencé 48, chargé d'encoder des informations en provenance du serveur 32 et du dispositif 47 et de les diffuser à l'antenne 49. En fonctionnement, le système de pilotage central 40 obtient de diverses sources (broadcasters, publicitaires, fournisseurs de contenu...) des informations sur des services à diffuser, programme leur diffusion et finalement, les met à disposition du serveur de diffusion 32 peu avant leur diffusion. Il garantit notamment l'authenticité de clés publiques par la délivrance de certificats numériques 51,52 et 53 respectivement aux broadcasters 41 à 43. Ce système de pilotage central 40 remplit aussi les fonctions du système de pilotage 31 décrit plus haut, de telle sorte que les messages MSG d'annonce de service diffusés par les broadcasters 41 à 43 peuvent sélectivement être renseignés sur les permissions et être signés au moyen de clés variables, sans entraîner de délais pénalisants d'authentification à la réception. Chacun des récepteurs 2 comprend en particulier (Figure 7) : - un pilote VBI référencé 61, prévu pour extraire une charge utile à partir d'informations reçues des émetteurs 1A (tels que les broadcasters 41 à 43) et comprenant un champ WST (World Standard Teletext), à calculer des codes de contrôle d'erreurs FEC (Forward Error Correction) et à commander un décodage de trames SLIP de la charge utile ; - un module de décapsulation 62 de couches de transport sur le réseau 5, capable de recevoir du pilote 61 les trames SLIP décodées et en extraire, après décodage, le contenu des trames IPIUDP, sous la forme d'un en-tête au format SAP et d'une charge utile au format SDP pour les messages d'annonces de services MSG ; - un navigateur (browser) 63, pourvu d'un dispositif d'identification 4 et d'une unité de lecture 24 de permissions (respectivement référencés 4N et 24N), du type de ceux décrits plus haut, - un chargeur (loader) 67, pourvu d'un dispositif d'identification 4 et d'une unité de lecture 24 de permissions optionnelle (respectivement référencés 4C et 24C), du type de ceux décrits plus haut, - et une bibliothèque d'authentification du type de celle référencée 25 décrite plus haut ; la table indexée 26 de clés est stockée dans une mémoire permanente du récepteur 2, par exemple du type mémoire flash, dans un code de la bibliothèque 25. Le navigateur 63 est prévu pour effectuer les fonctions suivantes à la réception de chaque message d'annonce de service MSG-A : - récupérer l'en-tête et la charge utile du message MSG-A par un socket 64 d'écoute ; - appeler une fonction de vérification de signature dans la bibliothèque 25, en lui passant en entrée un pointeur sur le message MSGA; - et en cas de succès de l'authentification, ouvrir des sockets 65 et 66 d'écoute respectivement pour les messages de contenu et les triggers ultérieurs, en appliquant les permissions indiquées par les drapeaux de permissions PERM du message MSG-A pour préciser l'accès aux fonctionnalités du navigateur 63 devant s'appliquer à l'application diffusée. La fonction de vérification de signature de la bibliothèque 25 exécute plus précisément les opérations suivantes : - calcul d'un hash MD5 sur l'ensemble de l'en-tête SAP-A hors signature et de la charge utile, l'indicateur L-AUTH donnant la longueur du champ d'authentification AUTH-A étant mise à 1 ; dans une variante correspondant à celle indiquée pour le calcul de signature, le champ d'authentification AUTH-A n'est pas pris en compte pour l'authentification, l'indicateur L-AUTH étant mis à 0 ; - récupération de l'identificateur de clé KeyID[SGN] dans le champ d'authentification AUTH-A de l'en-tête SAP-A et sélection de la clé d'authentification K', appropriée ; - vérification de la signature SGN du champ d'authentification AUTH-A, du type RSA, par re-calcul sur le hash de la signature au moyen de la clé K', sélectionnée ; en cas de signature invalide, renvoi de la valeur 0 ; - si la signature SGN est valide renvoi des drapeaux de permissions PERM. Ainsi, la charge utile du message MSG-A n'est prise en compte qu'en cas d'authentification réussie. Dans le cas contraire, aucun socket d'écoute n'est ouverte pour les messages ultérieurs du service annoncé et le client reste sourd aux données qui arrivent. Le fonctionnement du chargeur 67 est similaire pour un message d'annonce système, reçu via un socket 68 d'écoute : un socket 69 n'est ouverte pour les messages de contenu ultérieurs que si le message est authentifié, au moyen d'un appel à la librairie 25. Une deuxième modalité de réalisation de l'émetteur 1, référencée 1B (Figure 8), est appliquée à une combinaison de cryptage et d'authentification. Cette réalisation diffère de la précédente essentiellement par la présence dans l'émetteur 1B d'éléments de cryptage, complémentaires aux éléments de signature et prévus pour agir en amont de ces derniers. Les éléments de cryptage et ceux de signature reposent respectivement sur la sélection de deux clés courantes de chiffrement dans deux tables indexées 16 de clés (Figure 1), et font appel à respectivement une bibliothèque de cryptage 15B et une bibliothèque de signature 15A', du type de la bibliothèque de chiffrement 15 décrite plus haut de manière générale. Le récepteur 2 inclut une table indexée de décryptage correspondant à la table indexée de clés de cryptage, ces clés de décryptage étant préférentiellement privées. Les tables indexées de cryptage et de décryptage comprennent par exemple chacune 10 clés. Ainsi, le système de pilotage 31, référencé 31 B, comprend à la fois des unités de changement 12 de clé courante et des dispositifs de sécurisation 13 de messages pour le cryptage (respectivement 12B et 13B) et pour la signature après cryptage (respectivement 12A' et 13A'). De plus, le serveur de diffusion 32, référencé 32B, comprend un module de complètement et de cryptage 34 incluant une unité de commande de cryptage 11B et un module de signature 38 en aval du module 34, incluant une unité de commande de signature 11A', les unités de commande 11B et 11A' étant du type de l'unité de commande chiffrement 11. Ce serveur 32B intègre à l'en-tête au format SAP un champ d'authentification AUTH, référencé AUTH-B, de manière similaire au premier mode de réalisation. Le module de complètement et de cryptage 34 est chargé d'ajouter des informations complémentaires requises dans le message M1 comme dans le mode de réalisation précédent, et de faire appel à la bibliothèque de cryptage 15B pour crypter le message M4 ainsi obtenu, en lui transmettant un identificateur de clé de cryptage KeyID[CRYPT]. Le module de chiffrement 17 de la bibliothèque 15B (Figure 1) procède alors au cryptage de la charge utile, mais pas des données initiales de l'en-tête ni du champ d'authentification AUTH-B. L'identificateur de clé KeyID[CRYPT] est par exemple généré aléatoirement. Le module de signature 38 est prévu pour recevoir de la bibliothèque de cryptage 15B un message M5 résultant de ce cryptage et comprenant en particulier un identificateur de clé d'authentification KeyID[SGN], et pour faire appel à la bibliothèque de signature 15A' afin d'obtenir un message signé M6. Le module de chiffrement 17 de la bibliothèque 15A' (Figure 1) détermine et appose une signature portant sur l'ensemble du message M5, au moyen de la clé courante donnée par l'identificateur de clé KeyID[SGN], comme dans le mode de réalisation précédent. Le module d'encapsulation 36 joue le même rôle que précédemment et permet d'obtenir le message MSG à diffuser, noté MSG-B. A titre d'illustration (Figure 9), le message MSG-B comporte, outre sa charge utile, un en-tête au format SAP référencé SAP-B qui est structuré de la manière suivante : - champs V, ARTEC, L-AUTH, MSG ID HASH et AUTH-B similaires à ceux du premier mode de réalisation ; - identificateur de clé de cryptage KeyID[CRYPT] (1 doublemot) ; - indicateur de délai dépassé TIMEOUT (1 double-mot), utile lorsque la charge utile est cryptée et que l'émission du message d'annonce passe par un proxy ; - indicateur de padding P (1 bit), signalant un remplissage avant cryptage ; le dernier octet de la charge utile décryptée donne alors le nombre d'octets de padding ajoutés ; - et champ aléatoire (31 bits) contenant un vrai nombre aléatoire et destiné à être jeté après décryptage. L'ensemble CRYPT des champs cryptés est constitué de l'indicateur P, du champ aléatoire et de la charge utile, tandis que l'identificateur KeyID[CRYPT] et le champ TIMEOUT forment un en-tête de cryptage ENT-CRYPT non crypté. Dans une variante de réalisation applicable à l'un quelconque des couples de bibliothèques de chiffrement et d'identification associées (figures 10 et 11), la bibliothèque de chiffrement 75 comprend une table indexée 76 de blocs B1, B2... Bn de clés de chiffrement, au lieu d'une table de clés. Chacun des blocs B, inclut lui-même plusieurs clés Ki 1, Ki,2... ki,@i, dont le nombre peut varier selon le bloc considéré. De façon similaire, la bibliothèque d'identification 85 comprend une table indexée 86 de blocs B'1, B'2... B'n de clés d'identification, chacun des blocs B', incluant plusieurs clés K'i,1,K',2... K',,,, correspondant respectivement aux clés K,.,, K,2... Ki,@i des blocs B, de la bibliothèque de chiffrement 75. La connaissance de l'identificateur de clé KeylD ne permet donc pas de connaître de manière univoque la clé K,, choisie pour le chiffrement par le module de chiffrement 77, donc la clé d'identification K'i@ associée que doit utiliser le module d'identification 87 de la bibliothèque 85, mais seulement les blocs B, et B', auxquels ces clés appartiennent respectivement. Toutes les clés du bloc B', identifié doivent donc être essayées successivement jusqu'au succès du décryptage. Selon une variante d'implémentation des identificateurs, les identificateurs de clé d'authentification KeyID[SGN] et/ou de permissions PERM sont extérieurs au champ d'authentification AUTH dans l'en-tête du message MSG. Ainsi, on peut chiffrer les messages pour authentification en incluant ces identificateurs dans le calcul de signature SGN, mais tout en en excluant le champ d'authentification AUTH (L-AUTH=0). Dans un autre mode de réalisation (Figures 12 et 13), les drapeaux de permission PERM sont disposés dans le champ de charge utile. Selon l'exemple illustré, le message MSG d'annonce de service produit, référencé MSG-C, contient un en-tête au format SAP, noté SAP-C, sans permissions mais avec un champ réservé de deux octets dans l'entête ENT-C du champ d'authentification AUTH-C. Sa charge utile au format SDP, notée SDP-C, inclut les drapeaux de permissions PERM sur deux octets, par exemple en début de champ. Le champ de permissions nécessite plus d'espace en charge utile qu'en en-tête, car il requiert une écriture en format texte et non plus binaire, et une mention d'identification du champ de permissions. REVENDICATIONS 1. Dispositif de transmission d'instructions de contrôle pour accès à des fonctionnalités d'au moins un récepteur (2), ledit dispositif de transmission comprenant des moyens d'inscription (14) d'identificateurs de permissions (PERM) dans des messages (MSG) destinés audit récepteur (2), caractérisé en ce que les moyens d'inscription (14) sont prévus pour inscrire les identificateurs de permissions (PERM) dans des messages d'annonce (MSG) de services. 2. Dispositif de transmission selon la revendication 1, caractérisé en ce que chacun desdits messages d'annonce (MSG-A, MSG-B) comprenant un champ d'authentification (AUTH-A, AUTH-B) de longueur variable, les moyens d'inscription (14) sont prévus pour inscrire les identificateurs de permissions (PERM) dans ledit champ d'authentification. 3. Dispositif de transmission selon l'une des revendications 1 ou 2, caractérisé en ce que chacun desdits messages d'annonce (MSG-C) comprenant un champ de charge utile (SDP-C), les moyens d'inscription (14) sont prévus pour inscrire les identificateurs de permissions (PERM) dans ledit champ de charge utile. 4. Dispositif de transmission selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend aussi des moyens de commande de chiffrement (11-A, 11-A') pour signature, d'au moins une partie de chacun desdits messages (MSG), ladite partie incluant les identificateurs de permissions (PERM). 5. Dispositif de transmission selon l'une quelconque des revendications précédentes, caractérisé en ce que lesdits messages d'annonce (MSG) sont des messages d'annonce de services ATVEF et / ou de services système. 6. Dispositif de transmission selon l'une quelconque des revendications précédentes, caractérisé en ce qu'au moins un desdits identificateurs de permissions (PERM) porte sur des fonctionnalités d'accès, préférentiellement automatique, à un modem pour initier une connexion à un serveur en ligne d'un opérateur de services. 7. Dispositif de transmission selon la revendication 6, caractérisé en ce que ledit opérateur de services est connecté audit dispositif de transmission. 8. Dispositif de transmission selon l'une quelconque des revendications précédentes, caractérisé en ce qu'au moins un desdits identificateurs de permissions (PERM) porte sur des fonctionnalités d'utilisation d'une connexion sécurisée à un serveur en ligne. 9. Dispositif de transmission selon l'une quelconque des revendications précédentes, caractérisé en ce qu'au moins un desdits identificateurs de permissions (PERM) porte sur des fonctionnalités d'accès, préférentiellement automatique, à au moins un espace de stockage pour lire des données ou écrire des données de manière permanente dans ledit espace de stockage. 10. Dispositif de transmission selon la revendication 9, caractérisé en ce que ledit espace de stockage est un disque dur, une mémoire flash et/ou une carte à puce. 11. Dispositif de transmission selon l'une quelconque des revendications précédentes, caractérisé en ce qu'au moins un desdits identificateurs de permissions (PERM) porte sur des fonctionnalités d'accès à un syntoniseur dudit récepteur (2) pour modifier une chaîne courante. 12. Emetteur (1) de messages (MSG) caractérisé en ce qu'il comporte un dispositif de transmission selon l'une quelconque des revendications 1 à 11. 13. Dispositif de mise en #uvre d'instructions de contrôle pour accès à des fonctionnalités d'un récepteur (2), ledit dispositif de mise en oeuvre comprenant des moyens de lecture (24) d'identificateurs de permissions (PERM) dans des messages (MSG) reçus par ledit récepteur (2), caractérisé en ce que les moyens de lecture (24) sont prévus pour lire les identificateurs de permissions (PERM) dans des messages d'annonce (MSG) de services, ledit dispositif de mise en #uvre d'instructions étant préférentiellement prévu pour recevoir lesdites instructions de contrôle transmises par un dispositif de transmission d'instructions de contrôle conforme à l'une quelconque des revendications 1 à 11. 14. Récepteur (2) de messages (MSG) caractérisé en ce qu'il comporte un dispositif de mise en #uvre selon la revendication 13, ledit récepteur étant préférentiellement prévu pour recevoir lesdits messages (MSG) en provenance d'un émetteur (1) de messages conforme à la revendication 12. 15. Produit programme d'ordinateur, caractérisé en ce qu'il comprend des fonctionnalités de mise en #uvre desdits moyens (14,24) du dispositif de transmission d'instructions de contrôle conforme à l'une quelconque des revendications 1 à 11 ou du dispositif de mise en #uvre d'instructions de contrôle conforme à la revendication 13. 16. Message (MSG) destiné à être envoyé sur un réseau vers au moins un récepteur (2), ledit message incluant au moins un identificateur de permission (PERM), caractérisé en ce que ledit message (MSG) est un message d'annonce de service, ledit message (MSG) étant de préférence obtenu au moyen d'un dispositif de transmission selon l'une quelconque des revendications 1 à 11. 17. Procédé de transmission d'instructions de contrôle pour accès à des fonctionnalités d'au moins un récepteur (2), selon lequel on inscrit des identificateurs de permissions (PERM) dans des messages (MSG) destinés audit récepteur (2), caractérisé en ce qu'on inscrit les identificateurs de permissions (PERM) dans des messages d'annonce (MSG) de services, ledit procédé de transmission d'instructions de contrôle étant préférentiellement mis en #uvre au moyen d'un dispositif de transmission conforme à l'une quelconque des revendications 1 à 11. 18. Procédé de mise en #uvre d'instructions de contrôle pour accès à des fonctionnalités d'un récepteur (2), selon lequel on lit des identificateurs de permissions (PERM) dans des messages (MSG) reçus par ledit récepteur (2), caractérisé en ce qu'on lit les identificateurs de permissions (PERM) dans des messages d'annonce (MSG) de services, ledit procédé de mise en #uvre d'instructions de contrôle étant préférentiellement mis en #uvre au moyen d'un dispositif de mise en #uvre conforme à la revendication 13.