FR2825209A1 - Dispositifs et procede de securisation et d'identification de messages - Google Patents

Dispositifs et procede de securisation et d'identification de messages Download PDF

Info

Publication number
FR2825209A1
FR2825209A1 FR0106769A FR0106769A FR2825209A1 FR 2825209 A1 FR2825209 A1 FR 2825209A1 FR 0106769 A FR0106769 A FR 0106769A FR 0106769 A FR0106769 A FR 0106769A FR 2825209 A1 FR2825209 A1 FR 2825209A1
Authority
FR
France
Prior art keywords
sep
key
identification
msg
message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
FR0106769A
Other languages
English (en)
Inventor
Laurent Lesenne
Frederic Pasquier
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Thomson Licensing SAS
Original Assignee
Thomson Licensing SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Thomson Licensing SAS filed Critical Thomson Licensing SAS
Priority to FR0106769A priority Critical patent/FR2825209A1/fr
Priority to MXPA03010564A priority patent/MXPA03010564A/es
Priority to KR1020037014962A priority patent/KR100875289B1/ko
Priority to DE60203509T priority patent/DE60203509T2/de
Priority to ES02735376T priority patent/ES2240751T3/es
Priority to CNB028102487A priority patent/CN1315281C/zh
Priority to AU2002310832A priority patent/AU2002310832A1/en
Priority to JP2002592550A priority patent/JP2004527188A/ja
Priority to EP02735376A priority patent/EP1402679B1/fr
Priority to US10/478,447 priority patent/US20040162980A1/en
Priority to PCT/EP2002/005610 priority patent/WO2002096016A2/fr
Priority to US10/514,796 priority patent/US7627762B2/en
Publication of FR2825209A1 publication Critical patent/FR2825209A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/60—Digital content management, e.g. content distribution

Abstract

La présente invention concerne un dispositif (3) et un procédé de sécurisation de messages (MSG), envoyés vers un récepteur (2) comprenant des moyens de commande d'identification (21) par une clé courante d'identification (K'i ) modifiable. Elle concerne aussi un dispositif (4) et un procédé d'identification de messages correspondants. Le dispositif de sécurisation comprend une unité de commande de chiffrement (11) d'au moins une partie de chacun de ces messages au moyen d'une clé courante de chiffrement (K i ) modifiable. Il comprend aussi une unité de changement (12) de la clé courante de chiffrement, sélectionnant cette clé dans un jeu prédéterminé (16) de clés disponibles de chiffrement (K1 ... Kn ), ainsi qu'une unité d'inscription (13) dans ce message d'un identificateur de clé (KeylD). L'identificateur de clé sert au récepteur S sélectionner la clé courante d'identification dans un jeu prédéterminé (26) de clés disponibles d'identification (K'1 ... K'n ), préférentiellement de clés de déchiffrement, de manière à ce que les clés courantes de chiffrement et d'identification se correspondent. Applications à l'authentification et au cryptage de messages.

Description

<Desc/Clms Page number 1>
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.
<Desc/Clms Page number 2>
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.
<Desc/Clms Page number 3>
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.
<Desc/Clms Page number 4>
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
<Desc/Clms Page number 5>
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 :
<Desc/Clms Page number 6>
- 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-
<Desc/Clms Page number 7>
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
<Desc/Clms Page number 8>
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.
<Desc/Clms Page number 9>
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
<Desc/Clms Page number 10>
( 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.
<Desc/Clms Page number 11>
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.
<Desc/Clms Page number 12>
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
<Desc/Clms Page number 13>
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
<Desc/Clms Page number 14>
courantes d'identification dans des jeux prédéterminés de clés disponibles d'identification.
Figure img00140001
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.
<Desc/Clms Page number 15>
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 :
<Desc/Clms Page number 16>
- 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 ;
<Desc/Clms Page number 17>
- 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
<Desc/Clms Page number 18>
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
<Desc/Clms Page number 19>
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 ;
<Desc/Clms Page number 20>
- 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,
<Desc/Clms Page number 21>
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 ;
<Desc/Clms Page number 22>
- 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
<Desc/Clms Page number 23>
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
<Desc/Clms Page number 24>
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
<Desc/Clms Page number 25>
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).
<Desc/Clms Page number 26>
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
<Desc/Clms Page number 27>
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 ;
<Desc/Clms Page number 28>
- 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,
<Desc/Clms Page number 29>
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 :
Figure img00290001
<tb>
<tb> 00000000 <SEP> [2001 <SEP> 0000 <SEP> 53AA <SEP> OB8D <SEP> 2700 <SEP> 0000] <SEP> 763D <SEP> 300A... <SEP> S...'... <SEP> v=O.
<tb>
00000010 <SEP> 6F3D <SEP> 2D20 <SEP> 3935 <SEP> 3530 <SEP> 3035 <SEP> 3931 <SEP> 3320 <SEP> 3935 <SEP> o=-955005913 <SEP> 95
<tb> 00000020 <SEP> 3530 <SEP> 3035 <SEP> 3931 <SEP> 3320 <SEP> 494E <SEP> 2049 <SEP> 5034 <SEP> 2031 <SEP> 5005913 <SEP> IN <SEP> IP4 <SEP> 1
<tb> 00000030 <SEP> 3732 <SEP> 2E33 <SEP> 302E <SEP> 3930 <SEP> 2E31 <SEP> 3630 <SEP> OA73 <SEP> 3D63 <SEP> 72.30. <SEP> 90.160. <SEP> s=c
<tb> 00000040 <SEP> 6D6F <SEP> 6E63 <SEP> 686F <SEP> 6978 <SEP> OA65 <SEP> 3D64 <SEP> 7570 <SEP> 6F6E <SEP> monchoix. <SEP> e=dupon
<tb> 00000050 <SEP> 7440 <SEP> 7468 <SEP> 6D75 <SEP> 6C74 <SEP> 692E <SEP> 636F <SEP> 6DOA <SEP> 703D <SEP> t&commat;thmulti. <SEP> com. <SEP> p=
<tb> 00000060 <SEP> 2B31 <SEP> 2D36 <SEP> 3537 <SEP> 2D34 <SEP> 3733 <SEP> 2D34 <SEP> 3833 <SEP> 300A <SEP> +1-657-473-4830.
<tb>
00000070 <SEP> 613D <SEP> 6C61 <SEP> 6E67 <SEP> 3A65 <SEP> 6EOA <SEP> 613D <SEP> 7476 <SEP> 652D <SEP> a=lang <SEP> : <SEP> en. <SEP> a=tve-
<tb> 00000080 <SEP> 656E <SEP> 6473 <SEP> 3A33 <SEP> 3030 <SEP> OA61 <SEP> 3D74 <SEP> 7665 <SEP> 2D74 <SEP> ends <SEP> : <SEP> 300. <SEP> a=tve-t
<tb> 00000090 <SEP> 7970 <SEP> 653A <SEP> 7072 <SEP> 696D <SEP> 6172 <SEP> 790A <SEP> 613D <SEP> 7476 <SEP> ype <SEP> : <SEP> primary. <SEP> a=tv
<tb> OOOOOOAO <SEP> 652D <SEP> 6964 <SEP> 3A64 <SEP> 3631 <SEP> 3633 <SEP> 6164 <SEP> 612D <SEP> 3766 <SEP> e-id <SEP> : <SEP> d6163ada-7f
<tb> OOOOOOBO <SEP> 6164 <SEP> 2D33 <SEP> 6235 <SEP> 342D <SEP> 6262 <SEP> 3839 <SEP> 2D66 <SEP> 3166 <SEP> ad-3b54-bb89-flf
<tb> OOOOOOCO <SEP> 6161 <SEP> 3430 <SEP> 3736 <SEP> 6637 <SEP> 620A <SEP> 613D <SEP> 7476 <SEP> 652D <SEP> aa4076f7b. <SEP> a=tveOOOOOODO <SEP> 7072 <SEP> 6F66 <SEP> 696C <SEP> 653A <SEP> 310A <SEP> 743D <SEP> 3020 <SEP> 300A <SEP> profile <SEP> : <SEP> l. <SEP> t=0 <SEP> O.
<tb>
OOOOOOEO <SEP> 6D3D <SEP> 6461 <SEP> 7461 <SEP> 2032 <SEP> 3238 <SEP> 3530 <SEP> 2074 <SEP> 7665 <SEP> m=data <SEP> 22850 <SEP> tve
<tb> OOOOOOFO <SEP> 2D74 <SEP> 7269 <SEP> 6767 <SEP> 6572 <SEP> OA63 <SEP> 3D49 <SEP> 4E20 <SEP> 4950-trigger. <SEP> c=IN <SEP> IP
<tb> 00000100 <SEP> 3420 <SEP> 3232 <SEP> 372E <SEP> 3337 <SEP> 2E33 <SEP> 322E <SEP> 3433 <SEP> OA6D <SEP> 4 <SEP> 227.37. <SEP> 32.43. <SEP> m
<tb> 00000110 <SEP> 3D64 <SEP> 6174 <SEP> 6120 <SEP> 3232 <SEP> 3835 <SEP> 3120 <SEP> 7476 <SEP> 652D <SEP> =data <SEP> 22851 <SEP> tve-
<tb> 00000120 <SEP> 6669 <SEP> 6C65 <SEP> OA63 <SEP> 3D49 <SEP> 4E20 <SEP> 4950 <SEP> 3420 <SEP> 3232 <SEP> file. <SEP> c=IN <SEP> IP4 <SEP> 22
<tb> 00000130 <SEP> 342E <SEP> 3337 <SEP> 2E33 <SEP> 322E <SEP> 3434 <SEP> OA <SEP> 4.37. <SEP> 32.44.
<tb>
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 :
Figure img00290002
<tb>
<tb> 00000000 <SEP> [2021 <SEP> 0000 <SEP> 53AA <SEP> OB8D <SEP> 2027 <SEP> 0007 <SEP> 6797 <SEP> BE9E <SEP> !.. <SEP> S...'.. <SEP> g...
<tb>
00000010 <SEP> 7169 <SEP> 8F8D <SEP> FDF1 <SEP> B330 <SEP> 38FF <SEP> 957C <SEP> DOA2 <SEP> B515 <SEP> qi..... <SEP> 08.. <SEP> 1....
<tb> 00000020 <SEP> lF98 <SEP> DABC <SEP> CB04 <SEP> 9F03 <SEP> OEB8 <SEP> 3D27 <SEP> E5AA <SEP> 047A.......... <SEP> ='... <SEP> z
<tb> 00000030 <SEP> 35AF <SEP> F2FF <SEP> DC65 <SEP> 4F04 <SEP> 28E3 <SEP> CA3F <SEP> 948D <SEP> 1D8A <SEP> 5.... <SEP> eO. <SEP> (.. <SEP> ?...
<tb> 00000040 <SEP> 4540 <SEP> D763 <SEP> DB68 <SEP> 3ADD <SEP> CAEF <SEP> 5EB1 <SEP> 4116 <SEP> F939 <SEP> E&commat;. <SEP> c. <SEP> h <SEP> :... <SEP> ^. <SEP> A.. <SEP> 9
<tb> 00000050 <SEP> 7C29 <SEP> 862F <SEP> E7B8 <SEP> 75C1 <SEP> 081C <SEP> 3830 <SEP> 5A55 <SEP> AEC2 <SEP> 1)./.. <SEP> u... <SEP> 80ZU..
<tb>
00000060 <SEP> 1031 <SEP> 62CO <SEP> E52D <SEP> AC19 <SEP> 1CCF <SEP> 7471 <SEP> D28E <SEP> 8997. <SEP> lob..-.... <SEP> tq....
<tb>
00000070 <SEP> 7F46 <SEP> 9473 <SEP> 4F2A <SEP> B5EF <SEP> 8047 <SEP> 2DE9 <SEP> 87EF <SEP> A49E. <SEP> F. <SEP> sO*... <SEP> G......
<tb>
00000080 <SEP> 4E90 <SEP> 5DB7 <SEP> 0981 <SEP> COOl <SEP> DB17 <SEP> F07F] <SEP> 763D <SEP> 300A <SEP> N. <SEP> ]......... <SEP> v=O.
<tb>
00000090 <SEP> 6F3D <SEP> 2D20 <SEP> 3935 <SEP> 3530 <SEP> 3035 <SEP> 3931 <SEP> 3320 <SEP> 3935 <SEP> o=-955005913 <SEP> 95
<tb> OOOOOOAO <SEP> 3530 <SEP> 3035 <SEP> 3931 <SEP> 3320 <SEP> 494E <SEP> 2049 <SEP> 5034 <SEP> 2031 <SEP> 5005913 <SEP> IN <SEP> IP4 <SEP> 1
<tb> OOOOOOBO <SEP> 3732 <SEP> 2E33 <SEP> 302E <SEP> 3930 <SEP> 2E31 <SEP> 3630 <SEP> OA73 <SEP> 3D63 <SEP> 72.30. <SEP> 90.160. <SEP> s=c
<tb> OOOOOOCO <SEP> 6D6F <SEP> 6E63 <SEP> 686F <SEP> 6978 <SEP> OA65 <SEP> 3D64 <SEP> 7570 <SEP> 6F6E <SEP> monchoix. <SEP> e=dupon
<tb> OOOOOODO <SEP> 7440 <SEP> 7468 <SEP> 6D75 <SEP> 6C74 <SEP> 692E <SEP> 636F <SEP> 6DOA <SEP> 703D <SEP> t&commat;thmulti. <SEP> com. <SEP> p=
<tb> OOOOOOEO <SEP> 2B31 <SEP> 2D36 <SEP> 3537 <SEP> 2D34 <SEP> 3733 <SEP> 2D34 <SEP> 3833 <SEP> 300A <SEP> +1-657-473-4830.
<tb>
OOOOOOFO <SEP> 613D <SEP> 6C61 <SEP> 6E67 <SEP> 3A65 <SEP> 6EOA <SEP> 613D <SEP> 7476 <SEP> 652D <SEP> a=lang <SEP> : <SEP> en. <SEP> a=tve-
<tb> 00000100 <SEP> 656E <SEP> 6473 <SEP> 3A33 <SEP> 3030 <SEP> OA61 <SEP> 3D74 <SEP> 7665 <SEP> 2D74 <SEP> ends <SEP> : <SEP> 300. <SEP> a=tve-t
<tb> 00000110 <SEP> 7970 <SEP> 653A <SEP> 7072 <SEP> 696D <SEP> 6172 <SEP> 790A <SEP> 613D <SEP> 7476 <SEP> ype <SEP> : <SEP> primary. <SEP> a=tv
<tb> 00000120 <SEP> 652D <SEP> 6964 <SEP> 3A64 <SEP> 3631 <SEP> 3633 <SEP> 6164 <SEP> 612D <SEP> 3766 <SEP> e-id <SEP> : <SEP> d6163ada-7f
<tb> 00000130 <SEP> 6164 <SEP> 2D33 <SEP> 6235 <SEP> 342D <SEP> 6262 <SEP> 3839 <SEP> 2D66 <SEP> 3166 <SEP> ad-3b54-bb89-flf
<tb>
<Desc/Clms Page number 30>
Figure img00300001
<tb>
<tb> 00000140 <SEP> 6161 <SEP> 3430 <SEP> 3736 <SEP> 6637 <SEP> 620A <SEP> 613D <SEP> 7476 <SEP> 652D <SEP> aa4076f7b. <SEP> a=tve-
<tb> 00000150 <SEP> 7072 <SEP> 6F66 <SEP> 696C <SEP> 653A <SEP> 310A <SEP> 743D <SEP> 3020 <SEP> 300A <SEP> profile <SEP> : <SEP> 1. <SEP> t=0 <SEP> O.
<tb> 00000160 <SEP> 6D3D <SEP> 6461 <SEP> 7461 <SEP> 2032 <SEP> 3238 <SEP> 3530 <SEP> 2074 <SEP> 7665 <SEP> m=data <SEP> 22850 <SEP> tve
<tb> 00000170 <SEP> 2D74 <SEP> 7269 <SEP> 6767 <SEP> 6572 <SEP> OA63 <SEP> 3D49 <SEP> 4E20 <SEP> 4950-trigger. <SEP> c=IN <SEP> IP
<tb> 00000180 <SEP> 3420 <SEP> 3232 <SEP> 372E <SEP> 3337 <SEP> 2E33 <SEP> 322E <SEP> 3433 <SEP> OA6D <SEP> 4 <SEP> 227.37. <SEP> 32.43. <SEP> m
<tb> 00000190 <SEP> 3D64 <SEP> 6174 <SEP> 6120 <SEP> 3232 <SEP> 3835 <SEP> 3120 <SEP> 7476 <SEP> 652D <SEP> =data <SEP> 22851 <SEP> tve-
<tb> 000001AO <SEP> 6669 <SEP> 6C65 <SEP> OA63 <SEP> 3D49 <SEP> 4E20 <SEP> 4950 <SEP> 3420 <SEP> 3232 <SEP> file. <SEP> c=IN <SEP> IP4 <SEP> 22
<tb> 000001BO <SEP> 342E <SEP> 3337 <SEP> 2E33 <SEP> 322E <SEP> 3434 <SEP> OA <SEP> 4.37. <SEP> 32.44.
<tb>
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
<Desc/Clms Page number 31>
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-
Figure img00310001

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.
<Desc/Clms Page number 32>
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,
<Desc/Clms Page number 33>
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
<Desc/Clms Page number 34>
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 ;
<Desc/Clms Page number 35>
- 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
<Desc/Clms Page number 36>
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.

Claims (18)

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).
<Desc/Clms Page number 38>
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.
<Desc/Clms Page number 39>
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
<Desc/Clms Page number 40>
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
<Desc/Clms Page number 41>
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
<Desc/Clms Page number 42>
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,
<Desc/Clms Page number 43>
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.
Figure img00430001
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,,
FR0106769A 2001-05-23 2001-05-23 Dispositifs et procede de securisation et d'identification de messages Pending FR2825209A1 (fr)

Priority Applications (12)

Application Number Priority Date Filing Date Title
FR0106769A FR2825209A1 (fr) 2001-05-23 2001-05-23 Dispositifs et procede de securisation et d'identification de messages
MXPA03010564A MXPA03010564A (es) 2001-05-23 2002-05-22 Dispositivo de seguridad y procesos para proteger e identificar mensajes.
KR1020037014962A KR100875289B1 (ko) 2001-05-23 2002-05-22 메시지 보호 및 식별을 위한 보안화 디바이스 및 프로세스와, 메시지 송신기 및 수신기와, 그러한 보안화 디바이스의 여러 구성요소를 구현하기 위한 기능을 포함하는 컴퓨터 프로그램 제품을 담고 있는 매체
DE60203509T DE60203509T2 (de) 2001-05-23 2002-05-22 Sicherheitsbezogene vorrichtungen und verfahren zum schutz und zur identifikation von nachrichten
ES02735376T ES2240751T3 (es) 2001-05-23 2002-05-22 Dispositivos y metodos de seguridad para proteccion e identificacion de mensajes.
CNB028102487A CN1315281C (zh) 2001-05-23 2002-05-22 保护和识别消息的保密设备和方法
AU2002310832A AU2002310832A1 (en) 2001-05-23 2002-05-22 Security devices and processes for protecting and identifying messages
JP2002592550A JP2004527188A (ja) 2001-05-23 2002-05-22 メッセージの保護および識別のためのセキュリティ装置およびセキュリティ方法
EP02735376A EP1402679B1 (fr) 2001-05-23 2002-05-22 Dispositifs et procedes de securite pour la protection et l'identification de messages
US10/478,447 US20040162980A1 (en) 2001-05-23 2002-05-22 Security devices and processes for protecting and identifying messages
PCT/EP2002/005610 WO2002096016A2 (fr) 2001-05-23 2002-05-22 Dispositifs et procedes de securite pour la protection et l'identification de messages
US10/514,796 US7627762B2 (en) 2001-05-23 2002-11-08 Signing and authentication devices and processes and corresponding products, notably for DVB/MPEG MHP digital streams

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0106769A FR2825209A1 (fr) 2001-05-23 2001-05-23 Dispositifs et procede de securisation et d'identification de messages

Publications (1)

Publication Number Publication Date
FR2825209A1 true FR2825209A1 (fr) 2002-11-29

Family

ID=8863573

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0106769A Pending FR2825209A1 (fr) 2001-05-23 2001-05-23 Dispositifs et procede de securisation et d'identification de messages

Country Status (11)

Country Link
US (1) US20040162980A1 (fr)
EP (1) EP1402679B1 (fr)
JP (1) JP2004527188A (fr)
KR (1) KR100875289B1 (fr)
CN (1) CN1315281C (fr)
AU (1) AU2002310832A1 (fr)
DE (1) DE60203509T2 (fr)
ES (1) ES2240751T3 (fr)
FR (1) FR2825209A1 (fr)
MX (1) MXPA03010564A (fr)
WO (1) WO2002096016A2 (fr)

Families Citing this family (52)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7627762B2 (en) * 2001-05-23 2009-12-01 Thomson Licensing Signing and authentication devices and processes and corresponding products, notably for DVB/MPEG MHP digital streams
US20040163091A1 (en) * 2003-02-19 2004-08-19 Brill Gregory M. Attributes bridging solution and method of using the same
JP4717329B2 (ja) * 2003-03-14 2011-07-06 キヤノン株式会社 デジタル署名生成装置
US7911946B2 (en) * 2003-11-17 2011-03-22 General Instrument Corporation Method and apparatuses for using packet data to manage a data stream in a broadband communications system
JP4749680B2 (ja) * 2004-05-10 2011-08-17 株式会社ソニー・コンピュータエンタテインメント データ構造、データ処理装置、データ処理方法、認証装置、認証方法、コンピュータプログラム、及び記録媒体
US7437558B2 (en) * 2004-06-01 2008-10-14 Cisco Technology, Inc. Method and system for verifying identification of an electronic mail message
US8090940B1 (en) * 2004-06-01 2012-01-03 Cisco Technology, Inc. Method and system for verifying identification of an electronic message
CA2493442C (fr) 2005-01-20 2014-12-16 Certicom Corp. Methode et systeme pour gerer et filtrer des messages electroniques au moyen de techniques cryptographiques
US8165302B2 (en) * 2005-06-07 2012-04-24 Sony Corporation Key table and authorization table management
US8050406B2 (en) * 2005-06-07 2011-11-01 Sony Corporation Key table and authorization table management
JP4595691B2 (ja) * 2005-06-14 2010-12-08 トヨタ自動車株式会社 電子キーシステム
US7743409B2 (en) 2005-07-08 2010-06-22 Sandisk Corporation Methods used in a mass storage device with automated credentials loading
US7434253B2 (en) 2005-07-14 2008-10-07 Microsoft Corporation User mapping information extension for protocols
JP4596256B2 (ja) * 2005-08-02 2010-12-08 ソニー株式会社 送受信システムおよび方法、送信装置および方法、受信装置および方法、並びにプログラム
DE102005046462B4 (de) * 2005-09-21 2008-09-18 Engel Solutions Ag Netzwerkkomponente für ein Kommunikationsnetzwerk, Kommunikationsnetzwerk und Verfahren zur Bereitstellung einer Datenverbindung
CN1808975B (zh) * 2006-01-26 2010-09-08 黄涛 一种网络帐号防盗系统及其方法
CN101490687B (zh) * 2006-07-07 2012-04-18 桑迪士克股份有限公司 使用身份对象的控制系统及方法
EP2038803A2 (fr) * 2006-07-07 2009-03-25 Sandisk Corporation Système et procédé de commande de contenu faisant appel à des chaînes de certificats
US20090323968A1 (en) * 2008-06-27 2009-12-31 Shih-Ta Hsu Descrambling apparatus and descrambling method in a tv system
KR101508794B1 (ko) * 2008-07-09 2015-04-06 삼성전자주식회사 Ｎｄｅｆ 메시지에서 선택적으로 레코드들을 보안하기 위한 방법
US9104618B2 (en) 2008-12-18 2015-08-11 Sandisk Technologies Inc. Managing access to an address range in a storage device
JP5458657B2 (ja) * 2009-05-01 2014-04-02 ソニー株式会社 情報処理装置、鍵更新方法、及びプログラム
ES2379703T3 (es) 2010-03-26 2012-04-30 The Procter And Gamble Company Método de depilación y kit para depilación
US9083534B2 (en) * 2011-01-07 2015-07-14 Mastercard International Incorporated Method and system for propagating a client identity
WO2012103720A1 (fr) * 2011-06-29 2012-08-09 华为技术有限公司 Procédé et appareil de maintien de paramètres de cryptage/décryptage de couche de commande de liaison logique (llc)
EP2559420B1 (fr) 2011-08-17 2014-10-15 The Procter and Gamble Company Article d'épilation efficace
BR112014014585A8 (pt) 2011-12-21 2017-07-04 Sony Corp aparelho e método de processamento de informação, aparelho de servidor, método de processamento de servidor, e, programa
US9197700B2 (en) 2013-01-18 2015-11-24 Apple Inc. Keychain syncing
KR102457809B1 (ko) * 2014-09-24 2022-10-24 삼성전자주식회사 데이터 통신 보안을 위한 방법, 장치 및 시스템
US10104522B2 (en) * 2015-07-02 2018-10-16 Gn Hearing A/S Hearing device and method of hearing device communication
US9877123B2 (en) * 2015-07-02 2018-01-23 Gn Hearing A/S Method of manufacturing a hearing device and hearing device with certificate
DK201570434A1 (en) * 2015-07-02 2017-01-30 Gn Hearing As Hearing device and method of hearing device communication
US10318720B2 (en) 2015-07-02 2019-06-11 Gn Hearing A/S Hearing device with communication logging and related method
DK201570433A1 (en) 2015-07-02 2017-01-30 Gn Hearing As Hearing device with model control and associated methods
US9887848B2 (en) 2015-07-02 2018-02-06 Gn Hearing A/S Client device with certificate and related method
DK201570436A1 (en) * 2015-07-02 2017-01-23 Gn Hearing As Hearing device and method of updating a hearing device
US10158953B2 (en) 2015-07-02 2018-12-18 Gn Hearing A/S Hearing device and method of updating a hearing device
US10158955B2 (en) 2015-07-02 2018-12-18 Gn Hearing A/S Rights management in a hearing device
GB2547676B (en) * 2016-02-25 2018-03-21 Arm Ip Ltd Methods and resources for generating secure communications
US10498712B2 (en) 2016-11-10 2019-12-03 Ernest Brickell Balancing public and personal security needs
US10855465B2 (en) 2016-11-10 2020-12-01 Ernest Brickell Audited use of a cryptographic key
US11398906B2 (en) 2016-11-10 2022-07-26 Brickell Cryptology Llc Confirming receipt of audit records for audited use of a cryptographic key
US11405201B2 (en) 2016-11-10 2022-08-02 Brickell Cryptology Llc Secure transfer of protected application storage keys with change of trusted computing base
EP3937513A1 (fr) 2016-12-08 2022-01-12 GN Hearing A/S Système auditif, dispositifs et procédé de sécurisation de communication pour une application d'utilisateur
DK3334190T3 (da) * 2016-12-08 2021-11-15 Gn Hearing As Høreindretninger, brugertilbehørsindretninger og fremgangsmåde til opdatering af en høreindretningskonfiguration
US10348706B2 (en) * 2017-05-04 2019-07-09 Ernest Brickell Assuring external accessibility for devices on a network
AU2017412654B2 (en) * 2017-05-04 2020-07-09 Brickell Cryptology Llc Assuring external accessibility for devices on a network
US10652245B2 (en) 2017-05-04 2020-05-12 Ernest Brickell External accessibility for network devices
US11101979B2 (en) 2019-05-30 2021-08-24 Kira Inc. Method and system for creating word-level differential privacy using feature hashing techniques
CN112673607B (zh) 2019-07-03 2023-04-04 谷歌有限责任公司 匿名设备认证
CN113726830B (zh) * 2020-05-25 2023-09-12 网联清算有限公司 一种报文标识生成方法及装置
CN114513781A (zh) * 2022-02-11 2022-05-17 青岛民航空管实业发展有限公司 一种空管智慧台站的身份认证方法及数据加解密方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5222137A (en) * 1991-04-03 1993-06-22 Motorola, Inc. Dynamic encryption key selection for encrypted radio transmissions
US5301233A (en) * 1991-08-19 1994-04-05 France Telecom Etablissement Autonome De Droit Public Process for the transmission and reception of personalized programs
EP1075108A1 (fr) * 1999-07-23 2001-02-07 BRITISH TELECOMMUNICATIONS public limited company Distribution cryptographique de données

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998043431A1 (fr) * 1997-03-21 1998-10-01 Canal+ Societe Anonyme Procede pour telecharger des donnees vers un recepteur/decodeur mpeg et systeme de transmission mpeg pour appliquer ce procede
US6370249B1 (en) * 1997-07-25 2002-04-09 Entrust Technologies, Ltd. Method and apparatus for public key management
US6978017B2 (en) * 1997-10-14 2005-12-20 Entrust Limited Method and system for providing updated encryption key pairs and digital signature key pairs in a public key system
US6557172B1 (en) * 1999-05-28 2003-04-29 Intel Corporation Communicating enhancement data in layers
US7296091B1 (en) * 1999-06-18 2007-11-13 The Trustees Of Columbia University In The City Of New York System and method for receiving over a network a broadcast from a broadcast source
US6363480B1 (en) * 1999-09-14 2002-03-26 Sun Microsystems, Inc. Ephemeral decryptability
FI20000624A0 (fi) * 2000-03-17 2000-03-17 Prikatti Ab Oy Parannettu menetelmä, järjestelmä ja liiketoimintamalli sähköisen vedonlyönnin järjestämiseksi

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5222137A (en) * 1991-04-03 1993-06-22 Motorola, Inc. Dynamic encryption key selection for encrypted radio transmissions
US5301233A (en) * 1991-08-19 1994-04-05 France Telecom Etablissement Autonome De Droit Public Process for the transmission and reception of personalized programs
EP1075108A1 (fr) * 1999-07-23 2001-02-07 BRITISH TELECOMMUNICATIONS public limited company Distribution cryptographique de données

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"ADVANCED TELEVISION ENHANCEMENT FORUM SPECIFICATION (ATVEF)", ADVANCED TELEVISION ENHANCEMENT FORUM SPECIFICATION (ATVEF), XX, XX, February 1999 (1999-02-01), pages 1 - 37, XP002939077 *

Also Published As

Publication number Publication date
KR20040004628A (ko) 2004-01-13
MXPA03010564A (es) 2004-03-02
JP2004527188A (ja) 2004-09-02
CN1526217A (zh) 2004-09-01
US20040162980A1 (en) 2004-08-19
WO2002096016A2 (fr) 2002-11-28
EP1402679A2 (fr) 2004-03-31
DE60203509D1 (de) 2005-05-04
AU2002310832A1 (en) 2002-12-03
EP1402679B1 (fr) 2005-03-30
ES2240751T3 (es) 2005-10-16
WO2002096016A3 (fr) 2003-08-28
DE60203509T2 (de) 2006-02-23
CN1315281C (zh) 2007-05-09
KR100875289B1 (ko) 2008-12-23

Similar Documents

Publication Publication Date Title
FR2825209A1 (fr) Dispositifs et procede de securisation et d&#39;identification de messages
FR2825222A1 (fr) Dispositif et procedes de transmission et de mise en oeuvre d&#39;instructions de controle pour acces a des fonctionnalites d&#39;execution
EP1351440B1 (fr) Dispositif pour la multidiffusion sécurisée
EP0528730B1 (fr) Procédés d&#39;émission et de réception de programmes personnalisés
EP0554182B1 (fr) Procédé, appareil et dispositif de chiffrement de messages transmis entre réseaux interconnectés
US7441271B2 (en) Method and apparatus for intercepting events in a communication system
US6009173A (en) Encryption and decryption method and apparatus
US7325127B2 (en) Security server system
US20100223470A1 (en) Secure instant messaging system
FR2841070A1 (fr) Procede et dispositif d&#39;interface pour echanger de maniere protegee des donnees de contenu en ligne
EP2659613A1 (fr) Procede de transmission et de reception d&#39;un contenu multimedia
EP1201057B1 (fr) Methode et dispositif pour garantir l&#39;integrite et l&#39;authenticite d&#39;un ensemble de donnees
FR2876858A1 (fr) Dispositif et procede de reception d&#39;informations embrouillees, et unite de desembrouillage, systeme de transmission d&#39;informations et emetteur adaptes pour ce dispositif
EP0748073A1 (fr) Protocole d&#39;émission de messages de contrÔle d&#39;accès à des applications RDS, dispositifs d&#39;émission et de réception correspondants.
CN112398643B (zh) 一种通信数权保护方法及系统
WO2010133459A1 (fr) Procede de chiffrement de parties particulieres d&#39; un document pour les utilisateurs privileges
CN115348233A (zh) 一种标准邮件系统透明加密方法、介质及计算机设备
EP2265013A1 (fr) Transmission de contenu vers un équipement client comportant au moins un module de décodage et un module de sécurité
FR2814879A1 (fr) Procede et dispositif de certification