Brevet FR2825209A1 — publié le 20021129

La présente invention se rapporte à la sécurisation et à l'identification de messages sur un réseau, ainsi qu'à des dispositifs correspondants. Afin de sécuriser la circulation de messages sur un réseau non sécurisé, que cette circulation s'effectue notamment par radiodiffusion, par le câble ou par le réseau Internet, il est classique d'utiliser des clés de chiffrement, appelées aussi clés de cryptage. En général, l'émetteur des messages dispose d'une telle clé de chiffrement et le récepteur, d'une clé d'identification correspondante. Les clés peuvent être privées ou publiques, selon les applications visées. Par exemple, un émetteur utilise une biclé (key pair), dont il diffuse une clé de chiffrement publique permettant de chiffrer des messages et conserve pour lui seul une clé de déchiffrement privée. Le chiffrement des messages a deux types principaux d'applications : - l'authentification des messages, pour laquelle les résultats du chiffrement sont incorporés dans les messages sous forme de signature ; la clé d'identification peut alors être soit une clé de déchiffrement, soit une clé de chiffrement ; - et le cryptage des messages, pour lequel les résultats du chiffrement remplacent des portions du message chiffré ; la clé d'identification est alors une clé de déchiffrement. Dans ces deux types d'applications, il convient de minimiser les risques d'interception et de déchiffrement frauduleux des messages par un tiers, ou de falsification par l'apposition frauduleuse d'une signature. Plusieurs systèmes ont donc été proposés pour compliquer les possibilités de chiffrement ou de déchiffrement non autorisés. Ainsi, des techniques ont été développées pour pouvoir modifier régulièrement les clés de chiffrement et d'identification correspondantes. Certaines de ces techniques reposent sur l'envoi de nouvelles clés d'identification à travers le réseau de communication, en rendant difficile la reconnaissance de ces clés (par exemple par cryptage des clés), notamment lorsque ces dernières sont des clés privées. Ces techniques exposent cependant à une interception des clés envoyées et à leur utilisation, malgré les précautions prises. De plus, elles requièrent à chaque envoi d'une nouvelle clé, la reconnaissance et l'installation de cette dernière par le récepteur, ce qui peut être pénalisant pour l'efficacité de ce dernier. Le document EP-0. 506.637 décrit un système de validation et de vérification de stations mobiles d'un réseau de communications de radio cellulaire. Le système inclut une clé fixe et une clé modifiable appelée clé tournante, à la fois dans le réseau et dans les stations mobiles. Ces clés sont appliquées en entrées d'un algorithme d'authentification et une comparaison des réponses générées par le réseau et dans chaque station mobile permet de repérer des fraudes. La clé tournante est mise à jour simultanément dans le réseau et la station mobile à chaque authentification bilatérale, en fonction d'informations historiques d'authentification, communes à l'un et à l'autre. La sécurité des échanges peut être ainsi accrue, car les clés sont régulièrement modifiées sans transiter par le réseau. Cependant, un inconvénient d'un tel système est qu'il nécessite un calcul d'une nouvelle clé tournante à chaque authentification bilatérale. De plus, des problèmes d'asynchronisme risquent de se poser en présence d'un dysfonctionnement technique, et de rendre ainsi l'authentification inutilisable. Pour y remédier, des mécanismes spécifiques doivent être implantés, ce qui complexifie les systèmes et risque de réduire la fiabilité de l'authentification. Le brevet US-6.105. 133 divulgue un système bilatéral d'authentification et de cryptage de stations émettrices-réceptrices. Les échanges entre deux quelconques des stations sont sécurisés par authentification et cryptage, et par l'utilisation d'une clé de chiffrement modifiée à chaque connexion entre ces stations. Cette clé est calculée indépendamment dans chacune des stations, à partir de l'identificateur de l'autre station, de paramètres enregistrés de manière fixe dans les deux stations et d'une valeur de changement communiquée d'une station à l'autre. Cette technique accroît la fiabilité du système en permettant une modification fréquente de la clé de chiffrement, en évitant le transfert de cette clé sur le réseau et en assurant une synchronisation des mises à jour de clé dans les stations émettrices et réceptrices. Cependant, elle requiert à chaque mise à jour le calcul d'une nouvelle clé, dans l'émetteur comme dans le récepteur. Les temps nécessaires à ces calculs risquent de porter préjudice aux opérations à effectuer rapidement après la réception des messages. En particulier, ces temps sont la cause de dysfonctionnement lorsque les messages à décrypter et/ou authentifier sont suivis d'autres messages dont le traitement nécessite la connaissance des messages antérieurs, et que le laps de temps entre les messages antérieurs et les messages postérieurs est insuffisant pour acquérir cette connaissance. La présente invention concerne un dispositif de sécurisation de messages destinés à être envoyés sur un réseau et reposant sur l'utilisation d'une clé de chiffrement modifiable, le dispositif de sécurisation permettant de modifier cette clé sans avoir à la faire transiter par le réseau, de synchroniser les mises à jour de clés dans l'émetteur et le récepteur des messages, et d'effectuer les changements de clés très rapidement. De plus, le dispositif de l'invention peut être mis en oeuvre de manière économique, sans faire appel à des algorithmes sophistiqués de mise à jour de clés. L'invention concerne également un dispositif d'identification de messages reçus via un réseau, permettant d'obtenir les avantages mentionnés plus haut. L'invention s'applique aussi à un émetteur de messages comprenant un ou plusieurs dispositifs de sécurisation selon l'invention, à un récepteur de messages comprenant un ou plusieurs dispositifs d'identification selon l'invention, et à un produit programme d'ordinateur, un message et des procédés de sécurisation et d'identification correspondants. 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). L'invention s'applique généralement à des processus de sécurisation, par signature électronique 1 authentification et/ou par cryptage/ décryptage. Elle repose sur l'utilisation de clés de chiffrement à l'émission et de clés de chiffrement et/ou de déchiffrement à la réception, des clés de déchiffrement étant mises en oeuvre en décryptage et des clés de déchiffrement et/ou de chiffrement étant mises en oeuvre en authentification. A cet effet, l'invention a pour objet un dispositif de sécurisation de messages destinés à être envoyés sur un réseau, vers au moins un récepteur comprenant des moyens de commande d'identification de messages par une clé courante d'identification modifiable. Le dispositif de sécurisation comprend : - une unité de commande de chiffrement d'au moins une partie de chacun des messages au moyen d'une clé courante de chiffrement modifiable, - une unité de changement de la clé courante de chiffrement, - et une unité d'inscription dans le message d'informations de modification de la clé courante d'identification dans le récepteur, ces informations de modification servant au récepteur à modifier la clé courante d'identification de manière à ce que cette clé courante d'identification corresponde à la clé courante de chiffrement. Selon l'invention : - l'unité de changement de la clé courante de chiffrement est prévue pour sélectionner cette clé dans un jeu prédéterminé de clés disponibles de chiffrement, - et l'unité d'inscription est prévue pour inscrire dans le message un identificateur de clé, servant au récepteur à sélectionner la clé courante d'identification dans un jeu prédéterminé de clés disponibles d'identification correspondant au jeu prédéterminé des clés disponibles de chiffrement. Comme indiqué plus haut, on désigne par clés d'identification des clés de déchiffrement ou de chiffrement, qui sont associées respectivement à des clés de chiffrement utilisées par le dispositif de sécurisation. En décryptage, le jeu de clés d'identification est un jeu de clés de déchiffrement, chaque clé de déchiffrement ayant la même longueur que la clé de chiffrement correspondante utilisée pour le cryptage. En authentification, ce jeu consiste en des clés de déchiffrement, des clés de chiffrement ou une combinaison des deux types de clés, générées respectivement à partir des clés de chiffrement correspondantes à l'émission. Chaque clé d'identification, et tout particulièrement de chiffrement, utilisée par le récepteur a alors de préférence une longueur sensiblement inférieure à la clé de chiffrement correspondante utilisée par le dispositif de sécurisation pour générer la signature. En effet, il n'est pas nécessaire de décrypter ou de reconstituer complètement la signature : une coïncidence partielle suffit à assurer l'authenticité du message. On simplifie ainsi les opérations d'authentification et, pour les clés d'identification constituées de clés de chiffrement, on réduit les risques de production frauduleuse de signatures, en ne diffusant pas auprès des récepteurs les clés de chiffrement complètes utilisées à l'émission. De manière surprenante, l'envoi d'un simple identificateur suffit à obtenir précisément la clé d'identification souhaitée, de façon quasi- instantanée dans le récepteur. Ce résultat est obtenu grâce à un enregistrement préalable de deux jeux de clés disponibles correspondants, respectivement à l'émission et à la réception, et à l'indexation de ces clés. Le dispositif de l'invention autorise un changement de clé lors de l'envoi de tout message, ou de tout message d'un type donné. Dans une première forme d'indication de clés, l'identificateur de clé est joint à tout message susceptible de faire l'objet d'une modification de clé. La clé correspondant à cet indicateur à la réception est alors systématiquement sélectionnée à partir de l'identificateur, et utilisée pour l'identification. Dans une deuxième forme d'indication de clés, l'identificateur de clé est complété par un indicateur binaire de modification de clé. A la réception, la clé d'identification courante est alors gardée en mémoire jusqu'à ce que l'indicateur de changement de clé signale un changement de clé. Dans une troisième forme d'identification de clés, l'identificateur de clé n'est spécifié qu'en cas d'un changement effectif de clé. Sinon, l'identificateur de clé est remplacé par une valeur par défaut (par exemple 0), signalant que la clé précédemment utilisée est encore valable. Cette troisième forme économique est intéressante dans des cas d'émission de messages vers un ensemble de récepteurs qui sont toujours à l'écoute des messages et n'en ratent aucun. Elle est notamment applicable en multidiffusion (multicasting) sur le Web. L'identificateur de clé peut être déterminé de diverses manières, tant en ce qui concerne la fréquence de changement que la sélection de clé effectuée. Ainsi, dans une première forme de changement, l'identificateur de clé est changé sur demande d'un utilisateur à l'émission, qui peut déterminer ainsi à la fois les occurrences de changement et les nouvelles clés sélectionnées. Dans une deuxième forme de changement, l'identificateur de clé est modifié de façon périodique, selon une période choisie par l'utilisateur, et le nouvel identificateur est tiré aléatoirement. Dans une troisième forme de changement, l'identificateur est modifié selon une série prédéterminée de valeurs, à des instants choisis aléatoirement mais espacés de durées comprises entre une durée minimale et une durée maximale. Dans la deuxième et la troisième formes de changement, il est préférable que l'utilisateur exploitant le système puisse de toute manière modifier la clé courante à n'importe quel moment. Les clés à l'émission et à la réception peuvent être privées ou publiques. De préférence, en cryptage, les clés à la réception sont privées, de manière à garantir la confidentialité des messages, tandis qu'en authentification, les clés à l'émission sont privées, de manière à garantir l'identité de l'expéditeur. Les autres clés sont avantageusement publiques. Avantageusement, l'unité de commande de chiffrement fait appel à une bibliothèque de chiffrement, dans laquelle sont stockées les clés de chiffrement disponibles. Dans un premier mode de réalisation du dispositif de sécurisation (authentification), celui-ci comprend des moyens de commande d'ajout dans chacun des messages, d'une signature consistant en un résultat du chiffrement de la partie à chiffrer du message au moyen de la clé courante de chiffrement. Le jeu prédéterminé de clés disponibles d'identification est alors avantageusement un jeu de clés de déchiffrement. De plus, de préférence, la partie du message à chiffrer consiste en le message entier hors signature, incluant l'identificateur de clé. Ainsi, l'authentification porte non seulement sur l'identité de l'expéditeur et la charge utile du message, mais plus généralement sur toutes les informations contenues dans le message, y compris sur le choix de la clé d'identification et sur d'éventuels paramètres de fonctionnement au niveau du récepteur. Dans un deuxième mode de réalisation du dispositif de sécurisation (cryptage), chacun des messages comprenant un en-tête et une charge utile, l'unité de commande de chiffrement est prévue pour commander : - un chiffrement de la partie du message à crypter par la clé courante de chiffrement, cette partie comprenant au moins une portion de la charge utile, - et un remplacement dans le message de cette partie par des informations cryptées consistant en un résultat du chiffrement de cette partie au moyen de la clé courante de chiffrement Le dispositif de sécurisation de l'invention est associé à une unique clé courante de chiffrement, et correspond donc généralement soit à une authentification, soit à un cryptage. Cependant, plusieurs dispositifs de sécurisation conformes à l'invention sont avantageusement combinés dans un émetteur. On produit ainsi avantageusement un chiffrement à deux niveaux : - cryptage avec une première clé courante de chiffrement sélectionnée dans un premier jeu de clés disponibles, - puis signature avec une seconde clé courante de chiffrement sélectionnée dans un second jeu de clés disponibles, le chiffrement étant préférentiellement appliqué à l'ensemble du message hors signature, y compris la partie cryptée. Préférentiellement, les messages faisant l'objet de la sécurisation sont 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). Préférentiellement, les messages sont choisis parmi des messages d'annonce ATVEF (c'est-à-dire selon la norme Advanced Television Enhancement Forum) et/ou des messages d'annonce 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. Chacun des messages d'annonce de services ayant un champ d'authentification de longueur variable, l'unité d'inscription est préférentiellement prévue pour inscrire l'identificateur de clé dans ce champ d'authentification. Cette réalisation est avantageuse 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. Selon un premier mode de reconnaissance de clés, chacun des identificateurs de clés est associé à une des clés disponibles de chiffrement déterminée et à une des clés disponibles d'identification déterminée correspondant à cette clé de chiffrement. L'identificateur de clé sélectionné donne donc de manière univoque la clé à utiliser à la réception. Cette réalisation permet de parvenir rapidement à garantir l'origine et l'intégrité du message. Selon un deuxième mode de reconnaissance de clés, chacun des identificateurs de clés est associé à un bloc déterminé de clés de chiffrement parmi le jeu de clés disponibles de chiffrement et à un bloc déterminé de clés d'identification correspondant respectivement aux clés de chiffrement, parmi le jeu de clés disponibles d'identification. L'identificateur de clé sélectionné ne permet donc pas au récepteur de connaître immédiatement la clé d'identification à utiliser. Il doit procéder à des tests successifs avec les différentes clés du bloc visé, jusqu'à parvenir à celle appropriée. Ce mode de réalisation offre donc une protection supplémentaire contre le piratage, au prix d'une complexité et d'une durée d'authentification ou de décryptage accrues. De façon avantageuse, l'unité d'inscription est prévue pour choisir l'identificateur de clé parmi un nombre de valeurs (pouvant correspondre à des clés ou à des blocs de clés) compris entre 8 et 12, et préférentiellement égal à 10. Dans d'autres réalisations assurant une sécurité accrue, ce nombre de valeurs vaut 256 (codage de l'identificateur sur un octet) ou même 65536 (codage sur deux octets). Par ailleurs, les clés à l'émission et à la réception peuvent de préférence être mises à jour. Par exemple, le jeu des clés d'identification est prévu pour être modifié à distance, par connexion des récepteurs à des serveurs, identification des récepteurs et récupération sécurisée d'une table de clés d'identification via le réseau. L'invention s'applique aussi à un émetteur de messages. Selon l'invention, celui-ci comprend au moins un dispositif de sécurisation conforme à l'un quelconque des modes de réalisation de l'invention, cet émetteur étant préférentiellement prévu pour émettre les messages par diffusion générale. Par diffusion générale ou broadcasting, on 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 1 nternet. L'invention concerne aussi un dispositif d'identification de messages reçus via un réseau, chacun des messages incluant une partie chiffrée au moyen d'une clé courante de chiffrement modifiable. Ce dispositif d'identification comprend : - une unité de commande d'identification de la partie chiffrée, au moyen d'une clé courante d'identification modifiable, - et une unité d'extraction dans ce message, d'informations de modification de la clé courante d'identification, les informations de modification servant à modifier la clé courante d'identification de manière à ce que cette clé courante d'identification corresponde à la clé courante de chiffrement. Selon l'invention, l'unité d'extraction est prévue pour extraire du message un identificateur de clé, servant à sélectionner la clé courante d'identification dans un jeu prédéterminé de clés disponibles d'identification correspondant à un jeu prédéterminé de clés disponibles de chiffrement. Ce dispositif d'identification de messages est préférentiellement capable d'identifier les messages sécurisés au moyen de l'un quelconque des modes de réalisation d'un dispositif de sécurisation conforme à l'invention. L'invention s'applique également à un récepteur de messages. Selon l'invention, celui-ci comprend au moins un dispositif d'identification conforme à l'un quelconque des modes de réalisation selon l'invention. De plus, 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 aussi pour objet un produit programme d'ordinateur. Selon l'invention, celui-ci comprend des fonctionnalités de mise en oeuvre des unités du dispositif de sécurisation de messages ou du dispositif d'identification de messages, 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 est de plus relative à un message destiné à être envoyé sur un réseau vers au moins un récepteur. Ce message inclut : - au moins une partie chiffrée au moyen de respectivement au moins une clé courante de chiffrement modifiable, - et des informations de modification d'au moins une clé courante d'identification modifiable, les clés courantes d'identification permettant d'identifier respectivement les parties chiffrées. Selon l'invention, les informations de modification consistent en au moins un identificateur de clé, servant respectivement à sélectionner les clés courantes d'identification dans des jeux prédéterminés de clés disponibles d'identification. Le message est préférentiellement obtenu au moyen d'un dispositif de sécurisation de messages, et est préférentiellement destiné à un dispositif d'identification de messages, conformes à l'un quelconque des modes de réalisation de l'invention. Un autre aspect de l'invention est un procédé de sécurisation de messages destinés à être envoyés sur un réseau, vers au moins un récepteur comprenant des moyens de commande d'identification par une clé courante d'identification modifiable. Le procédé de sécurisation comprend : - une étape de changement d'une clé courante de chiffrement modifiable permettant de chiffrer au moins une partie de chacun des messages, - une étape d'inscription dans ce message d'informations de modification de la clé courante d'identification dans le récepteur, ces informations de modification servant au récepteur à modifier la clé courante d'identification de manière à ce que cette clé courante d'identification corresponde à la clé courante de chiffrement, - et une étape de chiffrement de la partie à chiffrer du message, au moyen de la clé courante de chiffrement. Selon l'invention : - lors du changement de la clé courante de chiffrement, on sélectionne cette clé dans au moins un jeu prédéterminé de clés disponibles de chiffrement, - et les informations de modification consistent en un identificateur de clé, servant au récepteur à sélectionner la clé courante d'identification dans un jeu prédéterminé de clés disponibles d'identification correspondant au jeu prédéterminé de clés disponibles de chiffrement. Ce procédé de sécurisation de messages est préférentiellement mis en oeuvre au moyen d'un dispositif de sécurisation de messages conforme à l'un quelconque des modes de réalisation de l'invention. L'invention est aussi relative à un procédé d'identification de messages reçus via un réseau, chacun de ces messages incluant une partie chiffrée au moyen d'une clé courante de chiffrement modifiable. Ce procédé d'identification comprend : - une étape d'extraction dans ce message, d'informations de modification d'une clé courante d'identification modifiable permettant d'identifier la partie chiffrée, les informations de modification servant à modifier la clé courante d'identification de manière à ce que la clé courante d'identification corresponde à la clé courante de chiffrement, - et une étape d'identification de ladite partie chiffrée au moyen de la clé courante d'identification. Selon l'invention, les informations de modification consistent en un identificateur de clé, au moyen duquel on sélectionne la clé courante d'identification dans un jeu prédéterminé de clés disponibles d'identification. Ce procédé d'identification de messages est préférentiellement mis en oeuvre au moyen d'un dispositif d'identification de messages conforme à l'un quelconque des modes de réalisation de l'invention. L'invention sera mieux comprise et illustrée au moyen des exemples suivants de réalisation et de mise en oeuvre, 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 oeuvre une première forme de sélection des clés ; - 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, 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 de l'authentification de messages de services ATVEF en combinaison avec l'émetteur de la Figure 2, mais aussi notamment pour l'authentification de messages de services système et pour du décryptage ; - 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 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 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 oeuvre 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, 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 ; dans l'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 ; par 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 Ki, K... , ! e modu) e 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 KI à utiliser ; - une unité de changement 12 de clé courante, permettant de modifier la clé courante KI à utiliser en envoyant des informations correspondantes à l'unité de commande de chiffrement 11 ; cette 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 KI, avec possibilité d'intervention directe d'un utilisateur ; - et une unité d'inscription 13 dans le message MO d'un identificateur de clé KeylD, 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'i, K's-.-K'n, correspondant une à une aux clés de chiffrement K, K.-. 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',, 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é KeylD, 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 M 1 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 11 sous forme d'une unité de commande d'authentification 11 A, 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é Kl 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) IIP 1 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). it 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 oeuvre 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 multiast 224.0. 1.113, port 2670, et ceux du type système sur une adresse IP multiast 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 : 0 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) ; dans le 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 ; - OxOO02 : 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 ; - OxOO010 : 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 ; - OxOO020 : 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 ; - OxOO040 : 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 M 1 est déjà signé ; si oui, retour au serveur de diffusion 32A ; - sinon, mise à jour de la longueur L-AUTH à 132 octets (0x21 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 OxOO, est le suivant : 00000000 [2001 0000 53AA OB8D 2700 0000] 763D 300A... S...'... v=O. 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&commat;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=0 O. 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 KeylD=OxO7, est le suivant : 00000000 [2021 0000 53AA OB8D 2027 0007 6797 BE9E !.. S...'.. g... 00000010 7169 8F8D FDF1 B330 38FF 957C DOA2 B515 qi..... 08.. 1.... 00000020 lF98 DABC CB04 9F03 OEB8 3D27 E5AA 047A.......... ='... z 00000030 35AF F2FF DC65 4F04 28E3 CA3F 948D 1D8A 5.... eO. (.. ?... 00000040 4540 D763 DB68 3ADD CAEF 5EB1 4116 F939 E&commat;. c. h :... ^. A.. 9 00000050 7C29 862F E7B8 75C1 081C 3830 5A55 AEC2 1)./.. u... 80ZU.. 00000060 1031 62CO E52D AC19 1CCF 7471 D28E 8997. lob..-.... tq.... 00000070 7F46 9473 4F2A B5EF 8047 2DE9 87EF A49E. F. sO*... G...... 00000080 4E90 5DB7 0981 COOl DB17 F07F] 763D 300A N. ]......... v=O. 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&commat;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 : 1. t=0 O. 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 IP/UDP, 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 MSG- A ; - 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 1 B (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 1 B 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 b ! ocs Bi, B.. B de clés de chiffrement, au lieu d'une table de clés. Chacun des blocs B, inclut lui-même plusieurs clés K, K, :,... K,,,, 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', 1, K', 2... K', j, correspondant respectivement aux clés Ki,1, Ki,2... K@,@@ 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',, 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 KeylD[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 sécurisation (3) de messages (MSG) destinés à être envoyés sur un réseau, vers au moins un récepteur (2) comprenant des moyens de commande d'identification (21) de messages (MSG) par une clé courante d'identification (K',, K', j) modifiable, ledit dispositif de sécurisation (3) comprenant : - une unité de commande de chiffrement (11) d'au moins une partie de chacun desdits messages (MSG) au moyen d'une clé courante de chiffrement (Ki, Ki,j) modifiable, - une unité de changement (12) de ladite clé courante de chiffrement (Ki, Ki,j), - et une unité d'inscription (13) dans ledit message (MSG) d'informations de modification (KeyID) de la clé courante d'identification (K',, K', j) dans ledit récepteur (2), lesdites informations de modification (KeyID) servant audit récepteur (2) à modifier la clé courante d'identification (K',, K', j) de manière à ce que ladite clé courante d'identification (K',, K', ) corresponde à la clé courante de chiffrement (K,, K, j), caractérisé en ce que : - l'unité de changement (12) de la clé courante de chiffrement (K,, K, j) est prévue pour sélectionner ladite clé (K,, KI) dans un jeu prédéterminé (16,76) de clés disponibles de chiffrement (K1... Kn, K1,1...Kn,ln), - et l'unité d'inscription (13) est prévue pour inscrire dans ledit message (MSG) un identificateur de clé (KeyID), servant au récepteur (2) à sélectionner la clé courante d'identification (K',, K', j) dans un jeu prédéterminé (26,86) de clés disponibles d'identification (K'... K'n ; K'1,1...K'n,ln) correspondant audit jeu prédéterminé (16,76) des clés disponibles de chiffrement (K1... Kn ; Ka... Knjn). 2. Dispositif de sécurisation (3) selon la revendication 1, caractérisé en ce qu'il comprend des moyens de commande (11A, 11A') d'ajout dans chacun desdits messages (MSG), d'une signature (SGN) consistant en un résultat du chiffrement de ladite partie dudit message au moyen de ladite clé courante de chiffrement (K,, K, ). 3. Dispositif de sécurisation (3) selon la revendication 2, caractérisé en ce que le jeu prédéterminé (26,86) de clés disponibles d'identification (K'1... K'n ; K\j... K'njn) est un jeu de clés de déchiffrement. 4. Dispositif de sécurisation (3) selon l'une des revendications 2 ou 3, caractérisé en ce que ladite partie dudit message consiste en ledit message entier hors signature, incluant l'identificateur de clé (KeyID [SGN]). 5. Dispositif de sécurisation (3) selon la revendication 1, caractérisé en ce que chacun desdits messages (MSG-B) comprenant un en-tête (SAP-B) et une charge utile (SDP), l'unité de commande de chiffrement (11-B) est prévue pour commander un chiffrement de ladite partie (CRYPT) dudit message (MSG-B) par ladite clé courante de chiffrement, ladite partie (CRYPT) comprenant au moins une portion de ladite charge utile (SDP), et un remplacement dans ledit message (MSG-B) de ladite partie (CRYPT) par des informations cryptées (CRYPT') consistant en un résultat du chiffrement de ladite partie au moyen de ladite clé courante de chiffrement (K,, KJ. 6. Dispositif de sécurisation (3) selon l'une quelconque des revendications précédentes, caractérisé en ce que lesdits messages (MSG) sont des messages d'annonce de services. 7. Dispositif de sécurisation (3) selon la revendication 6, caractérisé en ce que lesdits messages (MSG) sont choisis parmi des messages d'annonce ATVEF et/ou des messages d'annonce système. 8. Dispositif de sécurisation (3) selon l'une des revendications 6 ou 7, caractérisé en ce que chacun desdits messages ayant un champ d'authentification (AUTH) de longueur (L-AUTH) variable, l'unité d'inscription (13) est prévue pour inscrire l'identificateur de clé (KeyID) dans ledit champ d'authentification (AUTH). 9. Dispositif de sécurisation (3) selon l'une quelconque des revendications précédentes, caractérisé en ce que chacun desdits identificateurs de clés (KeyID) est associé à une des clés disponibles de chiffrement (K1... Kn) déterminée et à une des clés disponibles d'identification (K'i... K'n) déterminée correspondant à ladite clé de chiffrement. 10. Dispositif de sécurisation (3) selon l'une quelconque des revendications 1 à 9, caractérisé en ce que chacun desdits identificateurs de clés (KeyID) est associé à un bloc (B,) déterminé de clés de chiffrement (K', j) parmi le jeu (16,76) de clés disponibles de chiffrement (Ki i... KnJ et à un bloc (B',) déterminé de clés d'identification (K', j) correspondant respectivement aux dites clés de chiffrement (K', j), parmi le jeu (26,86) de clés disponibles d'identification (K\ i... K\, n). 11. Dispositif de sécurisation (3) selon l'une quelconque des revendications précédentes, caractérisé en ce que l'unité d'inscription (13) est prévue pour choisir l'identificateur de clé (KeyID) parmi un nombre de valeurs compris entre 8 et 12, et préférentiellement égal à 10. 12. Emetteur (1) de messages (MSG) caractérisé en ce qu'il comprend au moins un dispositif de sécurisation (3) conforme à l'une quelconque des revendications 1 à 11, ledit émetteur étant préférentiellement prévu pour émettre les messages (MSG) par diffusion générale. 13. Dispositif d'identification (4) de messages (MSG) reçus via un réseau, chacun desdits messages (MSG) incluant une partie chiffrée (SGN, CRYPT') au moyen d'une clé courante de chiffrement (K,, K,) modifiable, ledit dispositif d'identification (4) comprenant : - une unité de commande d'identification (21) de ladite partie chiffrée (SGN, CRYPT') au moyen d'une clé courante d'identification (K',, K', j) modifiable, - et une unité d'extraction (23) dans ledit message (MSG) d'informations de modification (Key) D) de) a dé courante d'identification (K',, K', j), lesdites informations de modification servant à modifier la clé courante d'identification (K',, K', ) de manière à ce que ladite clé courante d'identification (K',, K', j) corresponde à ladite clé courante de chiffrement (K,, Ki,j), caractérisé en ce que l'unité d'extraction (23) est prévue pour extraire du message (MSG) un identificateur de clé (KeyID), servant à sélectionner la clé courante d'identification (K',, K',) dans un jeu prédéterminé (26,86) de clés disponibles d'identification (K'1... K'n ; K'1, 1... K'njn) correspondant à un jeu prédéterminé (16,76) de clés disponibles de chiffrement (K1... Kn ; K1, 1... Kn, ln)' ledit dispositif d'identification (4) de messages (MSG) étant préférentiellement capable d'identifier les messages (MSG) sécurisés au moyen d'un dispositif de sécurisation (3) conforme à l'une quelconque des revendications 1 à 11. 14. Récepteur (2) de messages (MSG) caractérisé en ce qu'il comprend au moins un dispositif d'identification (4) conforme à 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 oeuvre desdites unités (11-13 ; 21, 23) du dispositif de sécurisation (3) de messages (MSG) conforme à l'une quelconque des revendications 1 à 11 ou du dispositif d'identification (4) de messages (MSG) 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 une partie chiffrée (SGN, CRYPT') au moyen de respectivement au moins une clé courante de chiffrement (K,, K, j) modifiable, - et des informations de modification (KeyID) d'au moins une clé courante d'identification (K'" K", J) modifiable, lesdites clés courantes d'identification permettant d'identifier respectivement lesdites parties chiffrées (SGN, CRYPT'), caractérisé en ce que lesdites informations de modification consistent en au moins un identificateur de clé (KeyID [SGN], KeyID [CRYPT]), servant respectivement à sélectionner lesdites clés courantes d'identification (K'" K',) dans des jeux prédéterminés (26,86) de clés disponibles d'identification (K'1... K'n ; K'i i... K'njn), ledit message (MSG) étant préférentiellement obtenu au moyen d'un dispositif de sécurisation (3) de messages conforme à l'une quelconque des revendications 1 à 11 et étant préférentiellement destiné à un dispositif d'identification (4) de messages conforme à la revendication 13. 17. Procédé de sécurisation de messages (MSG) destinés à être envoyés sur un réseau, vers au moins un récepteur (2) comprenant des moyens de commande d'identification (21) par une clé courante d'identification (K',, K', j) modifiable, ledit procédé de sécurisation comprenant : - une étape de changement d'une clé courante de chiffrement (KI1 K,) modifiable permettant de chiffrer au moins une partie de chacun desdits messages (MSG), - une étape d'inscription dans ledit message (MSG) d'informations de modification (KeyID) de la clé courante d'identification (K',, K', j) dans ledit récepteur (2), lesdites informations de modification (KeyID) servant audit récepteur (2) à modifier la clé courante d'identification (K',, K',) de manière à ce que ladite clé courante d'identification (K',, K', ;) corresponde à la clé courante de chiffrement (K,, K, j), - et une étape de chiffrement de ladite partie dudit message (MSG) au moyen de ladite clé courante de chiffrement (K,, K, j), caractérisé en ce que : - lors du changement de la clé courante de chiffrement (K,, K, j), on sélectionne ladite clé (Ki, Ki,j) dans au moins un jeu prédéterminé (16,19, 76) de clés disponibles de chiffrement (K1... Kn, K, i... Kn, n), - et lesdites informations de modification consistent en un identificateur de clé (KeyID), servant au récepteur (2) à sélectionner la clé courante d'identification (K',, K',,,) dans un jeu prédéterminé (26,86) de clés disponibles d'identification (K'1... K'n ; K'i... K') correspondant audit jeu prédéterminé (16,76) de clés disponibles de chiffrement (K1... Kn ; K1,1...Kn,ln), ledit procédé de sécurisation de messages (MSG) étant préférentiellement mis en oeuvre au moyen d'un dispositif de sécurisation (3) de messages (MSG) conforme à l'une quelconque des revendications 1 à 11. 18. Procédé d'identification de messages (MSG) reçus via un réseau, chacun desdits messages (MSG) incluant une partie chiffrée (SGN, CRYPT) au moyen d'une clé courante de chiffrement (K,, Ki,j) modifiable, ledit procédé d'identification comprenant : - une étape d'extraction dans ledit message (MSG) d'informations de modification (KeylD) d'une clé courante d'identification (K',, K', j) modifiable permettant d'identifier ladite partie chiffrée (SGN, CRYPT), lesdites informations de modification servant à modifier la clé courante d'identification (K',, K', ) de manière à ce que ladite clé courante d'identification (K',, K', j) corresponde à ladite clé courante de chiffrement (K,, Kl,), - et une étape d'identification de ladite partie chiffrée (SGN, CRYPT') au moyen de ladite clé courante d'identification (K',, k'i,j), caractérisé en ce que lesdites informations de modification consistent en un identificateur de clé (KeyID), au moyen duquel on sélectionne la clé courante d'identification (K',, K',,) dans un jeu prédéterminé (26,86) de clés disponibles d'identification (K'1... K'n ; K'1, 1... K'n"n), ledit procédé d'identification de messages (MSG) étant préférentiellement mis en oeuvre au moyen d'un dispositif d'identification (4) de messages (MSG) conforme à la revendication 13.