Brevet FR2831360A1 — publié le 20030425

L'invention concerne un protocole de gestion à distance du contrôle d'accès à des informations chiffrées ou embrouillées. Le contrôle d'accès à des informations chiffrées à connu un essor sans précédent, grâce à l'avènement des technologies de transmission d'informations en réseau. Ces techniques, ayant pour objet d'assurer la transmission d'informations auprès du plus grand nombre d'utilisateurs, permettent à l'heure actuelle de proposer un nombre de services très important, en raison de l'accroissement à un rythme de doublement des capacités de calcul et de mémorisation des-circuits intégrés tous les cinq ans environ, et, en conséquence, de la puissance de traitement des informations transmises. Les techniques du contrôle d'accès à des informations chiffrées ont, à l'origine, été proposées dans le cadre d'applications dans la transmission et l'affichage d'informations sur des récepteurs de télévision à des fins de distraction, d'information ou autre. De telles techniques ont, en particulier, trouvé application au système dit"ANTIOPE"pour Acquisition Numérique et Télévisualisation d'Images Organisées en Pages d'Ecriture, au système dit"TITAN"pour Terminal Interactif de Télétexte à Appel par Numérotation ou au système dit"EPEOS" pour Enregistrement Programmé des Emissions sur Ordre des Sources. Ces systèmes utilisant pour la diffusion de l'information une procédure dite"DIDON"pour Diffusion de Données Numériques, concernent un système de videotext diffusé, un système de videotext interactif, respectivement un système de messagerie de programmes par télécommande, depuis une source d'émission, de l'action d'enregistrement par un équipement récepteur, tel qu'un magnétoscope. L'application du processus de contrôle d'accès à de tels systèmes a été proposée. Une telle application pose le problème du verrouillage de l'information à l'émission, verrouillage par chiffrement ou embrouillage, puis du déverrouillage de l'information chiffrée ou verrouillée à la réception, comptetenu des critères d'habilitation des usagers et des spécificités du système à contrôler. En particulier un système de contrôle d'accès appliqué aux systèmes précités a été développé et décrit dans la demande de brevet français 79 02995 (2 448 825) mise à la disposition du public le 5 septembre 1980. Dans le système de contrôle d'accès précité, on utilise un processus à double clé comprenant, une clé de service, qui permet de verrouiller l'information, cette clé étant changée de manière aléatoire à des intervalles courts, de l'ordre de quelques minutes, et une clé dite d'abonnement, pouvant prendre plusieurs valeurs Ci selon le type d'abonnement. Cette clé change elle aussi de manière aléatoire, à des intervalles plus longs, de l'ordre du mois. Elle est inscrite sur un support d'abonnement, tel qu'une carte intelligente ou carte de crédit, lequel est introduit dans chaque poste récepteur. Des messages particuliers sont composés à l'émission et transmis avec les données verrouillées. Ces messages permettent, de restituer la clé de service, dans le poste récepteur, puis d'ouvrir la serrure électronique qui verrouille l'information verrouillée transmise. Un tel processus a été l'objet de nombreux développements technologiques, lesquels ont donné lieu à l'établissement de la norme UTE C90-007"Système d'accès conditionnel pour systèmes de diffusion numérique". De manière générale, à partir des enseignements de la demande de brevet français précitée, les dispositions retenues par le texte de la norme précédemment mentionnée ont pour objet la définition de spécifications de systèmes de contrôle d'accès conditionne à des informations embrouillées ou chiffrées qui permettent de s'assurer que les programmes de télévision, de radio, des services de consultation de données ou d'autres types de services ne sont accessibles qu'aux seuls usagers qui remplissent des conditions et satisfont à des critères bien précis, liés essentiellement à un paiement de la consultation des programmes ou des services précités. Dans ce but, de tels systèmes permettent d'assurer la gestion à distance du contrôle d'accès à des informations embrouillées au moyen d'une clé de service et transmises entre un centre d'émission et au moins un poste récepteur. Le centre d'émission comprend un module de calcul d'un mot de contrôle, CW, contenant au moins la clé de service, et un module de chiffrement du mot de contrôle, CW, au moyen d'une clé d'exploitation, SOK. Un module générateur de messages de contrôle des titres d'accès, messages ECM, contenant au moins le mot de contrôle chiffré et des paramètres de contrôle de titres d'accès et un module générateur de messages de gestion des titres d'accès, messages EMM, sont prévus. Les messages ECM et les messages EMM peuvent être multiplexés dans le flux des informations chiffrées transmises. Chaque poste récepteur comporte au moins un terminal de désembrouillage des informations embrouillées et un module de contrôle d'accès comprenant un processeur de sécurité (PS) hébergé par exemple par une carte de contrôle d'accès introduite dans le terminal. Le processeur de sécurité comporte la clé d'exploitation SOK et des titres d'accès, mémorisés en mémoire interne sécurisée, et un module de déchiffrement, le processeur de sécurité permettant, à partir de la clé d'exploitation et du mot de contrôle chiffré de restituer la clé de service, sur critère de vérification de l'un des titres d'accès inscrits, à partir des paramètres de contrôle des titres d'accès. Chaque terminal de désembrouillage comprend un module de désembrouillage permettant, à partir de la clé de service restituée, de déchiffrer l'information embrouillée transmise, pour utilisation par l'utilisateur abonné habilité détenteur de la carte de contrôle d'accès. De tels systèmes, développés dans le cadre des dispositions de la norme UTE C 90-007 précitée, donnent satisfaction, dans la mesure où, d'une part, les calculs de restitution de la clé de service et les secrets, clé d'exploitation, nécessaires à l'exécution de ces calculs, sont localisés en zone mémoire protégée de la carte de contrôle d'accès, la clé d'exploitation n'étant jamais accessible par lecture externe, et où, d'autre part, la transmission et la gestion de titres d'accès, mémorisés dans la mémoire du processeur de sécurité, est rendue totalement indépendante du contrôle d'accès en tant que tel, conditionné à la détention de la clé d'exploitation courante, afin de permettre la restitution de la clé de service courante, puis le désembrouillage des données embrouillées au moyen de cette dernière. La présente invention a pour objet la mise en ceuvre d'un protocole de gestion à distance du contrôle d'accès à des informations embrouillées permettant une application du processus de contrôle d'accès à tout type de service en ligne, lié en particulier à des opérations de transaction électronique, indépendamment du type de transmission des données embrouillées. Un autre objet de la présente invention est, en particulier, la mise en oeuvre d'un protocole de gestion à distance du contrôle d'accès à des informations chiffrées d'un très haut niveau de sécurité, le dialogue terminal de désembrouillage/processeur de sécurité, point d'attaque privilégié des pirates et perceurs de chiffre, étant soumis à un protocole de sécurisation local. Un autre objet de la présente invention est, en outre, la mise en oeuvre de messages spécifiques, tels que des messages EPM, constituant des messages de liaison de gestion des titres d'accès et assurant la liaison entre message ECM et message EMM. Un autre objet de la présente invention est, enfin, la mise en oeuvre d'un protocole de gestion à distance du contrôle d'accès à des informations embrouillées, appliqué à des services les plus divers, tels que la conduite sécurisée en ligne de transaction électronique, par l'intermédiaire d'une voie de retour grâce à la transmission de messages programmables, ce qui permet le traitement de variables d'état représentatives de situations et d'environnements les plus divers, indépendamment du type de service et de transaction mis en oeuvre. Le protocole de gestion à distance du contrôle d'accès à des informations embrouillées au moyen d'une clé de service et transmises en réseau, objet de l'invention, est mis en oeuvre entre un centre d'émission et au moins un poste récepteur. La transmission des informations embrouillées est accompagnée d'un mot de contrôle contenant au moins la clé de service, mot de contrôle chiffré au moyen d'une clé d'exploitation. Cette transmission du cryptogramme du mot de contrôle est effectuée au moyen de messages de contrôle de titres d'accès, messages ECM, contenant au moins ce mot de contrôle chiffré et des paramètres de contrôle de titres d'accès. Les messages ECM sont transmis et multiplexés dans le flux des informations embrouillées avec des messages de gestion de titres d'accès, messages EMM. Chaque poste récepteur comporte au moins un terminal de désembrouillage des informations embrouillées et un module de contrôle d'accès muni d'un processeur de sécurité. Le processeur de sécurité comporte la clé d'exploitation et des titres d'accès inscrits alloués à un utilisateur abonné mémorisés en mémoire protégée du processeur de sécurité et permet à partir de la clé d'exploitation et du mot de contrôle chiffré de restituer la clé de service sur critère de vérification des titres d'accès inscrits. Chaque terminal de désembrouillage permet à partir de la clé de service restituée le désembrouillage des informations embrouillées pour utilisation par un utilisateur abonné habilité. Il est remarquable en ce qu'il consiste au moins à transmettre du centre d'émission vers au moins un poste récepteur et/ou vers le processeur de sécurité associé à-ce dernier un message de commande comportant des champs de données formant au moins un gabarit d'entrée, des données applicatives de commande et une redondance cryptographique ou signature numérique. Le gabarit d'entrée contient les attributs de sécurité appliqués aux données applicatives de commande. La redondance cryptographique ou signature numérique permet d'authentifier et de garantir l'intégrité du message de commande à partir des attributs de sécurité. Il consiste en outre à soumettre l'échange d'instructions d'action et de réponses à ces instructions d'action entre le terminal de désembrouillage et le processeur de sécurité à un protocole de sécurisation local spécifique permettant de se prémunir contre une écoute locale à l'interface terminal de désembrouillage/processeur de sécurité, pour exécuter de manière sécurisée une suite de tâches constituées par l'exécution d'au moins une instruction d'action. Le protocole objet de la présente invention trouve application à la gestion à distance du contrôle d'accès à des informations embrouillées ou chiffrées transmises périodiquement en réseau, quel que soit le type de réseau de transmission mis en oeuvre, les critères de synchronisation de la transmission de l'information embrouillée ou chiffrée, du mot de contrôle chiffré et de la clé de service associée à ce dernier, le cas échéant de la clé d'exploitation utilisée, devant seuls être satisfaits. Il sera mieux compris à la lecture de la description et à l'observation des dessins ci-après dans lesquels : - la figure 1 a représente, à titre illustratif, un organigramme des étapes essentielles de mise en oeuvre du protocole de gestion à distance du contrôle d'accès à des informations embrouillées, objet de la présente invention ; - la figure 1 b représente, à titre illustratif, une variante de mise en oeuvre du protocole objet de la présente invention illustré en figure 1 a, ce protocole présentant un caractère interactif, lors de la présence d'une voie de retour entre poste récepteur et centre d'émission ou centre de gestion de ce centre d'émission ; - les figures 2a à 2c représentent, à titre illustratif, la structure spécifique de messages de commande respectivement de réponse permettant la mise en oeuvre du protocole objet de la présente invention ; - la figure 3a représente, à titre illustratif, un organigramme des étapes essentielles permettant la mise en oeuvre d'un protocole de sécurisation local mis en oeuvre entre le terminal de désembrouillage et le processeur de sécurité équipant le module de contrôle d'accès associé à ce dernier, pour assurer la transmission des messages de commande vers ce processeur de sécurité ; - la figure 3b représente, à titre illustratif, un organigramme des étapes essentielles permettant la mise en oeuvre d'un protocole de sécurisation local conduit entre le processeur de sécurité équipant le module de contrôle d'accès et le terminal de désembrouillage pour assurer la transmission de messages de réponse vers ce terminal, le cas échéant vers le centre d'émission ou le centre de gestion d'émission ; - la figure 3c représente, à titre illustratif, un processus d'indexation des messages de commande respectivement de réponse susceptible d'être mis en oeuvre dans le cadre du protocole de sécurisation local, afin de renforcer la sécurité et la fiabilité de ce dernier ; - la figure 3d représente, à titre illustratif, une variante de mise en oeuvre du protocole de sécurisation local représenté en figure 3a, permettant de conférer au processeur de sécurité du module de contrôle d'accès associé à chaque terminal de désembrouillage une fonction de contrôle d'aiguillage des messages de commande, en fonction de leur destination au terminal de désembrouillage respectivement au processeur de sécurité lui-même ; - la figure 4 représente, à titre illustratif, un exemple de mise oeuvre d'un message de liaison entre message EMM et message ECM de l'art antérieur dans une application liée à l'utilisation d'un porte jetons électronique. Une description plus détaillée du procédé interactif de gestion à distance du contrôle d'accès à des informations embrouillées conforme à l'objet de la présente invention sera maintenant donnée en liaison avec la figure 1 a et les figures suivantes. En référence à la figure 1 a précitée, on rappelle que le procédé objet de la présente invention est mis en oeuvre entre un émetteur E, émetteur de messages, un poste récepteur PR comprenant un terminal de désembrouillage T auquel est associée un module de contrôle d'accès. Le module de contrôle d'accès est muni d'un processeur de sécurité et peut, par exemple, être constitué soit par une carte de contrôle d'accès du type carte à microprocesseur, soit par une carte virtuelle implantée dans un système plus complexe. Les messages émis par l'émetteur de messages E sont destinés à assurer la gestion à distance du contrôle d'accès à des informations embrouillées au moyen d'une clé de service et transmises en réseau entre le centre d'émission émetteur de messages E et au moins un poste récepteur PR. La notion d'embrouillage des informations recouvre les opérations de chiffrement symétrique de ces informations au moyen de clés secrètes respectivement de chiffrement non symétrique au moyen de clé publique, clé privée. La transmission des informations chiffrées est accompagnée d'un mot de contrôle CW contenant au moins la clé de service. Le mot de contrôle est chiffré au moyen d'une clé d'exploitation désignée SOK. La transmission du mot de contrôle chiffré est effectuée au moyen de messages de contrôle de titres d'accès désignés messages ECM contenant au moins le mot de contrôle chiffré et des paramètres de contrôle de titre d'accès. Les messages ECM sont transmis et peuvent être multiplexés dans le flux des informations chiffrées avec des messages de gestion de titres d'accès désignés messages EMM. Le processus d'émission des données chiffrées et le multiplexage des messages ECM et des messages EMM satisfait par exemple aux dispositions de la norme UTE C90-007 précédemment mentionnée dans la description. Pour cette raison, le processus précité ne sera pas décrit de manière plus détaillée. D'une manière générale, on rappelle que le module de contrôle d'accès associé à chaque terminal de désembrouillage T comporte la clé d'exploitation SOK ainsi que des titres d'accès inscrits alloués à un utilisateur abonné, détenteur autorisé du module de contrôle d'accès. La clé d'exploitation et les titres d'accès inscrits sont mémorisés en mémoire protégée du module de contrôle d'accès précité. Ce dernier comporte en outre un processeur de sécurité et des ressources cryptographiques permettant, à partir de la clé d'exploitation et du mot de contrôle chiffré, de restituer la clé de service ayant servi au chiffrement des informations embrouillées transmises. La restitution de la clé de service est effectuée sur critères de vérification des titres d'accès inscrits, ou d'au moins l'un des titres d'accès inscrits, à partir des paramètres de contrôle des titres d'accès transmis. Chaque terminal de désembrouillage permet, à partir de la clé de service restituée, d'effectuer le désembrouillage des informations embrouillées diffusées pour utilisation en clair par l'utilisateur abonné habilité. Enfin, et dans le cadre de la mise en oeuvre du procédé objet de la présente invention, chaque poste récepteur peut avantageusement être relié au centre d'émission, émetteur E, par l'intermédiaire d'une voie de retour permettant d'assurer une mise en oeuvre interactive du procédé de gestion à distance conforme à l'objet de la présente invention. Ainsi qu'on l'a représenté en figure 1 a, on indique que le protocole objet de l'invention consiste au moins, en une étape A, à transmettre du centre d'émission vers au moins un poste récepteur PR et/ou vers le processeur de sécurité PS du module de contrôle d'accès associé à ce dernier un message de commande noté MC = [GE, DAC, RC] comportant des champs de données formant au moins un gabarit d'entrée GE, des données applicatives de commande DAC et des données d'authenticité RC pouvant être une redondance cryptographique, ou une signature numérique. Le gabarit d'entrée contient les attributs de sécurité à appliquer aux données applicatives de commande DAC. Les données d'authenticité permettent d'authentifier le message de commande, ainsi qu'il sera décrit ultérieurement dans la description. L'étape A est suivie d'une étape B consistant à soumettre l'échange d'instructions d'action, entre le terminal de désembrouillage T et le processeur de sécurité PS du module de contrôle d'accès, à un protocole de sécurisation local spécifique. Le protocole de sécurisation local spécifique permet de se prémunir contre une écoute locale à l'interface terminal de désembrouillage/processeur de sécurité, pour exécuter de manière sécurisée une suite de tâches constituée par l'exécution d'au moins une instruction d'action. Conformément à un aspect particulièrement avantageux du protocole conforme à l'objet de la présente invention, on indique que le protocole de sécurisation local spécifique précité mis en oeuvre à l'étape B permet de tenir compte de la destination des messages de commande MC au terminal T de désembrouillage respectivement au module de contrôle d'accès, ainsi qu'il sera décrit ultérieurement dans la description. En effet, en fonction du critère de sécurité maximale recherché, il est possible de mettre en oeuvre différentes variantes d'exécution du protocole de sécurisation local, ceci en vue, notamment, d'assurer une sécurisation maximale de l'échange des données entre le terminal de désembrouillage T et le processeur de sécurité du module de contrôle d'accès. Le niveau de sécurisation maximale peut être défini comme consistant à réserver l'exécution de l'ensemble des opérations de chiffrement-déchiffrement aux organes internes du module, en particulier au processeur de sécurité de ce dernier, ainsi qu'il sera décrit ultérieurement dans la description. Lorsque le ou les postes récepteurs PR sont munis d'une voie de retour, reliant chacun de ces récepteurs au centre d'émission E ou à un centre de gestion GE de ce dernier, l'étape B précitée peut alors, ainsi que représenté en figure 1 b, être suivie d'une étape C consistant à calculer et à transmettre sur la voie de retour, un message de réponse spécifique au message de commande MC précité. La transmission du message de réponse est effectuée à partir du poste récepteur PR, c'est-à-dire en fait du terminal de désembrouillage T, vers l'émetteur E ou le cas échéant vers le centre de gestion GE associé à cet émetteur et connecté en réseau avec ce dernier. Sur la figure 1 b, le message de réponse est noté MR = [G'E, DAR, RC, ST]. Il comporte des champs de données formant au moins un gabarit d'entrée G'E, des données applicatives de réponse DAR et des données d'état notées ST. Il peut comporter également des données d'authenticité RC. Le gabarit d'entrée contient les attributs de sécurité appliqués aux données applicatives de réponse. Selon un aspect avantageux du protocole objet de la présente invention, l'absence de gabarit d'entrée G'E dans le message de réponse MR correspond à une absence de sécurité appliquée à ces données applicatives de réponse. On comprend, en particulier, que les données applicatives de réponse DAR en fonction de l'opération réalisée n'ont pas nécessairement à être chiffrées et qu'en conséquence, dans une telle situation, le champ ou une partie du champ des données applicatives de réponse DAR peut être simplement transmis en clair. Au contraire, lorsque le message de commande transmis MC concerne des données sensibles, le champ ou une partie du champ formant les données applicatives de commande DAC peut être chiffré. Le champ contenant les données d'authenticité formées par la redondance cryptographique ou signature numérique RC peut être calculé à partir d'un protocole de calcul de signature à clé publique par exemple. D'une manière générale, on indique que le processus de sécurisation locale spécifique concerne l'échange de messages entre le terminal T et le processeur de sécurité PS. Dans un mode de réalisation non limitatif préférentiel, la liaison locale entre le terminal T de désembrouillage et le module de contrôle d'accès, constitué par une carte, est une liaison selon le protocole ISO 7816. Dans ces conditions, l'échange de messages locaux entre le terminal de désembrouillage T et la carte de contrôle d'accès correspond à des messages de commande de type dit CAPDU et de réponse dit de type RAPDU. Le protocole d'échange de ce type de messages ne sera pas décrit en détail, car il correspond à un protocole connu en tant que tel. Enfin, en ce qui concerne le calcul et la transmission des messages de réponse MR notamment sur la voie de retour, on indique que la voie de retour précitée peut être constituée par une liaison téléphonique du réseau téléphonique commuté par exemple, cette liaison étant, le cas échéant, associée à toute liaison en réseau hertzien ou autre de type classique afin d'assurer la transmission de chaque message de réponse MR vers l'émetteur E ou le centre de gestion d'émetteurs GE associé à ce dernier. Une description plus détaillée de la structure des messages de commande MC respectivement de réponse MR sera maintenant donnée en liaison avec les figures 2a, 2b et 2c. Ainsi que représenté sur la figure 2a, on indique que chaque message de commande MC peut comporter avantageusement un champ de données supplémentaires formant un gabarit de réponse GR. Ce gabarit de réponse contient les attributs de sécurité à appliquer aux données applicatives de réponse. D'une manière générale, on indique que chaque message de commande MC, lorsqu'un tel message de commande comporte un gabarit de réponse GR, permet de fixer les conditions et attributs de sécurité à appliquer aux données applicatives de réponse ultérieures au message de commande MC considéré. Il est ainsi possible de gérer non seulement la sécurité des messages de commande, mais également de l'ensemble des messages de réponse par changement des valeurs contenues dans le champ formant le gabarit de réponse GR de messages de commande MC successifs. Ainsi qu'on l'a en outre représenté en figure 2a, on indique que, pour tout message de commande MC, les données applicatives de commande DAC ou, le cas échéant, lorsque ces données applicatives de commande sont chiffrées, ces données, notées dans cette situation CKDAC, peuvent comporter une instruction d'action ou, de préférence, une liste d'instructions d'action. Sur la figure 2a, on a représenté une liste d'instructions d'action, cette liste étant notée : [ACTo[ACT1[ACT2... [ACTn]]]] La notation de la liste d'instructions d'action précitée correspond à une notation classique des listes. On comprend en particulier que chaque action notée ACT 0 à ACTn peut alors être exécutée séquentiellement par le destinataire du message de commande MC, ce destinataire étant, conformément à un aspect particulièrement avantageux du procédé objet de la présente invention, soit le terminal de désembrouillage T, soit le processeur de sécurité du module de contrôle d'accès précédemment cité. Un mode de mise en oeuvre particulièrement avantageux du procédé objet de la présente invention sera maintenant décrit en liaison avec la figure 2b. Ce mode de réalisation permet d'introduire une très grande souplesse d'utilisation des messages précités. Dans ce mode de réalisation, les messages précités, messages de commande et/ou de réponse, constituent alors des messages génériques désignés messages EXM. Les messages EXM peuvent, en raison de leur très grande souplesse d'utilisation et de la structure associée à ces derniers permettant d'introduire une telle souplesse d'utilisation, soit être déclinés en messages ECM, soit en messages EMM, ou encore en messages de gestion spécifique, ainsi qu'il sera décrit ci-après dans la description. Dans ce but, ainsi que représenté en figure 2b, les données applicatives de commande et/ou de réponse sont programmables. En conséquence, le champ correspondant de ces données comporte une combinaison logique de conditions dont le résultat binaire de la vérification logique, vrai ou faux, permet d'engendrer un branchement conditionne d'actions. Les actions sont traitées séquentielle ment par le terminal de désembrouillage ou le processeur de sécurité PS de la carte de contrôle d'accès destinataire. Sur la figure 2b, le caractère programmable des données applicatives de commande et/ou de réponse est représenté par la relation : Data = (Act (lfBlock [Then Block] [Else Block])) On comprend en particulier que, dans la relation précédente, Data désigne soit les données applicatives de commande DAC en clair ou, le cas échéant chiffrées, désignées par CKDAC, soit les données applicatives de réponse en clair désignées par DAR, ou le cas échéant chiffrées, désignées par CKDAR. La notation de la relation précédente est une notation de description métalinguistique de type Backus-Naur-Form qui sera explicitée ultérieurement dans la description. En ce qui concerne la relation précédente, on indique que le message de commande et/ou de réponse et les données applicatives de commande ou de réponse constituent une phrase logique structurée pouvant contenir la relation logique : Si ("If') : l'expression logique de condition est vérifiée ; Alors ("Then") : on exécute l'action ou la liste d'actions décrite dans le bloc descriptif de l'action ou de la liste d'actions associée à la condition vérifiée ; Sinon ("Else") : on exécute l'action ou la liste d'actions décrites dans le bloc descriptif de l'action ou de la liste d'actions associée à cette condition non vérifiée. Sur la figure 2c, on a représenté la structure de messages de réponse MR, cette structure comportant le gabarit d'entrée G'E, le gabarit de données applicatives de réponse DAR sous forme de données en clair ou chiffrées CKDAR et le champ d'état ST. On rappelle en outre que, pour ce qui concerne les données applicatives de réponse DAR en clair ou sous forme chiffrée, telles que mentionnées précédemment, ces données correspondent à la structure de données Data telle que décrite en liaison avec la figure 2a ou, de préférence, avec la figure 2b. Grâce à la structure des messages de commande MC respectivement de réponse MR telle que décrite précédemment dans la description en liaison avec les figures 2a à 2c, on indique que les messages génériques EXM précédemment décrits peuvent, en raison de leur structure commune, être dédiés soit à des actions de gestion commerciale indépendante de, mais liés à, la gestion des titres d'accès, actions commerciales telles que gestion d'un porte jetons ou analogue implanté sur le module de contrôle d'accès, en fonction des titres d'accès inscrits dans le processeur de sécurité du module de contrôle d'accès, soit au contrôle des titres d'accès ou à la gestion optimisée des titres d'accès inscrits en fonction par exemple du comportement de l'utilisateur abonné habilité, ou encore à la gestion de la sécurité locale d'échange de messages entre le processeur de sécurité et le terminal de déchiffrement par des actions de liaison entre messages ECM et messages EMM, à des actions de gestion de sécurité des informations chiffrées. Des exemples de structure générale des messages de commande respectivement de réponse seront maintenant donnés ci-après dans la description au moyen d'une notation de description métalinguistique apparentée à la forme BNF (Backus-Naur-Form) dans laquelle : - A = BC : l'élément A est constitué de la séquence des éléments B et C, - A = (Bt : l'élément A est constitué de 1 à n éléments B, - A = (B)' : l'élément A est constitué de 0 à n éléments B, - A = BIC : l'élément A est constitué de l'élément B ou de l'élément C, - A = B [C] : l'élément A est constitué de l'élément B suivi optionnellement de l'élément C, - A = - : l'élément A est constitué de rien. Une description sémantique des messages sera maintenant donnée dans la description. Par le terme message, on désigne tout message de commande MC à destination du processeur de sécurité PS du module ou de la carte de contrôle d'accès respectivement du terminal T en provenance de l'émetteur E ou du système de gestion d'émetteurs GE. Pour cette raison, on considèrera que tout message de commande MC est en fait destiné au processeur de sécurité équipant soit le module, soit la carte de contrôle d'accès, réelle ou virtuelle. Tout message de réponse MR est consécutif à un message de commande MC et à destination du terminal T ou des équipements amont du système d'émission. La structure générale des messages est alors la suivante, selon le tableau T1 ci-après : Tableau T1 Structure générale des messages d'accès d'accès conditionne Pour les commandes : Command = Gabaritinput [GabaritResponse] Data Authenticity Pour les réponses : Command = [ [Gabaritinput] Data [Authenticity]] StatusData Pour les messages de commande MC : - un message de commande comprend un gabarit d'entrée et optionnellement un gabarit de réponse. Le gabarit de réponse optionnel décrit les mécanismes de sécurité à appliquer à la réponse. Les données applicatives de commande sont précédées par un ou deux gabarits, Gabaritinput et GabaritResponse, seul le gabarit d'entrée indiquant les attributs de sécurité utilisés dans le message courant. Lorsque des données applicatives de commande nécessitent deux gabarits, ces derniers précèdent les données applicatives dans le message. De préférence, les informations décrites dans les gabarits d'entrée ou de réponse d'un message de commande MC sont émises en clair. Les données applicatives de commande indiquent des actions spécifiques qui sont prises en compte par le module ou la carte de contrôle d'accès ou le terminal de désembrouillage T. D'une manière générale, les données applicatives de commande sont émises à partir des équipements distants, c'est-à-dire de l'émetteur E, et transmises sous forme chiffrée afin d'assurer la confidentialité de ces données. Pour les messages de réponse MR : - le gabarit d'entrée G'E contient les attributs de sécurité qui sont appliqués aux données applicatives de réponse présentes dans la réponse. L'absence de gabarit indique qu'aucune sécurité n'est appliquée aux données applicatives. Le message de réponse MR associé à un message de commande MC peut être exploité soit localement par le terminal T de désembrouillage, soit par un équipement amont tel que l'émetteur ou le système de gestion d'émetteur GE, par l'intermédiaire de la voie de retour, ainsi que mentionné précédemment dans la description. Dans le premier cas, lorsque le message de réponse MR est exploité localement par le terminal T, le message de réponse n'est pas soumis à un chiffrement général, mais uniquement au protocole de sécurisation local, ainsi qu'il sera décrit ultérieurement dans la description. Au contraire, lorsque le message de réponse est destiné à une transmission sur la voie de retour, ce message de réponse MR est soumis à un processus de chiffrement général au moyen d'une clé de gestion spécifique par exemple. Bien entendu, les messages de réponse MR peuvent également comprendre optionnellement des données d'authenticité, redondance cryptographique ou signature numérique, pour authentifier et garantir l'intégrité du message de réponse lui-même. Le champ relatif à ces données d'authentification est absent lorsque le gabarit d'entrée associé est absent. En ce qui concerne le champ d'état, désigné par ST, un message de réponse MR contient toujours un statut ou champ d'état précisant le compterendu sur la structure du message, c'est-à-dire : - le message n'a pu être interprété, dans ce cas la réponse ne contient que le statut ST, - le message a été traité, dans ce cas, la réponse contient les données applicatives de la réponse et le statut ST. Des indications plus spécifiques relatives au champ de données de gabarit d'entrée des messages de commande et de réponse seront maintenant données. En référence à la structure générale des messages précédemment mentionnée dans la description en liaison avec le tableau T1, on rappelle que les gabarits définissent les paramètres nécessaires aux mécanismes de sécurité appliqués aux données applicatives de commande respectivement de réponse. Dans ces conditions, les deux gabarits d'entrée GE ou G'E et le gabarit de réponse GR peuvent comprendre les informations suivantes, selon le tableau T2 : Tableau T2 Structure d'un gabarit Gabarit = RefFile [Algolds] Keylds [Reflnits] Dans le tableau précité, la référence de fichier désignée par RefFiie indique le fichier où les références de clé s'appliquent. C'est le nom d'un fichier dédié, ou fichier maître, c'est-à-dire le nom d'un service distribué par le diffuseur de données chiffrées sous accès conditionne. En règle générale, RefFile = SOID. SOID désigne un paramètre identificateur de service diffusé, pour Service Output Identifier en langage anglo-saxon. Les références d'algorithmes désignées Algolds précisent les algorithmes utilisés dans le message courant pour les fonctions cryptographiques associées au message décrites selon le tableau T3. Tableau T3 Structure des références d'algorithmes Algoids = AlgoAuthenid [AlgoConfid] [AlgoCipherld] Dans le tableau précité, AlgoAuthenid désigne la fonction d'authenticité du message, AlgoConfld désigne la fonction de confidentialité des données applicatives de commande respectivement de réponse, et AlgoCipherld désigne la fonction de chiffrement de données applicatives spécifiques de commande respectivement de réponse. Les références de clés Keylds précisent les clés utilisées dans le message courant pour la mise on oeuvre de fonctions définies selon le tableau T4 : Tableau T4 Structure des références de clés Keyids = KeyAuthenld [KeyConfld] [KeyCipherld] dans lequel KeyAuthenid désigne la clé de vérification d'authenticité du message, KeyConfid désigne la clé de confidentialité des données applicatives de commande respectivement de réponse, KeyCipherld désigne la clé de chiffrement de données applicatives spécifiques. Les références de données initiales Reflnits sont des valeurs utilisées dans le message courant pour initialiser des fonctions d'authenticité du message désignées InitAuthen, respectivement de confidentialité des données applicatives InitConf. La structure générale des messages est en conséquence la suivante : . sans gabarit de réponse : lorsqu'aucun gabarit de réponse n'est spécifié dans le message de commande MC, aucun mécanisme de sécurité n'est appliqué à la réponse ; - aucun gabarit n'est fourni dans le message de réponse MR ; - les données applicatives de réponse sont en clair dans le message de réponse MR ; - aucune authenticité n'est adjointe aux données. Le couple message de commande MC/message de réponse MR présente alors la structure suivante, selon le tableau T5 : Tableau T5 Message de commande Message de réponse Gabaritlnput (GE) Data (DAC) ou (CKDAC) Data en clair (DAR) Authenticity (RC) StatusData (ST) . avec gabarit de réponse : la structure des messages de commande respectivement de réponse est la suivante, selon le tableau T6 : Tableau T6 Message de commande Message de réponse Gabaritlnput (GE) GabaritResponse (GR) GabariDnput (G'E) Data (DAC) ou (CKDAC) Data (en clair ou embrouillées) (DAR ou CKDAR) Authenticity (RC) Authenticity (RC) StatusData (ST) En qras : les données imposées par le gabarit de réponse de la commande. En règle générale, les dispositions applicables aux gabarits sont les suivantes : - si une fonction n'est pas nécessaire, les attributs de sécurité associés ne sont pas décrits explicitement ; - les messages contenant les données confidentielles et/ou des données chiffrées incluent obligatoirement un gabarit d'entrée pour l'authenticité du message. Des indications plus spécifiques seront maintenant données relativement aux structures de données constitutives des champs de données applicatives de commande respectivement de réponse. En référence à la structure générale des messages de commande respectivement de réponse, on rappelle que les données applicatives de commande d'un message de commande MC contiennent : - soit une action ou une liste d'actions traitées séquentiellement par le destinataire, c'est-à-dire par le processeur de sécurité du module de contrôle d'accès ou le terminal de désembrouillage T ; - soit une combinaison logique de conditions dont le résultat binaire de la vérification, vrai ou faux, permet d'effectuer un branchement conditionnel d'actions, lesquelles sont traitées en séquence par le destinataire. On rappelle que le message de commande, ou le cas échéant de réponse, répond alors à la phrase logique structurée pouvant comporter la relation logique : Si Alors Sinon précédemment mentionnée dans la description. Une telle structure peut être répétée à l'intérieur d'une structure de données désignée par TData, la combinatoire des conditions et des actions étant codée selon un processus de codage TLV, selon une structure de données ASN. 1 avec des étiquettes de type TData. D'une manière générale, on indique qu'une condition simple est une condition comportant une seule action. Une combinaison logique de conditions est constituée au moyen d'opérateurs logiques tels que les opérateurs classiques OR, AND, NOR et NAND réalisant les opérations logiques OU, ET, NON-OU et NON-ET. En fonction du contexte des données applicatives traitées, le terminal de désembrouillage T est en mesure de choisir entre une réponse longue respectivement une réponse courte donnée dans un message de réponse MR associé à un message de commande MC. Les données applicatives d'une réponse longue contiennent avantageusement : - la répétition de la structure de la commande ; - pour chaque action demandée dans la commande : la répétition de l'action demandée dans la commande, la description des informations demandées par chaque action de la commande, ces informations étant fournies par la carte ou le terminal, -- un compte-rendu pour chaque action, afin de renseigner l'émetteur E sur l'exécution de l'action. Les données applicatives d'une réponse courte contiennent, pour chaque action définie : - un bloc principal message simple ou action présente dans un message conditionnel hors combinatoire de conditions, ou - bloc Alors et/ou Sinon présent dans la commande et exécuté ou non -- la description des informations demandées par chaque action du ou des blocs, ces informations sont fournies par la carte ou module de contrôle d'accès ou le terminal de désembrouillage T ; -- un compte-rendu pour chaque action du ou des blocs, afin de renseigner l'émetteur E sur le résultat de l'exécution de l'action. Ainsi, chaque message de commande MC peut comporter un champ ou un bit de spécification du format de réponse du message de réponse correspondant associé à ce dernier. Le format de réponse longue ou courte peut être choisi par le terminal de désembrouillage, en fonction du contexte applicatif et du détail d'informations requis dans le cadre de ce contexte applicatif. Une pluralité de formats de réponse peut être prévue. Un exemple de structure de message simple de commande MC respectivement de réponse MR longue ou courte est donné dans le tableau T7 : Tableau T7 Message de commande Commentaire T Gabantlnput L Gabaritinput Gabarit d'entrée [TGabaritResponse L GabaritResponse] Gabarit de réponse TData L Données applicatives [TSOID L SOID] Selon structure optimisée ou non. [Toate L Date] Idem. (TActionObject L Action) + Action (s) à réaliser. TAuthen L Authenticity Authenticité du message. Message de réponse longue [TGabantlnput L Gabaritinput] Gabarit d'entrée T Data L Données applicatives : [TSOID L SOID] SOID et/ou Date global, si présent dans [Toate L Date] la commande. Réponse à chaque action de la commande. (TActionObject L Action [TResu) t L Result] Tstatus L StatusAction) + [TAuthen L Authenticity Authenticité du message. TstatusData L StatusData Status général à la réponse. Message de réponse courte [TGabantlnput L Gabaritinput] Gabarit d'entrée T Data L Données applicatives : Réponse à chaque action de la commande. ( [TResult L Result] Tstatus L StatusAction [TAuthen L Authenticity Authenticité du message. TstatusData L StatusData Status général à la réponse. La structure-générale des données applicatives de commande respectivement de réponse permet le codage de la combinatoire des conditions. Une telle structure peut être récursive et représentée dans ce cas, selon le tableau T8 : Tableau T8 Structure générale des données applicatives Pour les commandes : Data = (Action I (IfBlock [ThenBlock] [ElseBlock] )+ Où Action = Action demandée. ifblock = "Andlf" (lfBlock#Action )+ # "Orlf" (lfBlock # Action)+ # "NAndlf" (lfBock#Action)+# "NOrlf' (IfBlock 1 action. ThenBlock ="Then" (Action) . ElseBlock = "Else" (Action)+. Pour les réponses longues : Data = ((Action[Result]StatusAction) # (lfBlockR [ThenBlockLR] [ElseBlockLR]))+ Où Result = Informations demandées par l'action lorsqu'il y en a. StatusAction = Compte-rendu sur chaque action. lfBlockR = "AndlF" (lfBlockR # (Action [Result] StatusAction))+ # "Orlf' (lfBlockR 1 (Action [Result] StatusAction)) +# "NAndlf' (lfBlockR # Action [Result] StatusAction)) . "NOrlf' (lfBlockR [Result] StatusAction))+ ThenB ! ockLR ="Then" (Action [Result] StatusAction)+. ElseBlockLR = "Else" (Action [Result] StatusAction) +. Pour les réponses courtes : Data = ( ( [Result] StatusAction) # ([ThenBlockSR] [ElseBlockSR]))+ Où Result = informations demandées par l'action lorsqu'il y en a. StatusAction = Compte-rendu sur chaque action. ThenBlockSR = "Then" [Result] StatusAction)+. ElseBlockSR = "Else" [Result] StatusAction)+. Les règles d'exécution sont alors les suivantes : - 1. Dans une liste d'actions, les actions sont traitées dans l'ordre de la liste. - 2. Dans une clause Andlf, NAndlf, Orlf, ou NOrlf, toutes les actions de la liste associée peuvent être évaluées. - 3. Dans une clause Andlf ou NAndif, les actions de la liste associée sont exécutées tant que la clause reste vraie. - 4. Dans une clause Orlf ou NOrif, la dernière action exécutée de la liste associée est celle qui rend la clause vraie. A titre d'exemple non limitatif, on indique que, les données applicatives de commande respectivement de réponse transportées dans un message tel qu'un message de commande MC respectivement de réponse MR, peuvent être : - consulter 01 ou mettre à jour l'objet 02,01 et 02 désignant des objets ; -si les actions contrôlées 01 ou contrôlées 02 sont vérifiées, alors déchiffrer 03, où 03 désigne, à titre d'exemple non limitatif, le cryptogramme des mots de contrôle CW, c'est-à-dire les mots de contrôle CW chiffrés au moyen de la clé d'exploitation SOK. Une description plus détaillée du protocole de sécurisation locale spécifique constitutif de l'étape B de la figure 1 a ou 1 b sera maintenant donnée en liaison avec les figures 3a à 3d. D'une manière générale, on rappelle que l'interface terminal de désembrouillage/processeur de sécurité du module de contrôle d'accès et, en particulier, carte de contrôle d'accès lorsque ce dernier est constitué par une carte à microprocesseur par exemple, est le point d'attaque privilégié des pirates et perceurs de chiffre en vue de tenter de compromettre le mot de contrôle CW, lorsque ce dernier est transmis du processeur de sécurité PS au terminal de désembrouillage T. En effet, tous les calculs de restitution du mot de contrôle CW sont effectués dans le processeur de sécurité, lequel présente un degré de sécurité maximal, les secrets nécessaires à la restitution du mot de contrôle ne pouvant être atteints par une lecture extérieure. D'une manière plus particulière, on rappelle que les données applicatives de commande de chaque message de commande reçues au niveau du terminal de désembrouillage T peuvent être en clair ou, au contraire, peuvent être chiffrées et sont désignées DAC respectivement CKDAC dans ces deux situations. On rappelle que les données applicatives de commande chiffrées CKDAC ont été soumises par exemple à un processus de chiffrement général à partir d'une clé de gestion spécifique notée K dont dispose l'autorité assurant la gestion du contrôle d'accès et, en particulier, de la diffusion des données embrouillées par exemple. Afin de mettre en oeuvre le protocole de sécurisation local, on indique que le terminal de désembrouillage T et le module de contrôle d'accès, en particulier la carte de contrôle d'accès constitutive de ce dernier par exemple, sont munis de ressources cryptographiques de chiffrement/déchiffrement, de calcul et de vérification d'authenticité. D'une manière simplifiée, on indique que ces ressources cryptographiques comportent des algorithmes et des clés de chiffrement respectivement de calcul et de vérification d'authenticité spécifiques représentées symboliquement par une clé de chiffrement/déchiffrement, de calcul et de vérification d'authenticité notée CL. Cette clé est localement partagée par chaque terminal de désembrouillage et par chaque module de contrôle d'accès et peut être spécifique à chaque couple ainsi constitué. Dans ces conditions, ainsi que représenté en figure 3a, le protocole de sécurisation local spécifique peut consister, au niveau du terminal de désembrouillage T, à soumettre en 81 au moins les données applicatives de commande du message de commande MC à un processus de chiffrement local et d'authentification locale. De préférence, la totalité des champs des messages de commande MC est soumise au protocole de sécurisation local. Sur la figure 3a, l'opération correspondante de chiffrement local et d'authentification locale est notée selon la relation : CCL (MC) CLIC Dans cette relation, on indique que l'opération CCL indique à la fois le chiffrement d'au moins soit les données applicatives de commande en clair DAC, soit les données applicatives de commande chiffrées CKDAC du message de commande MC et le calcul des valeurs de signature par exemple, pour engendrer des valeurs correspondantes chiffrées et des valeurs de signature permettant l'authentification des valeurs notées CLMC pour les données applicatives de commande en clair ou pour les données applicatives de commande chiffrées. Selon une caractéristique particulièrement avantageuse du protocole de sécurisation local spécifique objet de l'invention, on indique que le processus de chiffrement local et d'authentification locale est indépendant du processus de chiffrement mis en oeuvre préalablement à la transmission du message de commande, c'est-à-dire en particulier, du processus de chiffrement général au moyen de la clé de gestion K précédemment mentionnée. L'étape 81" est alors suivie d'une étape 82 consistant à transmettre, du terminal de désembrouillage T vers le processeur de sécurité PS du module de contrôle d'accès, des message locaux de commande chiffrés formés à partir des données de commande localement sécurisées CLMC Sur la figure 3a, les messages locaux de commande chiffrés sont notés symboliquement LM (CLMC). Dans le cas où le module de contrôle d'accès est constitué par une carte de contrôle d'accès à microprocesseur, la transmission vers le processeur de sécurité PS à l'étape B2 peut être effectuée conformément au protocole ISO 7816, les messages locaux de commande étant constitués selon des messages de type C-APDU de manière connue en tant que telle. Le protocole de sécurisation local consiste ensuite, au niveau du processeur de sécurité PS équipant le module de contrôle d'accès, en une étape B3, à soumettre les messages locaux de commande chiffrés à un processus de déchiffrement local et d'authentification locale pour restituer le champ de données applicatives de commande précité. L'opération réalisée à l'étape B3 est notée : DcL (CLMC)- MC Dans cette relation, Oc (. ) désigne l'opération de déchiffrement et d'authentification locale précitée. Suite à l'étape B3, on dispose soit des données applicatives de commande en clair DAC, soit des données applicatives de commande chiffrées selon le processus de chiffrement général CKDAC, constitutives du message de commande MC. L'étape B3 est alors suivie de l'étape B4 consistant à soumettre le champ de données applicatives à un processus d'authentification, pour restituer à partir du champ de données applicatives de commande précité des suites d'instructions d'action exécutables selon au moins une tâche. Sur la figure 3a, on indique que le processus d'authentification est noté selon la relation : (ÎK (DAC, CKDAC)- DAC, CKDAC. Dans la relation précitée, l'opération ex (.) indique le processus d'authentification, lequel peut consister par exemple en une opération de vérification de signature à partir de la clé de gestion K utilisée lors du processus de chiffrement et d'authentification générale par l'opérateur gestionnaire du protocole objet de la présente invention et de la diffusion du service correspondant. On indique en effet que cette opération peut être réalisée à partir des attributs de sécurité transmis avec le message de commande MC, ces attributs permettant d'identifier et ainsi de restituer la clé de gestion K mémorisée au niveau du processeur de sécurité PS. A la fin de l'étape B4, on dispose des données applicatives de commande en clair DAC ou des données applicatives de commande chiffrées CKDAC selon le processus de chiffrement général, ainsi que mentionné précédemment dans la description. Lorsque les données applicatives de commande sont en clair, données DAC, l'étape B4 est alors suivie d'une étape B5 consistant à exécuter la suite d'instructions d'action exécutables selon une tâche. L'exécution est représentée sur l'étape B5, en partie gauche de la figure 3a. Au contraire, lorsque les données applicatives de commande sont chiffrées selon le chiffrement général, données CKDAC, l'étape d'exécution B5 peut, ainsi que représenté sur la figure 3a en partie droite, être subdivisée en une première étape B5a consistant à opérer un déchiffrement au moyen de la clé de gestion K de ces données applicatives de commande chiffrées, cette opération étant notée selon la relation : K (CKDAC) --+ DAC. Dans la relation précitée, DK (.) indique l'opération de déchiffrement proprement dite à partir de la clé de gestion K. L'étape B5a peut précéder l'étape B4 ou être exécutée en même temps. L'étape B5a est suivie d'une étape B5b d'exécution des données applicatives commande DAC. Une description plus détaillée du protocole de sécurisation local spécifique mis en oeuvre lors de l'établissement des messages de réponse sera maintenant donnée en liaison avec les figures 3b à 3d. En référence à la figure 3b précitée, on indique que le protocole de sécurisation local spécifique, suite à l'exécution d'au moins une instruction d'action exécutable selon au moins une tâche, consiste, au niveau du processeur de sécurité PS, à calculer des données applicatives de réponse à partir de l'exécution d'au moins une instruction d'action exécutable selon au moins une tâche à l'étape B6. On comprend en particulier que les données applicatives de réponse sont calculées à partir des données d'état obtenues suite à l'exécution des blocs relativement à la condition Alors des données applicatives de commande, ainsi que suite à la procédure d'évaluation des blocs non exécutés lorsque cette condition n'est pas vérifiée, mais suivie de la condition Sinon, ainsi que mentionné précédemment dans la description. En outre, les données applicatives de réponse DAR peuvent consister, ainsi que mentionné précédemment dans la description, en une phrase logique structurée contenant au moins la relation logique elle-même appliquée sur des variables d'état spécifiques. L'étape B6 est alors suivie d'une étape B7 consistant à soumettre les données applicatives de réponse DAR à un processus de sécurisation par chiffrement local et authentification locale du message de réponse MR pour engendrer des données applicatives de réponse localement sécurisées. Sur l'étape B7, le processus précité est symbolisé par la relation : CcL (MR) o CLMR. Dans la relation précédente, de même que lors de la mise en oeuvre de l'étape 81 de la figure 3a, ecL (. ) indique l'opération de processus de sécurisation par chiffrement local et authentification locale pour obtenir les données chiffrées et sécurisées CLMR. L'étape B7 est elle-même suivie d'une étape B8 consistant à transmettre, du processeur du sécurité PS vers le terminal de désembrouillage T, des messages locaux de réponse contenant les données applicatives de réponse localement sécurisées. Sur la figure 3b, les messages locaux de réponse contenant les données applicatives de réponse localement sécurisées sont notés : LM (CLMR). Lorsque le- module de contrôle d'accès est constitué par une carte de contrôle d'accès connectée avec le terminal de désembrouillage selon un liaison locale conforme au protocole ISO 7816, les messages locaux de réponse précités sont constitués par des messages dits de type R-APDU. Le protocole de sécurisation locale spécifique, tel que représenté en figure 3b, est alors suivi, au niveau du terminal de désembrouillage T, par une étape B9 consistant à soumettre les données applicatives de réponse localement sécurisées à un processus de déchiffrement local et de vérification d'authenticité locale pour restituer les données applicatives de réponse d'origine constitutives du message de réponse MR. Sur la figure 3b, l'opération correspondante est notée selon la relation : "DCL (CLMR)- > MR. Dans cette relation, l'opération'DcL (.) désigne l'opération de déchiffrement et de vérification d'authenticité locale réalisée à partir de la clé de chiffrement et d'authentification locale CL. Le protocole de sécurisation local mis en oeuvre relativement au message de réponse et aux données applicatives de réponse DAR, tel que décrit en liaison avec la figure 3b, est parfaitement satisfaisant dans le cas où les données applicatives de réponse sont destinées au seul terminal de désembrouillage T. En effet, le processus de sécurisation locale mis en oeuvre en particulier à l'étape B7 et, bien entendu, vis à vis des messages de commande MC à l'étape 81 de la figure 3a, est suffisant pour assurer une confidentialité stricte des messages locaux échangés sur la liaison locale entre le terminal de désembrouillage et le processeur de sécurité du module de contrôle d'accès. En effet, il est toujours envisageable de faire appel à des systèmes cryptographiques forts pour la mise en oeuvre des processus de sécurisation locale, systèmes cryptographiques forts, tels que par exemple les masques jetables ou autres permettant d'assurer un chiffrement quasi parfait des messages locaux échangés sur la liaison locale, cible des pirates ou perceurs de chiffre. En outre, le protocole de sécurisation local peut avantageusement être accompagné d'un processus d'indexation des messages de commande et de réponse afin de renforcer la sécurité et la fiabilité de l'ensemble en permettant la détection de filtrage ou de rejeu et ainsi, l'élimination de messages qui seraient répétés accidentellement et/ou intentionnellement par des personnes non habilitées. Dans ce but, ainsi que représenté en figure 3c, à chaque message de commande respectivement de réponse MC, MR est associée une valeur d'index courant notée jc respectivement Ic pour les messages de commande et de réponse, les messages de commande et de réponse indexés étant dénotés MCjc respectivement Mu,,. Les indices précités représentent la valeur courante des indices j et 1 affectés à chaque message de commande respectivement de réponse. Chaque valeur d'indice courant est incrémenté pour chaque nouveau message de commande respectivement de réponse, cette incrémentation étant réalisée localement soit au niveau du terminal de désembrouillage, soit au niveau du processeur de sécurité. La valeur courante est comparée à la valeur antérieure j respectivement) de l'index du message de commande respectivement de réponse qui a satisfait à la comparaison précitée. Sur réponse négative à cette comparaison pour le message courant de commande respectivement de réponse, un message d'erreur est établi, un processus d'authentification réciproque terminal de désembrouillage/processeur de sécurité pouvant être déclenché par exemple. Au contraire, sur réponse positive à la comparaison précitée, le processus ou protocole de sécurisation locale peut alors être poursuivi sur la base du message de commande respectivement de réponse courant. Le processus d'indexation précité peut par exemple être mis en oeuvre postérieurement à l'étape B4 de la figure 3a au niveau du processeur de sécurité, préalablement à l'étape B5 d'exécution par exemple. Enfin, un mode de mise en oeuvre préférentiel du protocole de sécurisation local, dans lequel le processeur de sécurité du module de contrôle d'accès joue un rôle prépondérant de contrôle de l'ensemble des messages de commande reçus et traités par le terminal de désembrouillage et/ou le processeur de sécurité du module de contrôle d'accès, sera maintenant décrit en liaison avec la figure 3d. De manière générale, on indique que le processeur de sécurité PS est doté d'une fonction de discrimination de la destination des messages de commande MC afin d'assurer tout contrôle de transmission et d'exécution des messages de commande respectivement de réponse sous l'autorité du protocole de sécurisation local mis en oeuvre. Dans ce but, ainsi que représenté sur la figure 3d, le protocole de sécurisation local peut consister à soumettre en une étape B4a les données applicatives de commande à un test de discrimination de leur destination au module de contrôle d'accès respectivement au terminal de désembrouillage. Cette opération consiste par exemple à déterminer si le message de commande MC correspondant, message courant, ou une commande des données applicatives de commande DAC de ce dernier, est destiné au terminal de désembrouillage T. Sur réponse négative au test précité, le message de commande MC ou la commande considérée étant destiné au processeur de sécurité PS et, l'étape d'authentification de l'étape B4 ayant été réussie, l'exécution selon l'étape B5 de la figure 3a peut être réalisée soit à partir des données applicatives de commande DAC, soit des données applicatives de commande chiffrées CKDAC. Au contraire, sur réponse positive au test B4a, le message de commande MC courant ou la commande considérée étant destiné au terminal de désembrouillage T, ce message étant noté MC*, une étape de sécurisation locale B4b est appelée, laquelle consiste à soumettre les données applicatives de commande DAC, CKDAC ou le message de commande MC* à un processus de chiffrement local au moyen de la clé de chiffrement local CL. Cette opération mise en oeuvre au niveau du processeur de sécurité PS correspond à celle réalisée à l'étape B1 de la figure 3a. L'étape B4b précitée est alors suivie d'une étape B4c consistant à transmettre vers le terminal de désembrouillage T les données applicatives de commande chiffrées ou le message de commande chiffré, c'est-à-dire les données CLMC*, que ces données aient été chiffrées au moyen d'un processus de chiffrement général par l'intermédiaire d'une clé de gestion K ou, au contraire, non soumises à un tel processus de chiffrement général. Dans le premier cas, le déchiffrement général est effectué par le processeur de sécurité PS avant transmission vers le terminal de désembrouillage T. Suite à la transmission de l'étape B4c vers le terminal T, les données applicatives de commande chiffrées précitées sont soumises à une opération de déchiffrement en une étape B4d au niveau du terminal T lui-même. Cette opération de déchiffrement correspond sensiblement à l'opération décrite en liaison avec l'étape B3 de la figure 3a mise en oeuvre cette fois au niveau du terminal de désembrouillage T. L'étape B4d précitée est elle-même suivie d'une étape B4e consistant soit en une exécution des données applicatives de commande en clair DAC au niveau du terminal de désembrouillage ou, au contraire, en une transmission des données applicatives de commande chiffrées par le processus de chiffrement général, données notées CKDAC, vers le centre d'émission E ou vers le centre de gestion de ce centre d'émission GE. Un exemple de mise en oeuvre d'un message de liaison dit message EPM, entre message EMM et message ECM de l'art antérieur sera maintenant décrit en liaison avec la figure 4 dans une application liée à l'utilisation d'un porte jetons ou de tout système de décompte de valeurs. En référence à la figure précitée, en une étape Eo, le poste récepteur PR reçoit un crédit d'unités CU par l'intermédiaire d'un message EMM noté EMM (CU, IEP). Dès réception du message EMM précité, le terminal de désembrouillage T présente le message précité au processeur de sécurité PS par transmission, lequel ajoute le crédit d'unités dans le porte jetons électronique référencé dans le message EMM. A titre, d'exemple, on indique que, pour un porte jetons électronique EP, le numéro d'identification peut être un numéro IEP. L'opération de transmission précitée est réalisée à l'étape E1. Suite à l'étape précitée, le processeur de sécurité PS ajoute le crédit d'unités dans le porte jetons électronique référencé à l'étape E2, t'opération de crédit étant notée : NCR = CR + CU où CR désigne la valeur de crédit antérieur et NCR la nouvelle valeur de crédit. Les opérations Eo, E1 et E2 ont été réalisées à l'initiative du gestionnaire du contrôle d'accès afin de conférer un crédit d'unités suffisant pour permettre à ce dernier d'effectuer une proposition d'accès à tout client attributaire du crédit d'unités précité. Dans ce but, l'étape Es est alors suivie d'une étape E3 réalisée à l'initiative du gestionnaire de contrôle d'accès par l'émission, et, bien entendu, la réception correspondante par le poste récepteur PR d'un message dit EPM destiné à assurer la liaison entre le message EMM précité et tout message ECM ultérieur, ainsi qu'il sera décrit ci-après. Le message EPM, de la forme EPM (MIFF, COST), diffuse un numéro de référence de film ou de programme, par exemple noté MIDF, qui va être diffusé et que l'abonné est susceptible d'accepter ou de refuser dans le cadre de la proposition d'accès faite. En outre, le message EPM précité comprend une valeur de coût, notée COST, correspondant au coût d'achat du film ou du programme considéré. Suite à l'étape E3, une étape E4 est prévue laquelle consiste à solliciter, au niveau du terminal T, l'accord de l'abonné sur la proposition d'accès ainsi soumise. En pratique, le message EPM est présenté une première fois au processeur de sécurité PS qui indique que l'accord de l'abonné est nécessaire. En l'absence d'accord de l'abonné à l'étape E4, la proposition d'accès est classée sans suite à l'étape Es. Au contraire, sur accord de l'abonné à l'étape E4, à la proposition d'accès précitée, le terminal T procède à la transmission du message EPM avec l'accord de l'abonné, message de liaison avec les champs correspondants MIDF et de coût COST vers le processeur de sécurité PS. L'étape E6 est alors elle-même suivie, au niveau du processeur de sécurité PS, d'une étape E7 consistant à débiter le porte jetons électronique EP, cette opération étant notée : NNCR = NCR-COST le porte jetons électronique étant ainsi débité de la valeur COST, c'est-à-dire du nombre d'unités correspondant au programme acheté. En outre, une inscription du numéro d'identification ou de référence du film ou du programme acheté, numéro MIDF, est effectuée en mémoire du processeur de sécurité PS. L'étape E7 précédente est alors suivie d'une étape E8 réalisée lors de la diffusion du film ou du programme-acheté par l'intermédiaire des messages ECM de type classique. Les messages ECM précités sont reçus à l'étape E8 par le poste récepteur et, en particulier, par le terminal T et sont bien entendu accompagnés du cryptogramme du mot de contrôle CCW et sont présentés par le terminal T au processeur de sécurité PS par transmission à l'étape Eg. Le numéro d'identification du programme ou du film diffusé dans ces deux étapes est noté DIDF. Le processeur de sécurité PS entame alors une étape de vérification E10 consistant à vérifier l'identité du numéro d'identification du film ou programme diffusé DIDF et du numéro d'identification du programme ou du film proposé en accès par le message EPM, c'est-à-dire du numéro d'identification MIDF. Sur réponse négative à l'étape de vérification E10 précitée, une étape E11 de fin d'accès au film ou programme diffusé, référencé DIDF, est appelée. Au contraire, sur réponse positive au test E10 de vérification précité, une opération de déchiffrement du cryptogramme du mot de contrôle est réalisée, cette opération étant notée : (CCW)- CW à l'étape E12, pour restituer le mot de contrôle CW. L'étape E12 est alors suivie de la transmission du mot de contrôle CW contenant la clé de service au terminal de désembrouillage T en vue de l'ouverture d'accès au programme ou film diffusé de numéro d'identification DIDF. REVENDICATIONS 1. Protocole de gestion à distance du contrôle d'accès à des informations embrouillées au moyen d'une clé de service et transmises en réseau entre un centre d'émission et au moins un poste récepteur, la transmission desdites informations embrouillées étant accompagnée d'un mot de contrôle (CW) contenant au moins ladite clé de service, ce mot de contrôle étant chiffré au moyen d'une clé d'exploitation (SOK), la transmission dudit mot de contrôle chiffré étant effectuée au moyen de messages de contrôle de titres d'accès, messages ECM, contenant au moins ledit mot de contrôle chiffré et des paramètres de contrôle de titre d'accès, lesdits messages ECM étant transmis et multiplexés dans le flux des informations embrouillées avec des messages de gestion de titres d'accès, messages EMM, chaque poste récepteur comportant au moins un terminal de désembrouillage des informations embrouillées comportant un module de contrôle d'accès muni d'un processeur de sécurité, ledit processeur de sécurité comportant ladite clé d'exploitation (SOK) et des titres d'accès inscrits alloués à un utilisateur abonné, mémorisés en mémoire protégée de ce processeur de sécurité et permettant, à partir de ladite clé d'exploitation et dudit mot de contrôle chiffré de restituer la clé de service, sur critère de vérification desdits titres d'accès inscrits, à partir des paramètres de contrôle des titres d'accès, chaque terminal de désembrouillage permettant, à partir de la clé de service restituée, le désembrouillage desdites informations embrouillées pour utilisation par un utilisateur abonné habilité, caractérisé en ce que ledit protocole consiste au moins : - à transmettre, du centre d'émission vers au moins un poste récepteur et/ou vers le processeur de sécurité associé à ce dernier, un message de commande, ce message de commande comportant des champs de données formant au moins un gabarit d'entrée, des données applicatives de commande et des données d'authenticité, ledit gabarit d'entrée contenant les attributs de sécurité appliqués auxdites données applicatives de commande, lesdites données d'authenticité permettant d'authentifier et de garantir l'intégrité dudit message de commande, à partir desdits attributs de sécurité, - à soumettre l'échange d'instructions d'action et de réponses à ces instructions d'action entre le terminal de désembrouillage et le processeur de sécurité à un protocole de sécurisation local spécifique, permettant de se prémunir contre une écoute locale à l'interface terminal de désembrouillage/processeur de sécurité, pour exécuter de manière sécurisée une suite de tâches constituées par l'exécution d'au moins une instruction d'action. 2. Protocole selon la revendication 1, caractérisé en ce que chaque poste récepteur étant relié au centre d'émission ou à un centre de gestion de ce centre d'émission par une voie de retour, celui-ci consiste, en outre, à calculer et transmettre, sur ladite voie de retour, un message de réponse, spécifique audit message de commande, ce message de réponse comportant des champs de données formant au moins un gabarit d'entrée, des données applicatives de réponse et des données d'état, ledit gabarit d'entrée contenant les attributs de sécurité appliqués aux données applicatives de réponse, l'absence de gabarit d'entrée, dans ledit message de réponse, correspondant à une absence de sécurité appliquée à ces données applicatives de réponse. 3. Protocole selon la revendication 1 ou 2, caractérisé en ce que chaque message de commande comporte en outre un champ de données formant un gabarit de réponse, ledit gabarit de réponse contenant les attributs de sécurité à appliquer aux données applicatives de réponse. 4. Protocole selon l'une des revendications 1 à 3, caractérisé en ce que lesdites données applicatives de commande étant chiffrées, lesdites données applicatives de commande chiffrées sont soumises à un processus de déchiffrement et d'authentification et en ce que les données applicatives de réponse sont chiffrées et authentifiées. 5. Protocole selon l'une des revendications 1 à 4, caractérisé en ce que, pour tout message de commande, lesdites données applicatives de commande comportent une instruction d'action ou une liste d'instructions d'action, traitée séquentiellement par le destinataire de ce message de commande, terminal ou processeur de sécurité du module de contrôle d'accès. 6. Protocole selon l'une quelconque des revendications 1 à 4, caractérisé en ce que lesdites données applicatives de commande et/ou de réponse sont programmables et comportent une combinaison logique de conditions dont le résultat binaire de la vérification logique, vrai ou faux, permet d'engendrer un branchement conditionnel d'actions, lesdites actions étant traitées séquentiellement par le terminal de désembrouillage ou le processeur de sécurité destinataire. 7. Protocole selon la revendication 6, caractérisé en ce que ledit message de commande et lesdites données applicatives de commande constituent une phrase logique structurée contenant la relation logique : Si (If) : L'expression logique de condition est vérifiée ; Alors (Then) : on exécute l'action ou la liste d'actions décrite dans le bloc descriptif de l'action ou de la liste d'actions associée à la condition vérifiée ; Sinon (Else) : on exécute l'action ou la liste d'actions décrites dans le bloc descriptif de l'action ou de la liste d'actions associée à cette condition non vérifiée. 8. Protocole selon la revendication 7, caractérisé en ce que le bloc non exécuté est en outre évalué. 9. Protocole selon l'une des revendications 6 à 8, caractérisé en ce que lesdits messages de commande et/ou de réponse sont dédiés : - à des actions de gestion commerciale indépendantes de, mais liées à, la gestion des titres d'accès, actions commerciales telles que gestion d'un porte jetons électronique implanté dans ledit processeur de sécurité, en fonction des titres d'accès inscrits dans ce processeur de sécurité ; - au contrôle des titres d'accès ; - à la gestion optimisée des titres d'accès inscrits, en fonction du comportement de l'utilisateur abonné habilité ; - à la gestion de la sécurité locale d'échange de messages entre le processeur de sécurité et le terminal de désembrouillage ; - à des actions de liaison entre message ECM et message EMM ; - à des actions de gestion de la sécurité des informations embrouillées. 10. Protocole selon l'une des revendications 1 à 9, caractérisé en ce que, pour un message de commande comportant au moins un champ de données applicatives de commande, ledit terminal de désembrouillage et ledit processeur de sécurité comportant des ressources cryptographiques de chiffrement/déchiffrement, de calcul et de vérification d'authenticité, ledit protocole de sécurisation local spécifique consiste : . au niveau dudit terminal de désembrouillage - à soumettre lesdites données applicatives de commande dudit message de commande à un processus de chiffrement local et d'authentification locale, indépendants des processus de chiffrement mis en oeuvre préalablement à la transmission dudit message de commande, pour engendrer des données de commande localement sécurisées ; - à transmettre dudit terminal de désembrouillage vers ledit processeur de sécurité des messages locaux de commande chiffrés, formés à partir desdites données de commande localement sécurisées, et . au niveau dudit processeur de sécurité - à soumettre lesdits messages locaux de commande chiffrés à un processus de déchiffrement local et d'authentification locale pour restituer ledit champ de données applicatives de commande ; - à soumettre ledit champ de données applicatives de commande à un processus d'authentification et restituer, à partir du champ de données applicatives de commande, des suites d'instructions d'actions exécutables selon au moins une tâche ; - à exécuter ladite suite d'instructions d'actions exécutables selon au moins une tâche. 11. Protocole selon l'une des revendications 1 à 10, caractérisé en ce que ledit terminal de désembrouillage et ledit processeur de sécurité comportant des ressources cryptographiques de chiffrement/déchiffrement, de calcul et de vérification d'authenticité, ledit protocole de sécurisation local spécifique consiste en outre, suite à l'exécution d'au moins une instruction d'action exécutable selon au moins une tâche : . au niveau dudit processeur de sécurité - à calculer des données applicatives de réponse, à partir de l'exécution d'au moins une instruction d'action exécutable selon au moins une tâche ; - à soumettre lesdites données applicatives de réponse à un processus de sécurisation par chiffrement local et authentification locale, pour engendrer des données applicatives de réponse localement sécurisées ; - à transmettre, dudit processeur de sécurité vers ledit terminal de désembrouillage, des messages locaux de réponse contenant les données applicatives de réponse localement sécurisées ; et . au niveau dudit terminal de désembrouillage - à soumettre lesdites données applicatives de réponse localement sécurisées à un processus de déchiffrement local et de vérification d'authenticité locale, pour restituer lesdites données applicatives de réponse, constitutives dudit message de réponse. 12. Protocole selon la revendication 11, caractérisé en ce que, dans le cas de messages de réponse destinés au centre d'émission ou à un centre de gestion de ce centre d'émission, celui-ci comporte en outre une étape consistant à soumettre les données applicatives de réponse à un processus de chiffrement et d'authentification général pour engendrer des données applicatives de réponse chiffrées, ladite étape étant conduite préalablement à l'étape consistant à soumettre lesdites données applicatives de réponse à un processus de chiffrement local et d'authentification locale. 13. Protocole selon l'une des revendications 9 à 12, caractérisé en ce que ledit processus de sécurisation local comporte en outre un processus d'indexation des messages de commande et de réponse permettant la détection de filtrage ou de rejeu. 14. Protocole selon l'une des revendications 9 à 13, caractérisé en ce que, pour un message de commande comportant au moins un champ de données applicatives de commande, ledit terminal de désembrouillage et ledit processeur de sécurité comportant des ressources cryptographiques de chiffrement/déchiffrement, de calcul et de vérification d'authenticité, ledit protocole de sécurisation local spécifique consiste au moins : . au niveau dudit processeur de sécurité - à soumettre lesdites données applicatives de commande à un test de discrimination de leur destination au processeur de sécurité respectivement au terminal de désembrouillage ; et .. lorsque les données applicatives de commande en clair sont destinées audit processeur de sécurité, - à exécuter ladite suite d'instructions d'actions exécutables selon au moins une tâche ; sinon, .. lorsque les données applicatives de commande en clair sont destinées au terminal de désembrouillage, - à soumettre lesdites données applicatives de commande à un processus de chiffrement local et d'authentification locale, pour engendrer des données applicatives de commande localement sécurisées ; - a transmettre lesdites données applicatives de commande localement sécurisées dudit processeur de sécurité vers ledit terminal de désembrouillage ; et . au niveau dudit terminal de désembrouillage, - à soumettre lesdites données applicatives de commande localement sécurisées à un processus de déchiffrement local et d'authentification locale, pour restituer lesdites données applicatives de commande, et constituer des suites d'instructions d'actions exécutables selon au moins une tâche ; - à exécuter lesdites instructions d'actions exécutables selon au moins une tâche. 15. Protocole selon l'une des revendications 1 à 13, caractérisé en ce que ledit protocole de sécurisation local est exécuté par chiffrement/déchiffrement symétrique à partir d'une clé de chiffrement/déchiffrement et d'authentification locale, spécifique à chaque couple terminal de désembrouillage/processeur de sécurité, ladite clé de chiffrement/déchiffrement et d'authentification locale étant paramétrée à partir d'un secret spécifique audit processeur de sécurité et/ou audit terminal de désembrouillage dudit couple. 16. Protocole selon la revendication 15, caractérisé en ce que ladite clé de chiffrement/déchiffrement et d'authentification locale est modifiée périodiquement. 17. Protocole selon l'une quelconque des revendications 1 à 16, caractérisé en ce que chaque message de commande comporte un champ de spécification du format du message de réponse correspondant, selon un format de réponse longue ou courte, en fonction du contexte applicatif et du détail d'informations requis dans le cadre de ce contexte applicatif. 18. Message de commande émis à partir d'un centre d'émission vers au moins un poste récepteur, ce poste récepteur comportant au moins un terminal de désembrouillage d'informations embrouillées et un module de contrôle d'accès muni d'un processeur de sécurité coopérant avec ledit terminal de désembrouillage, par échange de messages locaux de commande respectivement de réponse sur une liaison locale terminal de désembrouillage/processeur de sécurité, caractérisé en ce que ledit message de commande comporte au moins : - un champ de données constituant un gabarit d'entrée ; - un champ de données applicatives de commande destinées à commander ledit terminal de désembrouillage et/ou ledit processeur de sécurité par l'intermédiaire desdits messages locaux de commande ; - un champ de données d'authenticité, ledit gabarit d'entrée contenant des attributs de sécurité appliqués auxdites données applicatives de commande et lesdites données d'authenticité permettant d'authentifier ledit message de commande. 19. Message de commande selon la revendication 18, caractérisé en ce que celui-ci comporte en outre un champ de données formant un gabarit de réponse, ledit gabarit de réponse contenant les attributs de sécurité à appliquer aux données applicatives de réponse, établies en réponse audit message de commande. 20. Message de réponse émis, à partir d'un poste récepteur de messages de commande, vers un centre d'émission de ces messages de commande, ledit poste récepteur comportant au moins un terminal de désembrouillage d'informations embrouillées et un module de contrôle d'accès muni d'un processeur de sécurité coopérant avec ledit terminal de désembrouillage, par échange de messages locaux de commande respectivement de réponse sur une liaison locale terminal de désembrouillage/processeur de sécurité, caractérisé en ce que ledit message de réponse comporte au moins : - un champ de données formant un gabarit d'entrée ; - un champ de données d'état, ledit gabarit d'entrée comportant des attributs de sécurité à appliquer aux données applicatives de réponse, l'absence de gabarit d'entrée, dans ledit message de réponse, correspondant à une absence de sécurité appliquée à ces données applicatives de réponse. 21. Message de commande respectivement de réponse, selon l'une des revendications 18 à 20, caractérisé en ce que lesdites données applicatives de commande respectivement de réponse sont programmables, le champ de données applicatives de commande respectivement de réponse comportant une combinaison logique de conditions dont le résultat binaire de la vérification logique, vrai ou faux, permet d'engendrer un branchement conditionnel d'actions, lesdites actions étant traitées séquentiellement par ledit terminal de désembrouillage et/ou ledit processeur de sécurité respectivement par ledit poste émetteur destinataire.