FR2960734A1

FR2960734A1 - Procede et dispositifs de communications securisees dans un reseau de telecommunications

Info

Publication number: FR2960734A1
Application number: FR1054220A
Authority: FR
Inventors: Patrick Battistello
Original assignee: France Telecom SA
Current assignee: Orange SA
Priority date: 2010-05-31
Filing date: 2010-05-31
Publication date: 2011-12-02
Also published as: US20130086649A1; US8738900B2; EP2577901A1; CN103039033A; WO2011151573A1

Abstract

L'invention concerne un procédé de communications sécurisées dans un réseau de télécommunications, ledit réseau comprenant un groupe de serveurs S (où i = 1,2,...,p, et p est un entier strictement positif), dits Serveurs d'Autorisation. Ce procédé comprend, pour une transaction entre une entité A et une entité B dudit réseau, les étapes suivantes : a) l'entité A envoie à l'un des Serveurs d'Autorisation S une requête d'autorisation dans laquelle l'entité A s'identifie et s'authentifie comme le détenteur d'un identifiant ID ; b) l'entité A déclare audit Serveur d'Autorisation S son intention de communiquer avec l'entité B, et le Serveur d'Autorisation détermine une clé secrète individuelle K qu'il partage avec cette entité B ; c) le Serveur d'Autorisation S engendre une clé de session K et envoie ladite clé de session K à l'entité A ; d) le Serveur d'Autorisation S engendre un identifiant de transaction IDTR ; e) le Serveur d'Autorisation S fait parvenir à l'entité B des éléments comprenant au moins ledit identifiant de transaction IDTR ; f) à l'aide de cet identifiant de transaction IDTR , l'entité B vérifie la validité de la transaction, et g) l'entité B engendre la clé de session K .

Description

PROCEDE ET DISPOSITIFS DE COMMUNICATIONS SECURISEES DANS UN RESEAU DE TELECOMMUNICATIONS

La présente invention concerne la sécurisation des communications dans un réseau de télécommunications.

Les réseaux de télécommunications, comme l'Internet, transmettent des données entre différentes entités réseau, telles qu'un serveur web ou un serveur de messagerie électronique, via une infrastructure commune. L'invention peut s'appliquer par exemple à l'accès sécurisé d'une entité réseau à une plateforme de service.

L'invention peut également s'appliquer, par exemple, à la transmission d'un « message original » d'une entité réseau à une ou plusieurs autre(s) entité(s) réseau ; par « message original », on entend ici un ensemble quelconque d'informations, par exemple un courrier électronique, ou une demande d'initiation d'appel VoIP (initiales des mots anglais « Voice over Internet Protocol » signifiant « Voix sur IP »), ou encore un « message instantané ». On dira de manière générale qu'un message original est envoyé par un « client expéditeur » rattaché à un domaine « expéditeur » et connecté à un domaine « émetteur », vers un « client destinataire » rattaché à un domaine « destinataire » et connecté à un domaine « récepteur » (dans le cadre de la présente invention, on dira qu'une entité est « rattachée » à un domaine réseau lorsque cette entité possède un lien de service et/ou logique et/ou administratif avec ce domaine ; dans le cas du courrier électronique, l'adresse logique correspond à l'adresse « email »). Le domaine émetteur peut ou non être distinct du domaine expéditeur, et le domaine récepteur peut ou non être distinct du domaine destinataire ; cette distinction entre domaines est utile, par exemple, lorsqu'un domaine émetteur relaie vers un client destinataire un message émis par un client expéditeur itinérant qui est connecté à ce domaine émetteur mais qui n'est pas rattaché au domaine émetteur. Comme il est bien connu, les réseaux de télécommunications subissent des attaques à destination de cibles professionnelles, administratives ou individuelles. Une attaque courante de nos jours consiste à envoyer vers le plus grand nombre de destinataires possible des messages indésirables qu'ils n'ont pas sollicités, tels que des « spam » pour des courriers électroniques ou des « spit » pour des appels téléphoniques sur Internet. Le qualificatif « indésirable » est pris au sens large et s'applique à la fois à l'identité de l'expéditeur du message, qui peut être authentique ou falsifiée, et au contenu du message. La possibilité d'attaques du type spam/spit repose notamment sur les facteurs suivants : - la faiblesse des protocoles utilisés sur Internet, tels que le protocole SMTP (« Simple Mail Transfer Protocol » en anglais) le plus utilisé pour le transfert de courrier électronique et qui n'incorpore notamment pas de fonctions d'authentification de l'émetteur d'un courrier ; - l'augmentation de la puissance des ordinateurs qui peuvent envoyer des messages indésirables en masse de façon automatique sur une période très courte ; et - l'augmentation du nombre de réseaux ayant accès à Internet et de la connectivité entre ces réseaux, ce qui présente un très grand nombre de cibles à des attaquants qui peuvent s'abriter derrière des réseaux relativement permissifs ou hors de portée légale ou administrative des réseaux cibles. De plus, il n'est pas aisé, pour un domaine émetteur du type « émetteur.fr », de déterminer si une adresse du type user@expéditeur.fr fournie par un client expéditeur itinérant connecté à ce domaine émetteur est valide, c'est-à-dire si l'adresse de ce client est effectivement attribuée dans le domaine « expéditeur.fr » et si ce client dispose des droits pour envoyer un message depuis cette adresse : en effet, le domaine émetteur ne gère pas les identités, c'est-à-dire les adresses logiques du type « expéditeur.fr ». Cette difficulté de contrôle est souvent utilisée par des attaquants pour émettre des messages sous une fausse identité depuis un domaine auquel les attaquants ont accès, ou bien via une machine corrompue située dans un domaine légitime. Par exemple, un domaine Internet « domaine.fr » créé par un attaquant peut tout-à-fait être utilisé pour émettre des appels VoIP avec une identité d'appelant +332abcdefgh@domaine.fr, alors qu'en fait le numéro d'abonné "+332abcdefgh" est attribué, disons, au domaine « orange.fr ». Face à ce genre d'attaque, le fait d'ajouter une signature numérique par le domaine appelant (cf. document RFC 4474 de l'IETF) est inefficace, car, si cela garantit au destinataire que l'appel provient bien de « domaine.fr », cela ne lui garantit pas que le numéro appelant est effectivement enregistré dans ce domaine. Une solution à cette difficulté de contrôle consiste à bloquer dans le domaine émetteur l'envoi de tout message dont l'adresse d'origine n'est pas rattachée au domaine émetteur, mais cette solution est trop limitative, notamment pour la mobilité des services de VoIP qui permettent à un terminal itinérant d'utiliser un relais tiers tel qu'un domaine émetteur pour établir un appel téléphonique. Cette situation pose le problème de trouver des moyens permettant à un domaine destinataire de s'assurer que des contrôles suffisants ont été réalisés au niveau du domaine émetteur du message.

Dans le cadre de la présente invention, on appellera « transaction » l'ensemble des échanges protocolaires permettant l'établissement d'un secret partagé, ou « clé primaire de session », entre deux entités réseau A et B pour la durée d'une session. La transaction correspond à la phase d'initialisation de la session, cette session pouvant durer beaucoup plus longtemps que la transaction. Dans certaines parties de la description, les termes transaction et session pourront être considérés comme équivalents. Dans un souci de simplification, la clé primaire de session sera également notée « clé de session » entre A et B , indépendamment des opérations de dérivation ou de diversification qui peuvent lui être appliquées. Cette clé de session peut par exemple servir à la dérivation d'autres clés secrètes pour mettre en place une connexion sécurisée (TLS, IPSec, ou autre) entre les entités A et B. Comme autre exemple, cette clé de session peut permettre de garantir la confidentialité ou l'intégrité d'un message original envoyé par l'entité A (client expéditeur) à l'entité B (client destinataire) ; à chaque nouveau message original envoyé depuis un client expéditeur vers un ou plusieurs client(s) destinataire(s) correspond une nouvelle transaction ; à l'inverse, la répétition d'une étape protocolaire, par exemple du fait d'un problème réseau, n'est pas considérée comme une nouvelle transaction.

Une entité réseau peut évidemment, en principe, authentifier une autre entité réseau au moyen d'une infrastructure à clé publique PKI (« Public Key Infrastructure » en anglais). Mais comme il est bien connu, les infrastructures PKI sont lourdes à mettre en place et à utiliser. En variante, certains procédés, tels que l'algorithme de Diffie- Hellman, prévoient la détermination commune d'une clé de session par deux entités préalablement à tout échange de messages originaux entre elles. Mais un tel algorithme ne donne, en lui-même, à une entité A aucune garantie sur l'identité d'une entité B avec laquelle elle établit ainsi une clé de session.

En variante, dans les réseaux comprenant un faible nombre d'usagers, tels que les réseaux de pairs, on peut prévoir une installation « manuelle » (par exemple par visite sur place) d'une clé secrète partagée pour chaque paire d'entités intéressées. Mais une telle installation ne convient pas aux réseaux comprenant un grand nombre d'usagers.

On connaît aussi un protocole de communciations sécurisées appelé « IPACF » (voir l'article « Using Identity-Based Privacy-Protected Access Control Filter (IPACF) to Against Denial of Service Attacks and Protect User Privacy », de C.-H. Wu et al., http://portal.acm.orô/citation.cfm?id=1404806, 2007). Ce protocole est destiné à une architecture comprenant un ensemble d'entités A pouvant toutes communiquer de façon sécurisée avec une entité unique B ; en pratique, les entités A sont des clients et l'entité unique B est un serveur ou une entité de contrôle d'accès. II existe un secret partagé distinct entre B et chacune des entités A. Le protocole IPACF comprend trois phases : une phase de configuration initiale permettant la mise en place de secrets partagés, une phase d'authentification lors de l'établissement d'une nouvelle session, et enfin la phase de communication sécurisée proprement dite. Lors de cette phase de communication sécurisée, une entité A envoie une trame contenant un identifiant d'utilisateur (qui est fonction du secret partagé et d'un numéro de trame), ainsi qu'une valeur de filtrage (également fonction du secret partagé et du numéro de trame). L'entité B vérifie si l'identifiant reçu est valide par rapport à l'ensemble des identifiants possibles pour toutes les entités A à un instant donné ; le cas échéant, l'entité B vérifie la valeur de filtrage pour l'entité A identifiée. Le même principe s'applique lorsque B envoie une trame à A. Pour chaque trame reçue, l'entité A et l'entité B mettent à jour leurs valeurs d'identifiants et de filtrage. Le protocole IPACF offre une bonne protection contre les attaques par inondation, puisque toute trame reçue par A ou B non associée à un identifiant et à une valeur de filtrage valides est rejetée. Cette vérification est triviale pour le récepteur, car il s'agit d'une comparaison avec des valeurs pré-calculées. Par ailleurs, ce protocole offre une bonne protection contre le rejeu, puisque les valeurs d'identifiant et de filtrage changent à chaque trame.

Mais le protocole IPACF présente certains inconvénients. En premier lieu, le mécanisme est sensible aux pertes de trames, puisqu'à toute trame émise par A doit répondre une trame émise par B ; cet inconvénient est notamment gênant dans le cas d'un protocole de transport en mode non-connecté, où les paquets de signalisation peuvent arriver dans un ordre quelconque, et éventuellement se perdre en route. En second lieu, le mécanisme est « asymétrique » en ce sens que chaque entité A ne peut communiquer qu'avec une entité B avec laquelle elle dispose d'un secret partagé ; ainsi, il n'est pas possible d'envisager des communications sécurisées directes entre deux entités utilisateur A. Un mécanisme « symétrique » bien adapté aux réseaux comprenant un grand nombre d'usagers consiste à mettre en place un tiers de confiance, communément appelé « Centre dê Distribution de Clés ». Chaque entité réseau A souhaitant faire appel. à ce service de communications sécurisées s'abonne auprès du Centre de Distribution de Clés, et obtient en conséquence, pour une durée prédéterminée ou pour une transaction prédéterminée, une clé secrète KSA partagée entre A et un Serveur d'Autorisation S associé au Centre de Distribution de Clés. Avantageusement, les abonnés à ce service n'ont pas à stocker de secrets ou de certificats concernant les autres abonnés, la sécurisation des communications se faisant transaction par transaction avec la participation du Centre de Distribution de Clés. De plus, le Centre de Distribution de Clés peut selon les besoins transmettre de manière sécurisée des clés secrètes à des entités de support (stockage, passerelles, et ainsi de suite) placées sous son contrôle, ou à des entités légales pour l'interception de certaines communications. Comme le Centre de Distribution de Clés est le dépositaire de toutes les clés secrètes des abonnés, il est évidemment indispensable qu'il soit puissamment protégé contre les intrusions hostiles, mais cela ne représente pas de difficulté particulière.

L'article intitulé « IDDR-CEP: Inter-Domain and DoS-Resistent Cal/ Establishment Protocol » de P. Battistello (soumis pour la conférence IPTComm 2010) divulgue un tel protocole de communications sécurisées entre deux entités A et B abonnées au service. Ce protocole IDDR-CEP comprend essentiellement les étapes suivantes : a) l'entité A envoie à un Serveur d'Autorisation S une requête d'autorisation dans laquelle l'entité A s'identifie et s'authentifie comme le détenteur d'un identifiant IDA ; b) l'entité A déclare au Serveur d'Autorisation S son intention 10 de communiquer avec une certaine entité B ; le Serveur d'Autorisation S détermine une clé secrète KSB qu'il partage avec cette entité B ; c) le Serveur d'Autorisation S engendre une clé de session KNB , ladite clé de session KNB étant une fonction à sens unique de ladite clé secrète KSB et étant également fonction d'un entier N , appelé 15 numéro de transaction, affecté à ladite transaction ; puis le Serveur d'Autorisation S envoie ladite clé de session KNB à l'entité A ; d) le Serveur d'Autorisation S engendre également une « valeur de filtrage » IDTRN , qui est une fonction dépendant au moins dudit numéro de transaction N de manière non-inversible ; 20 e) le Serveur d'Autorisation S fait parvenir à l'entité B des éléments comprenant au moins ladite valeur de filtrage IDTRN ; f) l'entité B vérifie que la valeur de filtrage IDTRN reçue lors de ladite étape e) figure au sein d'un ensemble de valeurs précalculées par l'entité B et associées à au moins une valeur prévue du numéro de 25 transaction, puis en déduit la valeur courante du numéro de transaction N ; et g) l'entité B engendre la clé de session KNB L'entité A peut alors compléter la transaction avec l'entité B. Par exemple, si l'entité B est un fournisseur de services, l'entité A pourra faire la demande d'un service particulier et l'obtenir, en échangeant avec l'entité B des données chiffrées au moyen de la clé de session KNB Comme autre exemple, si l'entité B attend un document de la part de l'entité A, cette dernière pourra envoyer à l'entité B un message original accompagné du code «MAC » de ce message original obtenu au moyen de la clé de session KNAB (on rappelle à cet égard que, de manière classique, un code d'authentification de message, appelé en anglais « Message Authentication Code », ou « MAC », est une valeur courte --généralement quelques dizaines de bits -- déduite des données contenues dans un message et d'une clé secrète partagée entre l'émetteur et le récepteur du message l'aide d'un algorithme cryptographique ; en envoyant un message accompagné de son code d'authentification, l'émetteur permet au récepteur de vérifier que ces données n'émanent pas d'une autre entité et n'ont pas été altérées entre leur émission et leur réception). On bénéficie ainsi des avantages, mentionnés ci-dessus, des procédés de communications sécurisées du type « Centre de Distribution de Clés ». Notamment, on impose une vérification de l'authenticité de toute entité abonnée au service de communications sécurisées avant qu'elle ne s'adresse à une autre entité abonnée, afin d'offrir des garanties de sécurité à cette autre entité. Par ailleurs, selon le protocole IDDR-CEP, l'entité B reçoit, lors de 25 l'étape e) ci-dessus, la valeur de filtrage IDTRN de la part du Serveur d'Autorisation S . En outre, l'entité B calcule la valeur de filtrage IDTRN pour au moins une valeur N du numéro de transaction, cette valeur étant prévue pour faire suite, selon un algorithme prédéterminé, à une valeur utilisée dans une transaction précédente. Or, lorsque plusieurs transactions ont été autorisées sur une courte période par le Serveur d'Autorisation S pour une même entité B , il peut se produire que les éléments envoyés à cette entité B lors de ladite étape e) ne lui parviennent pas dans l'ordre des numéros de transaction N prescrits par l'algorithme. Pour résoudre ce problème, le protocole IDDR-CEP prévoit que, de préférence, l'entité B précalcule la valeur de filtrage IDTRN pour une séquence prédéterminée de plusieurs valeurs de l'entier N , et que, après réception d'une certaine valeur de filtrage IDTRN , l'entité B identifie, par scrutation dans cet ensemble de valeurs de IDTRN , à quel numéro de transaction N correspond la valeur de filtrage reçue. On notera que la valeur de IDTRN est une fonction dépendant au moins de l'entier N de manière non-inversible, de sorte qu'il n'est pas possible de calculer la valeur de l'entier N à partir de la valeur de IDTRN en inversant cette fonction, ni de calculer l'une quelconque des valeurs IDTRN+r (i > 0) en connaissant toute ou partie des valeurs précédentes IDTRN_ (j ? 0). Grâce à ces dispositions, les entités abonnées au service de communications sécurisées sont avantageusement protégées contre les attaques par inondation ou par rejeu. En effet, l'entité B détecte une telle attaque facilement (c'est-à-dire en peu d'opérations de calcul) lorsqu'elle constate qu'une valeur reçue et censée représenter une valeur de filtrage IDTRN valide ne figure pas au sein dudit ensemble de valeurs précalculées (un attaquant a une chance infime de deviner une valeur de numéro de transaction N acceptable à un moment donné par une entité B donnée, de sorte que cet attaquant ne peut pas calculer une valeur de IDTRN acceptable, même si la façon dont la valeur de filtrage IDTRN est fonction de N est rendue publique).

De plus, la taille (en nombre de bits) des messages protocolaires dans le protocole IDDR-CEP est avantageusement faible. En effet, d'une part, ni Serveur d'Autorisation S ni l'entité A n'ont à envoyer la clé de session KNB à l'entité B. D'autre part, la transmission de la valeur de filtrage IDTRN du Serveur d'Autorisation S à l'entité B lors de l'étape e) ci-dessus ne requiert pas non plus de message(s) de grande taille, car la valeur de filtrage IDTRN peut être une fonction de taille modeste (de manière caractéristique, quelques octets) tout en offrant une bonne sécurité sur le plan cryptographique.

Le protocole IDDR-CEP prévoit donc la mise en place d'un Serveur d'Autorisation S . Or il est souhaitable, dans de nombreux cas pratiques, de disposer d'une pluralité de Serveurs d'Autorisation Si (où i =1,2,..., p ) plutôt que d'un seul. Il peut s'agir par exemple : - de besoins de redondance ; typiquement, les entités Si et B appartiennent au même domaine ou réseau, et le nombre d'entités Si se limite à quelques unités de manière à assurer le partage de charge ou la redondance en cas de panne ; et/ou - de besoins de service : typiquement, les entités Si et B appartiennent toutes à des domaines différents ; par exemple l'entité B 20 est le proxy entrant du domaine « orange.fr », et chaque entité Si est un proxy sortant d'un domaine tiers pouvant émettre des messages vers le domaine orange.fr. Mais pour pouvoir réaliser cet objectif de Serveurs d'Autorisation multiples, il faut pouvoir résoudre toute une série de problèmes : 25 - l'entité B doit savoir lequel des Serveurs d'Autorisation Si gère la transaction en cours, car, comme dans le protocole IDDR-CEP, il est fortement souhaitable que l'authentification de l'entité A soit de la responsabilité d'un Serveur d'Autorisation ; par conséquent, pour se défendre contre des attaques par usurpation d'identité, B doit pouvoir authentifier ce Serveur d'Autorisation, c'est-à-dire l'identifier (parmi les p serveurs du groupe) de manière sécurisée ; - sauf cas particuliers (petit groupe de Serveurs d'Autorisation appartenant à un même domaine), il faut empêcher que l'un quelconque des Serveurs d'Autorisation du groupe ne puisse découvrir les éléments secrets utilisés par un quelconque autre Serveur d'Autorisation du groupe ; - il est fortement souhaitable qu'un nombre quelconque k de Serveurs d'Autorisation S. distincts soient autorisés à gérer k transactions ayant toutes le même numéro de transaction N , et ceci, afin d'éviter que les Serveurs d'Autorisation S. du groupe ne soient obligés de se coordonner entre eux de manière à ce qu'il ne puisse y avoir, pour l'ensemble du groupe, qu'une seule transaction possible associée à un numéro de transaction N donné ; mais alors, par sécurité, et pour des besoins légaux (séquestre), il ne faut pas pas que deux transactions de même numéro de transaction N gérées par des Serveurs d'Autorisation distincts puissent engendrer la même clé de session ; - il est fortement souhaitable que la taille des messages protocolaires soit suffisamment faible pour permettre l'utilisation d'un mode de transport non-connecté (par exemple, associé au protocole de signalisation SIP), dans lequel la taille nominale des messages de signalisation empêche l'insertion de données de grande taille ; et - il est fortement souhaitable que le protocole puisse s'accommoder aisément d'une montée en charge (« scalability » en anglais) si l'on souhaite autoriser un grand nombre d'entités S. (par exemple, plusieurs centaines) à gérer des transactions impliquant une même entité B. La présente invention concerne donc un procédé de communications sécurisées dans un réseau de télécommunications, ledit 12 réseau comprenant un groupe de serveurs Si (où , et p est un entier strictement positif), dits Serveurs d'Autorisation. Ce procédé comprend, pour une transaction entre une entité A et une entité B dudit réseau, les étapes suivantes : a) l'entité A envoie à l'un des Serveurs d'Autorisation Si une requête d'autorisation dans laquelle l'entité A s'identifie et s'authentifie comme le détenteur d'un identifiant IDA ; b) l'entité A déclare audit Serveur d'Autorisation Si son intention de communiquer avec l'entité B ; le Serveur d'Autorisation Si détermine une clé secrète individuelle KS8 B qu'il partage avec cette entité B; c) le Serveur d'Autorisation Si engendre une clé de session KNS, qui est une fonction à sens unique de ladite clé secrète individuelle KS,B , et est également fonction d'un entier N , appelé numéro de transaction, affecté à ladite transaction ; le Serveur d'Autorisation Si envoie ladite clé de session KN s, à l'entité A ; d) le Serveur d'Autorisation Si engendre également une valeur de filtrage IDTRN , qui est une fonction dépendant au moins dudit numéro de transaction N de manière non-inversible ; puis il engendre un identifiant de transaction IDTRN S, , qui est une fonction de ladite valeur de filtrage IDTRN , de ladite clé secrète individuelle KS,B , et d'un identifiant IDS, de ce Serveur d'Autorisation S, ; e) le Serveur d'Autorisation Si fait parvenir à l'entité B des éléments comprenant au moins ledit identifiant de transaction IDTRN.s, ; f) à l'aide de l'identifiant de transaction IDTRN si reçu lors de ladite étape e), l'entité B : - identifie la valeur de filtrage IDTRN courante au sein d'un ensemble de valeurs de filtrage précalculées par l'entité B et associées à 5 au moins une valeur prévue du numéro de transaction, et - obtient l'identifiant de Serveur d'Autorisation IDS, , et en déduit la clé secrète individuelle KSie correspondante ; et g) l'entité B engendre la clé de session KNB , . II est clair que l'étape b) n'est pas nécessairement postérieure à 10 l'étape a). De même, l'étape d) n'est pas nécessairement postérieure à l'étape c). On notera que l'invention s'applique à un nombre quelconque de Serveurs d'Autorisation (y compris un seul), mais elle est particulièrement avantageuse lorsque le nombre p de Serveurs d'Autorisation est élevé. 15 On notera également que l'évaluation de l'authenticité de l'entité A peut être effectuée par tout moyen d'authentification connu. De plus, cette évaluation peut être effectuée en s'adressant préalablement à un Serveur d'Authentification distinct du Serveur d'Autorisation S,. On notera également qu'en pratique, et pour des besoins de 20 séparation cryptographique, ce n'est pas nécessairement la clé (primaire) de session KNB , qui sera utilisée pour le chiffrement des échanges entre les entités A et B , mais, le cas échéant, une ou plusieurs clé(s) dérivée(s) de KNg,. Dans un souci de simplification, les clés dérivées d'une clé primaire ne seront pas systématiquement explicitées dans le 25 présent document, mais une opération de dérivation ou de diversification selon l'état de l'art sera implicite dès lors qu'un même secret partagé sert à mettre en oeuvre une pluralité de fonctions cryptographiques. 14 Selon l'invention, donc, un Serveur d'Autorisation S, détermine, pour une nouvelle transaction ayant une certaine entité B comme destinataire, un numéro de transaction N. Puis le Serveur d'Autorisation S, fournit une clé de session KNB, à l'entité A. Comme dans le protocole IDDR-CEP, l'entité B possède des moyens pour calculer elle-même cette clé de session ; selon la présente invention, l'entité B utilise pour ce faire une clé secrète individuelle KS1B , ainsi que le numéro de transaction courant N , dont l'entité B détermine la valeur après réception d'un « identifiant de transaction » IDTRN s, en provenance du Serveur d'Autorisation S,, soit directement, soit via une autre entité, qui peut avantageusement être l'entité A (cf. les modes de réalisation décrits en détail ci-dessous). Chaque Serveur d'Autorisation Si détermine les numéros de transaction N successifs relatifs à une entité B donnée selon un algorithme prédéterminé (dont on donnera des exemples ci-dessous). L'entité B précalcule une « valeur de filtrage » IDTRN pour au moins une valeur du numéro de transaction N. Pour les mêmes raisons que dans le protocole IDDR-CEP, l'entité B précalcule de préférence les valeurs de filtrage IDTRN pour plusieurs valeurs prévues du numéro de transaction N (ce que, dans le cadre de la présente invention, on appellera une « fenêtre de transactions »). On notera à cet égard que les Serveurs d'Autorisation S, n'ont pas, quant à eux, besoin de gérer de fenêtre de transactions. On notera également que la séquence de numéros de transaction utilisée, conformément audit algorithme, par un Serveur d'Autorisation S, donné pour une entité B donnée, est (sauf agencement particulier) indépendante de la séquence de numéros de transaction utilisée par le même Serveur d'Autorisation S, pour une autre entité B ; par conséquent, les fenêtres de transactions utilisées par les diverses entités B sont (sauf agencement particulier) mutuellement indépendantes. L'identifiant de transaction IDTRN s, est une fonction de la valeur de filtrage IDTRN , de la clé secrète individuelle Ks,B , et d'un identifiant IDs, de ce Serveur d'Autorisation S. . Comme il sera expliqué en détail ci- dessous, l'entité B obtient, après réception de l'identifiant de transaction IDTRN,s, , la valeur de filtrage IDTRN courante par scrutation dans l'ensemble desdites valeurs de filtrage précalculées associées à la fenêtre de transactions courante. L'entité B en déduit ensuite l'identifiant Ms,. On notera que, contrairement au protocole IDDR-CEP, la valeur de filtrage IDTRN n'est pas transmise à l'entité B en clair, mais sous une forme plus ou moins partiellement masquée (cf. exemples de réalisation ci-dessous), et ce, afin d'empêcher qu'un attaquant (autre qu'un Serveur d'Autorisation corrompu distinct du présent Serveur d'Autorisation S;) ne puisse, à partir de l'identifiant de transaction IDTRN,si et de la valeur de filtrage IDTRN , obtenir l'identifiant IDsi du Serveur d'Autorisation S, . L'entité B peut dès lors détecter une attaque facilement, c'est-à-dire en peu d'opérations de calcul, lorsqu'elle constate : que la valeur de l'identifiant de transaction IDTRN,s, reçu n'est compatible avec aucune des valeurs de filtrage IDTRN précalculées, ou que la valeur IDs, déduite n'est l'identifiant d'aucun des Serveurs d'Autorisation du groupe, ou encore que ce Serveur d'Autorisation S, a déjà autorisé pour l'entité B une transaction précédente de même numéro N.

L'invention offre donc avantageusement (comme le faisait le protocole IDDR-CEP, bien qu'avec d'autres moyens) une excellente protection des entités abonnées au service de communications sécurisées contre les attaques par inondation ou par rejeu.

La présente invention maintient également la propriété du protocole IDDR-CEP concernant la faible taille des messages protocolaires. En effet, d'une part, ni Serveur d'Autorisation Si ni l'entité A n'ont à envoyer la clé de session KNB i à l'entité B ; d'autre part, la transmission (directe ou indirecte) de l'identifiant de transaction IDTRN,si à l'entité B lors de l'étape e) ci-dessus ne requiert pas de message(s) de grande taille, car l'identifiant de transaction IDTRN,si peut être une fonction de taille modeste (de manière caractéristique, quelques dizaines d'octets) tout en offrant une bonne sécurité sur le plan cryptographique. Selon des caractéristiques particulières, l'entité B vérifie, lors de l'étape f) ci-dessus, que la valeur de l'identifiant de transaction IDTRN,si reçu est cohérente avec la clé secrète individuelle Ksia . Grâce à ces dispositions, l'entité B peut authentifier le Serveur d'Autorisation Si qui est censé avoir autorisé la transaction courante. Selon d'autres caractéristiques particulières, lesdits Serveurs d'Autorisation utilisent, pour déterminer les numéros de transaction N successifs relatifs à une entité B donnée, un algorithme commun à l'ensemble des Serveurs d'Autorisation dudit groupe. Grâce à ces dispositions, chaque entité B ne gère qu'une seule fenêtre de transactions (telle que définie ci-dessus), quel que soit le nombre de Serveurs d'Autorisation dans ledit groupe. La tâche de gestion de l'entité B est donc grandement simplifiée, et ce, d'autant plus que le nombre p de Serveurs d'Autorisation est élevé.

Dans ces conditions, les Serveurs d'Autorisation du groupe partagent une fenêtre de transactions commune avec toute entité B donnée. Or ces Serveurs d'Autorisation peuvent recevoir, a priori, des requêtes demandant l'autorisation de communiquer avec cette entité B avec un débit de réception tout-à-fait différent d'un Serveur d'Autorisation à l'autre. On prévoira donc, de préférence, un mécanisme de synchronisation destiné à garantir que les numéros de transaction N déterminés par les divers Serveurs d'Autorisation tombent, dans des conditions de fonctionnement normales, à l'intérieur de la fenêtre de transactions gérée par l'entité B , et que, inversement, la fenêtre de transactions gérée par l'entité B « glisse » de concert avec le Serveur d'Autorisation S, ayant le débit de transactions le plus élevé. Selon une première variante (qui sera appellée « synchronisation à base d'horloge » ci-après), le numéro de transaction N déterminé, pour une entité B donnée, par un Serveur d'Autorisation Si quelconque à un instant td donné est une fonction prédéterminée de cet instant td et d'un numéro de référence NB, dont la valeur est un secret partagé par l'entité B et par l'ensemble des Serveurs d'Autorisation du groupe. Grâce à ces dispositions, la largeur de la fenêtre de transactions gérée par l'entité B à un instant td donné ne doit refléter que l'incertitude sur l'instant t,. correspondant auquel l'entité B reçoit les éléments que le Serveur d'Autorisation S, lui a fait parvenir conformément à l'étape e) du procédé selon l'invention. Cette incertitude résulte, d'une part, des délais de transmission (directe ou indirecte, rappelons-le) de ces éléments, et d'autre part des limitations techniques dans la synchronisation des horloges internes respectives de l'entité B et du Serveur d'Autorisation S.. Somme toute, cette incertitude, et donc la largeur de la fenêtre de transactions, est habituellement assez faible, de sorte que le nombre de valeurs de filtrage qu'une entité B doit précalculer est avantageusement petit. De préférence, la valeur du numéro de référence NB est mise à jour périodiquement au moyen d'une fonction à sens unique prédéterminée. Cette première variante possède alors, essentiellement, la propriété dite « Forward Secrecy » en anglais, à savoir la propriété selon laquelle la compromission de secrets à long terme (clé privée ou secret partagé) ne doit pas permettre à un attaquant de reconstituer les clés de session antérieures à cette compromission. On peut vérifier que c'est bien le cas en l'occurrence, même lorsque l'attaquant est un Serveur d'Autorisation corrompu. En effet, si un attaquant parvient à compromettre un Serveur d'Autorisation Si , il aura accès à sa clé secrète individuelle KS,e , ainsi qu'à la valeur courante du numéro de transaction N , ce qui lui permet de calculer la clé de session KNB i associée à la transaction courante ainsi qu'aux transactions suivantes gérées par ce Serveur d'Autorisation Si corrompu. Cependant, comme la mise à jour du numéro de référence NB est réalisée au moyen d'une fonction à sens unique, cet attaquant n'aura pas accès aux valeurs du numéro de transaction N antérieures à la dernière mise à jour. On peut donc, selon la période choisie pour la mise à jour du numéro de référence NB, ajuster la sécurité offerte par le système, c'est-à-dire la durée antérieure pendant laquelle la propriété « Forward Secrecy » n'est pas assurée en cas de compromission.

Selon une deuxième variante (qui sera appellée « synchronisation à base de messages réseau » ci-après), le numéro de transaction N déterminé, pour une entité B donnée, par un Serveur d'Autorisation Si quelconque est une fonction de séquencement prédéterminée du numéro 19 de transaction précédent, et ce Serveur d'Autorisation Si envoie à l'entité B un message de synchronisation à chaque fois que le Serveur d'Autorisation Si détermine pour l'entité B une valeur du numéro de transaction appartenant à une série de valeurs prédéterminées.

Grâce à ces dispositions, l'entité B , qui reçoit de tels messages de synchronisation de la part de chacun des Serveurs d'Autorisation du groupe, peut alors caler sa fenêtre de transactions en fonction du dernier numéro de transaction N déterminé par le Serveur d'Autorisation Si ayant le débit de transactions le plus élevé. De plus, cette entité B peut envoyer des messages de synchronisation à l'ensemble des Serveurs d'Autorisation du groupe afin que les Serveurs d'Autorisation ayant les débits de transaction les plus faibles puissent mettre à jour leur numéro de transaction courant en conséquence. La séquence des numéros de transaction N peut, dans cette deuxième variante, être simplement l'ordre croissant des entiers naturels, mais on choisira, de préférence, une fonction à sens unique pour ladite fonction de séquencement ; en effet, cette deuxième variante possèdera alors, avantageusement, la propriété de « Forward Secrecy » mentionnée ci-dessus.

Selon d'autres caractéristiques particulières, tout ou partie desdits éléments envoyés à l'entité B lors l'étape e) ci-dessus sont protégés en intégrité. Grâce à ces dispositions, on protège ces éléments contre toute altération ; or une telle altération ferait échouer la transaction dans la plupart des cas. Cette protection en intégrité peut notamment être réalisée au moyen d'un code MAC. Selon des caractéristiques encore plus particulières, cette protection en intégrité est réalisée au moyen de ladite clé de session KNB, ou d'une clé dérivée de cette clé de session KNB Grâce à ces dispositions, l'entité B pourra s'assurer que l'entité qui lui a envoyé des éléments comprenant un identifiant de transaction IDTRN sr valide dispose bien de la clé de session KNB, associée à la transaction courante. Ces dispositions permettent également d'adresser 5 les identifiants de transaction IDTRN.sr à l'entité B en clair par mesure de simplicité. Selon encore d'autres caractéristiques particulières, lesdits éléments que le Serveur d'Autorisation S, fait parvenir à l'entité B lors de l'étape e) ci-dessus comprennent également une donnée CHECKNB, 10 dépendant du numéro de transaction N et déduite, au moyen d'une fonction cryptographique dépendant d'une clé secrète Ks1B,check dérivée de ladite clé secrète Ks,B , d'un ensemble d'éléments tirés de ladite requête d'autorisation et, optionnellement, du numéro de transaction N. Grâce à ces dispositions, le Serveur d'Autorisation S, peut prouver 15 à l'entité B qu'il a bien autorisé la transaction et lui indiquer les informations sur lesquelles il s'est appuyé pour le faire. Selon encore d'autres caractéristiques particulières, l'entité A fait parvenir à l'entité B ledit identifiant IDA de l'entité A, ou un identifiant dérivé ID'A utilisé par exemple pour des besoins d'anonymat. 20 Grâce à ces dispositions, l'entité B est informée de l'identité de l'entité A qui a initié avec elle la transaction de numéro N. Selon des caractéristiques encore plus particulières : - ledit ensemble d'éléments dont est déduite ladite donnée CHECKNB, comprend l'identifiant IDA de l'entité A ou ledit identifiant dérivé ID'A , et 25 - lors de ladite étape f), l'entité B vérifie, au moyen de ladite clé secrète KSIB.check , la cohérence entre, d'une part, la donnée CHECKNB; reçue 21 (directement ou indirectement) du Serveur d'Autorisation Si comme décrit succinctement ci-dessus, et d'autre part lesdits éléments comprenant l'identifiant IDA ou l'identifiant dérivé ID'A reçus de l'entité A comme décrit succinctement ci-dessus.

Grâce à ces dispositions, l'entité B peut vérifier que l'entité A qui s'adresse à elle a bien été autorisée par le Serveur d'Autorisation S, sous la même identité IDA ou ID'A . On protège ainsi l'entité B contre les usurpations d'identité (« phishing » en anglais). Corrélativement, l'invention concerne divers dispositifs.

Elle concerne ainsi, premièrement, un dispositif, dit Serveur d'Autorisation, pour sécuriser les communications dans un réseau de télécommunications lors d'une transaction entre une entité A et une entité B , comprenant des moyens pour : - identifier et authentifier une entité A détentrice d'un identifiant IDA , - déterminer une clé secrète individuelle Ks B que ledit Serveur d'Autorisation S, (où i =1,2,...,p , et p est un entier strictement positif) partage avec une entité B avec laquelle l'entité A déclare son intention de communiquer, - engendrer une clé de session KNBr et l'envoyer à l'entité A, ladite clé de session KNB i étant une fonction à sens unique de ladite clé secrète individuelle KS8 8 et étant également fonction d'un entier N , appelé numéro de transaction, affecté à ladite transaction, - engendrer une valeur de filtrage IDTRN , qui est une fonction dépendant au moins dudit numéro de transaction N de manière non-inversible, - engendrer un identifiant de transaction IDTRN,si, qui est une fonction de ladite valeur de filtrage IDTRN , de ladite clé secrète individuelle Ks,B , et d'un identifiant IDsi de ce Serveur d'Autorisation S, , et - faire parvenir à ladite entité B des éléments comprenant au moins ledit identifiant de transaction IDTRN,si. Elle concerne aussi, deuxièmement, un dispositif, dit entité B , de communications sécurisées dans un réseau de télécommunications, caractérisé en ce qu'il comprend des moyens pour, lors d'une transaction impliquant ladite entité B et une entité A : - recevoir des éléments comprenant au moins un identifiant de transaction IDTRN si engendré par un Serveur d'Autorisation Si (où i =1,2,..., p , et p est un entier strictement positif), ledit identifiant de transaction IDTRN si étant une fonction d'une valeur de filtrage IDTRN , d'une clé secrète individuelle KsiB partagée par l'entité B et ledit Serveur d'Autorisation Si , et d'un identifiant IDsi de ce Serveur d'Autorisation Si , et ladite valeur de filtrage IDTRN étant une fonction dépendant au moins, de manière non-inversible, d'un entier N , appelé numéro de transaction, affecté à ladite transaction, - à l'aide dudit identifiant de transaction IDTRN si , - identifier la valeur de filtrage IDTRN courante au sein d'un ensemble de valeurs de filtrage précalculées par l'entité B et associées à au moins une valeur prévue du numéro de transaction, et - obtenir l'identifiant de Serveur d'Autorisation IDsi, et en déduire la clé secrète individuelle KsiB correspondante, et - engendrer une clé de session KNS, qui est, d'une part, fonction dudit numéro de transaction N , et d'autre part une fonction à sens unique de ladite clé secrète individuelle Ks,B . Selon des caractéristiques particulières, ladite entité B comprend en outre une table de correspondance mettant en relation au moins une valeur prévue du numéro de transaction avec la valeur de filtrage précalculée associée. Grâce à ces dispositions (cf. modes de réalisation ci-dessous), l'entité B peut commodément, par simple scrutation de cette table de correspondance, déduire la valeur de filtrage courante de l'identifiant de transaction reçu, puis lire la valeur du numéro de transaction associée à cette valeur de filtrage courante. Inversement, l'entité B peut commodément, par simple scrutation de cette table de correspondance, lire la valeur de filtrage associée au numéro de transaction courant, que l'entité B a préalablement déduit de l'identifiant de transaction reçu. L'invention concerne aussi, troisièmement, un dispositif, dit entité A, de communications sécurisées dans un réseau de télécommunications, comprenant des moyens pour, lors d'une transaction impliquant ladite entité A et une entité B : - s'identifier et s'authentifier comme le détenteur d'un identifiant IDA auprès d'un Serveur d'Autorisation S, (où i =1,2,..., p , et p est un entier strictement positif), - déclarer audit Serveur d'Autorisation S. son intention de communiquer avec une certaine entité B , - recevoir de la part du Serveur d'Autorisation S. une clé de session KNB; , ladite clé de session KNS, étant une fonction à sens unique d'une clé secrète individuelle Ks,B partagée par le Serveur d'Autorisation S, et ladite entité B , et étant également fonction d'un entier N , appelé numéro de transaction, affecté à ladite transaction, - recevoir de la part du Serveur d'Autorisation Si un identifiant de transaction IDTRN s, , ledit identifiant de transaction IDTRN s, étant une fonction d'une valeur de filtrage IDTRN , de ladite clé secrète individuelle Ks,B , et d'un identifiant IDs, de ce Serveur d'Autorisation Si, et ladite valeur de filtrage IDTRN étant une fonction dépendant au moins, de manière non-inversible, dudit numéro de transaction N , et - envoyer à l'entité B des éléments comprenant au moins ledit identifiant de transaction IDTRN.s, . Ce troisième dispositif est donc associé au mode de réalisation de l'invention, brièvement mentionné ci-dessus, dans lequel la transmission de l'identifiant de transaction IDTRN,st du Serveur d'Autorisation S, à l'entité B est relayée par l'entité A.

L'invention concerne également un dispositif cumulant les moyens des deux derniers dispositifs décrits succinctement ci-dessus ; un tel dispositif peut se comporter, selon les circonstances, soit comme une entité expéditrice A, soit comme une entité destinataire B. Les avantages offerts par ces dispositifs sont essentiellement les 20 mêmes que ceux offerts par les procédés corrélatifs succinctement exposés ci-dessus. On notera qu'il est possible de mettre en oeuvre le procédé de communications sécurisées selon l'invention au moyen d'instructions logicielles et/ou au moyen de circuits électroniques. 25 L'invention vise donc également un programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur. Ce programme d'ordinateur est remarquable en ce qu'il comprend des instructions pour la mise en oeuvre desdits moyens compris dans l'un quelconque des dispositifs de communications sécurisées décrits succinctement ci-dessus. Les avantages offerts par ce programme d'ordinateur sont essentiellement les mêmes que ceux offerts par lesdits dispositifs. D'autres aspects et avantages de l'invention apparaîtront à la lecture de la description détaillée ci-dessous de modes de réalisation particuliers, donnés à titre d'exemples non limitatifs. La description se réfère aux figures qui l'accompagnent, dans lesquelles : - la figure 1 représente schématiquement un réseau de télécommunications et les principales entités auxquelles s'applique l'invention, - la figure 2 représente schématiquement les étapes d'un procédé de communications sécurisées selon un premier mode de réalisation de l'invention, et - la figure 3 représente schématiquement les étapes d'un procédé de communications sécurisées selon un deuxième mode de réalisation de l'invention. Le système illustré sur la figure 1 comprend au moins trois entités interconnectées via un réseau de communication, par exemple un réseau de type Internet. Le procédé est particulièrement avantageux dans le cas d'un mode de transport non-connecté, mais convient également à un mode de transport connecté. Les entités A et B sont abonnées au même service de communications sécurisées. Elles utilisent chacune, de manière classique, un terminal ou un serveur apte à émettre ou recevoir des messages de nature quelconque tels que, par exemple, des courriers électroniques ou des appels téléphoniques sur des canaux fixes ou mobiles. On notera que, dans le cadre de la présente invention, le mot « serveur » est, pour simplifier l'exposé, utilisé pour désigner uniformément tout type de dispositif informatique, et non uniquement les dispositifs informatiques classiquement désignés sous le nom de « serveurs ». En pratique, l'entité A peut jouer le rôle de serveur ou relais pour une entité A' connectée à l'entité A ; de même, l'entité B peut jouer le rôle de serveur ou relais pour une entité B' connectée à l'entité B. L'entité Si (où i = 1,2,..., p) est un « Serveur d'Autorisation » (pouvant, naturellement, être composé en pratique de plusieurs serveurs physiques) appartenant à un groupe de p Serveurs d'Autorisation. Cette entité Si permet à une entité abonnée A de s'adresser de manière sécurisée à une autre entité abonnée B ; de plus, elle protège l'entité B contre la réception de messages indésirables. Suivant les applications et les scénarios de déploiement (cf. exemples ci-dessous), l'entité Si peut être indépendante des domaines applicatifs ou réseaux auxquels appartiennent les entités A et B , ou bien l'entité Si peut appartenir au même domaine applicatif ou réseau que l'entité A et/ou que l'entité B. Le Serveur d'Autorisation Si prend en compte une séquence de valeurs entières, dites « numéros de transaction », séparément pour chaque entité B. Le numéro de transaction N permet d'ordonner les transactions auxquelles participe l'entité B , mais qui sont initiées par une entité abonnée autre que l'entité B (ou autre qu'une entité pour laquelle, le cas échéant, l'entité B sert de serveur ou de relais). La séquence des numéros de transaction N pour une entité B donnée n'est connue que de cette entité B et du Serveur d'Autorisation Si (ou de l'ensemble des Serveurs d'Autorisation du groupe) ; de plus, aucun numéro de transaction n'est transmis d'une entité à une autre. Grâce à ces dispositions, il est impossible pour un attaquant de trouver la valeur courante du numéro de transaction relatif à une entité abonnée au service de communications sécurisées. La transaction de numéro de transaction N doit être autorisée par le Serveur d'Autorisation S, , suite à une requête d'autorisation émise par l'entité A vers S,. En cas d'approbation, le Serveur d'Autorisation S. répond à cette requête d'autorisation en fournissant à l'entité A les informations nécessaires pour entrer en contact avec l'entité B. Lors de chaque transaction, suite à une identification de l'entité A, le Serveur d'Autorisation Si détermine une clé secrète à long terme Ks,A qu'il partage avec cette entité A. Cette clé secrète à long terme KsIA permet de dériver d'autres clés secrètes qui sont utilisées au besoin pour assurer l'intégrité ou la confidentialité des messages échangés entre A et Si . De même, il existe un secret partagé à long terme Ks1B entre 15 l'entité B et chacun des Serveurs d'Autorisation Si . Cette clé secrète à long terme Ks,B permet de dériver d'autres clés secrètes qui sont utilisées au besoin pour assurer l'intégrité ou la confidentialité des messages échangés (directement ou indirectement) entre S, et B. Pour toute transaction de numéro N , les entités S, et B sont 20 capables d'engendrer indépendamment, en utilisant des algorithmes pouvant être publics, une valeur de filtrage IDTRN , qui doit dépendre au moins de N et être engendrée au moyen d'un algorithme tel que, si l'on connaît une ou plusieurs valeurs IDTRN utilisées dans des transactions précédentes, on ne peut pas en déduire la valeur courante de N , ou une 25 valeur IDTRN+, (i > 0).

Le Serveur d'Autorisation Si engendre en outre un identifiant de transaction IDTRN,si , qui est une fonction de ladite valeur de filtrage IDTRN , de ladite clé secrète individuelle KsiB , et d'un identifiant IDs, de ce Serveur d'Autorisation Si De plus, les entités Si et B sont capables d'engendrer indépendamment, en utilisant des algorithmes pouvant être publics, la clé (primaire) de session es, utilisée entre les entités A et B pour la transaction et la session courantes ; cette clé de session doit dépendre au moins de N et de KsiB, et être engendrée au moyen d'un algorithme tel que, même si l'on connaît la valeur de KNB i et la valeur de N , on ne peut pas en déduire la valeur de KsiB . De manière classique, la clé primaire de session (ou de transaction) KNB, permet de dériver d'autres clés secrètes qui sont utilisées au besoin pour assurer l'intégrité ou la confidentialité des 15 messages échangés entre A et B. De préférence, l'entité B précalcule les valeurs de filtrage IDTRN pour une séquence prédéterminée de valeurs de l'entier N. Dans ce cas, les Serveurs d'Autorisation S, du groupe utiliseront tous, de préférence, le même algorithme pour déterminer les numéros de transaction N 20 successifs relatifs à cette entité B , de manière à ce que l'entité B n'ait à gérer qu'une seule fenêtre de transactions. Divers algorithmes peuvent être choisis à cet effet, mais l'algorithme choisi devra de préférence incorporer un mécanisme de synchronisation vis-à-vis des divers Serveurs d'Autorisation Si , et ce, afin 25 de minimiser la largeur de la fenêtre de transactions.

Par exemple, dans la « synchronisation à base d'horloge », le numéro de transaction N déterminé, pour une entité B donnée, par un Serveur d'Autorisation Si quelconque à un instant td donné est une fonction prédéterminée de cet instant td et d'un numéro de référence NB, dont la valeur est un secret partagé par l'entité B et par l'ensemble des Serveurs d'Autorisation Si du groupe. L'instant td est une indication horaire (« timestamp » en anglais) évaluée avec une précision prédéterminée, par exemple à la seconde près. Quant au numéro de référence NB, sa valeur est de préférence mise à jour périodiquement (par exemple, toutes les 10 minutes) au moyen d'une fonction à sens unique prédéterminée. Par ailleurs, il est souhaitable dans certains cas (par exemple, pour les applications en temps-réel) qu'un Serveur d'Autorisation Si puisse autoriser plusieurs transactions pendant une même unité de temps t 15 (correspondant à ladite précision prédéterminée). Dans ce cas, l'identifiant de transaction IDTRN si et la clé de session KNB i dépendront également d'un numéro de sous-transaction j . On pourra de plus prévoir que le nombre de sous-transactions par unité de temps que peut autoriser un Serveur d'Autorisation Si ne peut pas dépasser une valeur 20 prédéterminée Jmax Comme autre exemple, dans la « synchronisation à base de messages réseau », le numéro de transaction N déterminé, pour une entité B donnée, par un Serveur d'Autorisation Si quelconque est une fonction de séquencement prédéterminée du numéro de transaction 25 précédent, et ce Serveur d'Autorisation Si envoie à l'entité B un message de synchronisation à chaque fois que le Serveur d'Autorisation Si détermine pour l'entité B une valeur du numéro de transaction appartenant à une série de valeurs prédéterminées (par exemple, toutes les 10 transactions). Dans cette deuxième variante, à l'initialisation du système de la figure 1, les entités Si du groupe et B se mettent d'accord sur un numéro de transaction initial NB , qui varie de préférence d'une entité B à une autre. Ensuite, à chaque transaction, le numéro de transaction N est modifié selon un algorithme pouvant être public ; par exemple, N peut être incrémenté de 1 à chaque nouvelle transaction, mais cet algorithme peut également varier d'une entité B à une autre, auquel cas il doit figurer dans les secrets partagés par les entités Si du groupe et l'entité B. La figure 2 représente schématiquement les étapes d'un premier mode de réalisation du procédé selon l'invention, dans lequel la transmission de l'identifiant de transaction IDTRN Si du Serveur d'Autorisation Si à l'entité B est relayée par l'entité A.

Le présent mode de réalisation a principalement pour objet la mise en place sécurisée d'une clé de session KNBi entre les entités A et B pour la transaction de numéro N , l'usage subséquent (par exemple, transmission confidentielle de flux multimédias, ou paiement électronique) que feront ces entités A et B de cette clé de session KNB i au cours de la session étant indépendant de l'invention. Pour fixer les idées, on supposera qu'une entité A, dite « client expéditeur », souhaite envoyer un « message original » MES à une, ou plusieurs, entité(s) B , dite(s) « client(s) destinataire(s) ». On va décrire à présent les étapes principales de ce mode de réalisation.

Lors d'une première étape E1, une nouvelle transaction est authentifiée, et autorisée, par un Serveur d'Autorisation S, du groupe.

Plus précisément, lors d'une sous-étape E1.1, l'entité A initie une transaction en envoyant une requête d'autorisation REQ à un Serveur d'Autorisation S. , avec qui elle partage une clé secrète Ks,A. Cette requête d'autorisation REQ contient au moins des éléments INFO permettant au Serveur d'Autorisation S, d'authentifier l'entité A, ces éléments comprenant au moins un identifiant IDA de cette entité. La requête d'autorisation REQ peut contenir en outre des informations caractérisant le message MES ou permettant d'identifier l'entité B.

Enfin, lorsque l'intégrité des échanges entre A et S, n'est pas assurée par le protocole de transport sous-jacent, la requête d'autorisation REQ contient de préférence un code d'authentification MAC1 calculé sur tout ou partie des éléments précédemment cités de la requête REQ. Pour ce faire, on utilisera une clé secrète dérivée de la clé secrète Ks,A, que l'on notera KsA,MACI On notera également, concernant les identités des entités A et B , que : - dans certains cas, l'entité A ne connaît pas complètement l'identité du client destinataire de son message original MES ; cette identité est alors déterminée par le Serveur d'Autorisation Si ; - dans certains cas, il est possible que, pour des besoins d'anonymat, l'identifiant IDA de l'entité A ne soit pas révélé à l'entité B , ou que l'entité A demande au Serveur d'Autorisation Si de présenter l'entité A à l'entité B sous un « identifiant dérivé » ID'A ; et - le cas échéant, suivant l'architecture considérée, les identités de A ou B peuvent être remplacées ou complétées par celles de A' ou B' (cf. description de la figure 1 ci-dessus).

Lors d'une sous-étape E1.2, sur réception de la requête d'autorisation REQ, le Serveur d'Autorisation S. décide, en fonction des informations contenues dans cette requête, d'autoriser ou non la transaction.

Si la requête d'autorisation REQ reçue est associée à un code d'authentification MAC1, le Serveur d'Autorisation S, vérifie alors l'intégrité des éléments de la requête d'autorisation REQ concernés. Si besoin, le Serveur d'Autorisation Si détermine l'identité du, ou des, client(s) destinataire(s) B (ou B' ). Enfin, le Serveur d'Autorisation Si vérifie, optionnellement, les éventuelles listes blanches ou noires de l'entité B relativement à l'entité A, au cas où l'entité B aurait déclaré, par exemple, refuser toute transaction avec cette entité A en particulier. Si la transaction est autorisée, le Serveur d'Autorisation S. transmet alors à l'entité A, lors d'une étape E2, une réponse 15 d'autorisation RESP contenant au moins la clé de session KNB ` Lorsque la confidentialité des échanges entre le Serveur d'Autorisation Si et l'entité A n'est pas assurée par le protocole de transport sous-jacent, le Serveur d'Autorisation Si envoie à l'entité A la clé de session KNB sous une forme confidentielle. Cette forme 20 confidentielle peut par exemple être le résultat du chiffrement de la clé de session KNB i au moyen d'un algorithme utilisant ladite clé secrète KsiA ou une clé dérivée de cette clé secrète KsiA. La clé de session KNB; pourra alors être calculée par l'entité A à partir de cette forme chiffrée au moyen d'un algorithme de déchiffrement utilisant la clé secrète KsiA ou 25 ladite clé dérivée de la clé secrète KsiA.

Le Serveur d'Autorisation Si transmet également, dans ce premier mode de réalisation, un identifiant de transaction IDTRN.si à l'entité A , qui se chargera de le retransmettre à l'entité B lors de la sous-étape E3.2 décrite ci-dessous.

On notera qu'il est possible, optionnellement, de transmettre l'identifiant de transaction IDTRN.si en clair. Néanmoins, dans le cas où la confidentialité des échanges entre le Serveur d'Autorisation Sl et l'entité A n'est pas assurée par le protocole de transport sous-jacent, si un attaquant était capable de lire sa valeur, il pourrait envoyer très rapidement à l'entité B un ou plusieurs messages invalides de façon à ce qu'ils soient reçus par l'entité B avant le message légitime émis par l'entité A. L'entité B détecterait en fait une telle attaque, mais seulement après voir procédé à des vérifications supplémentaires (voir ci-dessous) car la valeur de l'identifiant de transaction IDTRN s, lui paraîtrait correcte.

L'entité B serait donc exposée à un risque d'attaque par inondation. Aussi, dans le cas considéré, le Serveur d'Autorisation Si enverra à l'entité A l'identifiant de transaction IDTRN s, de préférence chiffré ou masqué de manière connue, en utilisant pour ce faire la clé secrète KsA ou une clé secrète dérivée de cette clé secrète KsiA.

Comme mentionné ci-dessus, l'identifiant de transaction IDTRN.sr est une fonction de la valeur de filtrage IDTRN , de la clé secrète individuelle KsÉB , et d'un identifiant IDs; du Serveur d'Autorisation S, . On va donner à présent des exemples de réalisation de cette fonction. Dans ces exemples : - la valeur de filtrage IDTRN (longue, par exemple, de 16 octets) est composée d'au moins deux parties logiques, à savoir Va et VI , où la longueur de VI est égale à celle de IDs, (par exemple, 8 octets), - l'identifiant de transaction IDTRN s, est la concaténation d'au moins trois parties, à savoir Po, PI et P2, - la partie P vaut = V1 XOR IDs, , où le symbole « XOR » désigne l'addition bit à bit (opération « ou exclusif »), et - la partie P2 vaut P2 = HMAC (Po Pl), où le symbole « (...I...) » désigne la concaténation, et où HMAC est une fonction cryptographique dépendant de la clé secrète individuelle Ks,B . Ainsi, la partie P2 permet d'authentifier de façon cryptographique le Serveur d'Autorisation S,, qui a été préalablement identifié grâce à la valeur IDs1 contenue dans P1. De plus, la partie P2 protège Po et P en intégrité. La partie P est obtenue par masquage d'une partie V1de la valeur de filtrage IDTRN au moyen de l'identifiant ID& . Cet identifiant IDs, est 20 constant au cours du temps, mais comme la valeur de filtrage IDTRN change à chaque transaction, P change également à chaque transaction, de sorte qu'un attaquant ne connaissant pas le numéro de transaction N ne peut ni prédire les valeurs suivantes de P ni retrouver IDs, à partir de P.

La lecture de P à l'étape E4, décrite ci-dessous, permettra à l'entité B , par opération inverse à celle qui a permis de calculer PI, de retrouver la valeur IDsi contenue dans PI, et de vérifier la validité de la valeur de filtrage IDTRN et de l'identifiant IDsi . Cette double vérification ne peut être réalisée de façon simultanée : en effet, l'entité B doit d'abord déduire la valeur de filtrage IDTRN de l'identifiant de transaction IDTRN,si reçu. A cet effet, on pourra prendra par exemple simplement : Po =Va. Ainsi, l'entité B va comparer la partie Po reçue à la partie Vo des valeurs IDTRN précalculées pour la fenêtre de transactions courante. Cette partie Vo de IDTRN qui apparaît en clair dans IDTRN si sera appelée « amorce de IDTRN ». Dans le cas de la synchronisation à base d'horloge, il est toutefois envisageable, pour plus de sécurité, de masquer complètement IDTRN par IDsi dans Pl. Ainsi un attaquant observant les échanges ne verrait aucune partie de IDTRN en clair. Dans ce cas, « l'amorce de IDTRN » Vo est vide, VI = IDTRN , et il est nécessaire de fournir à l'entité B un autre moyen pour récupérer et vérifier la validité de la valeur de filtrage. Par exemple, on pourra prendre : Po = td , où td désigne, rappelons-le, l'indication horaire ; l'entité B calcule d'abord le numéro de transaction N correspondant à cette indication horaire, et vérifie qu'il figure bien dans la fenêtre de transactions courante ; puis l'entité B récupère la valeur de filtrage IDTRN précalculée correspondant à cette valeur du numéro de transaction.

Dans le cas, mentionné ci-dessus, où l'on choisit la synchronisation à base d'horloge et où les transactions sont caractérisées en complément par un numéro de sous-transaction j , la partie P2 de l'identifiant de transaction IDTRN.s, dépendra également de ce numéro de sous- transaction. La réponse d'autorisation RESP peut contenir également, aux fins de vérification, un sous-ensemble INFO' des informations INFO contenues dans la requête d'autorisation REQ. La réponse d'autorisation RESP peut contenir également une donnée CHECKNB, dépendant du numéro de transaction N et déduite, au moyen d'une fonction cryptographique dépendant d'une clé secrète KsIe,check dérivée de ladite clé secrète Ks,B , d'un ensemble d'éléments tirés de ladite requête d'autorisation REQ et, optionnellement, du numéro de transaction N. On notera que, pour ce faire, on peut envisager (au 15 moins) deux variantes : - selon une première variante, les variables auxquelles est appliquée ladite fonction cryptographique ne comprennent que des éléments tirés de ladite requête d'autorisation ; dans ce cas, il est nécessaire que la clé secrète KSIB,cheek soit une fonction à sens unique du numéro de 20 transaction N (et de la clé secrète Ks,B) ; - selon une deuxième variante, le numéro de transaction N est effectivement inclus dans les variables auxquelles est appliquée ladite fonction cryptographique ; dans ce cas, ladite clé secrète KSIB,check ne dépend pas nécessairement de N , et doit seulement être une fonction à 25 sens unique de la clé secrète Ks,B. De préférence, cette fonction cryptographique dépendra en outre d'un aléa engendré simultanément, lors de chaque transaction, par le Serveur d'Autorisation Si et l'entité B (cet aléa empêche une entité A malveillante de trouver la clé secrète KSjB,check par inversion de la donnée CHECKNB i Comme indiqué ci-dessus, il est possible d'envisager des applications de l'invention dans lesquelles l'entité A est autorisée à rester anonyme vis-à-vis de l'entité B ; dans ce cas (ainsi que dans d'autres cas éventuellement), lesdits éléments tirés de la requête d'autorisation REQ et dont le chiffrement fournit la donnée CHECKNB i ne contiendront aucun identifiant de l'entité A, ou contiendront ledit identifiant dérivé ID'A de l'entité A. Enfin, lorsque l'intégrité des échanges entre A et Si n'est pas assurée par le protocole de transport sous-jacent, la réponse d'autorisation RESP contient de préférence un code d'authentification MAC2 calculé sur tout ou partie des éléments précédemment cités de la réponse RESP. Pour ce faire, on utilisera une clé secrète dérivée de la clé secrète KsiA, que l'on notera KsiA,MAC2 Lors d'une étape E3, l'entité A reçoit la réponse d'autorisation RESP de la part du Serveur d'Autorisation Si , et envoie un « message authentifié » AM à l'entité B.

Plus précisément, lors d'une sous-étape E3.1, après réception de la réponse d'autorisation RESP, l'entité A effectue de préférence les vérifications suivantes : - si la réponse d'autorisation RESP reçue contient des données censées appartenir à un sous-ensemble des informations contenues dans la requête d'autorisation REQ, l'entité A vérifie que ces informations correspondent bien à une requête d'autorisation REQ précédemment émise par elle ; et - si la réponse d'autorisation RESP reçue est associée à un code d'authentification MAC2, l'entité A vérifie l'intégrité des éléments de la réponse d'autorisation RESP concernés. Si ces vérifications sont positives, lors d'une sous-étape E3.2, 5 l'entité A extrait de la réponse d'autorisation RESP la clé de session KNB, , l'identifiant de transaction IDTRN,si, et, le cas échéant, la donnée CHECKNB, . L'entité A envoie alors à l'entité B un message authentifié AM comprenant le message original MES, l'identifiant de transaction IDTRN,si , et, le cas échéant, la donnée CHECKNB , . 10 Lorsque l'intégrité des échanges entre A et B n'est pas assurée par le protocole de transport sous-jacent, le message authentifié AM contient de préférence un code d'authentification MAC3 calculé sur tout ou partie des éléments précédemment cités de ce message AM ; pour ce faire, on utilisera avantageusement la clé de session KNB i ou une clé 15 secrète KNB 1,114AC3 dérivée de la clé de session KNB , . Sauf en cas de besoin d'anonymat complet, le message authentifié AM comprendra l'identifiant IDA ou l'identifiant dérivé ID'A de l'entité A. Cet identifiant pourra naturellement, lui aussi, faire partie desdits éléments servant de base au calcul du code d'authentification MAC3. 20 On notera que, en variante (cf. notamment les exemples d'architecture présentés ci-dessous), le message authentifié AM peut être envoyé par une entité autorisée autre que l'entité A elle-même, par exemple un autre serveur réseau. Le cas où le message authentifié AM est envoyé « directement » par le Serveur d'Autorisation S, sera décrit ci- 25 dessous en référence à la figure 3. Lors d'une étape E4, l'entité B reçoit le message authentifié AM et détermine la clé de session.

Plus précisément, lors d'une sous-étape E4.1, après réception d'un message authentifié AM, l'entité B obtient, comme expliqué ci-dessus, la valeur de filtrage IDTRN courante et le numéro de transaction N courant à partir de l'identifiant de transaction IDTRN,si reçu.

Comme expliqué ci-dessus, après avoir vérifié la validité de la valeur IDTRN obtenue, l'entité B vérifie : - à partir de la valeur de filtrage IDTRN et de l'identifiant de transaction IDTRN s, , l'identité du Serveur d'Autorisation S, qui a autorisé la présente transaction, - que le couple ( IDTRN , IDs,) n'a pas déjà été « consommé », et - à partir de l'identifiant de transaction IDTRN si et de la clé secrète individuelle Ks,B , l'authenticité du Serveur d'Autorisation Si . Si toutes ces vérifications sont positives, l'entité B récupère ou calcule la clé de session KNB,, ainsi que, optionnellement, ladite clé 15 secrète KSiB,Check et/ou ladite clé secrète KNB r,MAC3 associées à cette transaction. Optionnellement, l'entité B vérifie ensuite que : - les informations que l'entité B a reçues sont cohérentes avec le code d'authentification MAC3 (si présent) et la clé de session KNB i ou la 20 clé secrete KNBf,MAC3, et/ou - les informations que l'entité B a reçues sont cohérentes avec la donnée CHECKNBi (si présente) et la clé secrète Ks;B,check Enfin (sauf si ces vérifications optionnelles donnent un résultat négatif), lors d'une sous-étape E4.2, l'entité B extrait le message original MES du message authentifié AM, et transmet, le cas échéant, ce message original MES à un client destinataire B' . La figure 3 représente schématiquement les étapes d'un deuxième mode de réalisation du procédé selon l'invention.

Dans ce mode de réalisation, une entité A, dite « client expéditeur », souhaite envoyer à une, ou plusieurs, entité(s) B , dite(s) « client(s) destinataire(s) » un message original MES. Par ailleurs, ce message original MES peut, dans certaines applications (par exemple, si le message MES est une demande d'initiation d'appel VoIP), jouer simultanément le rôle de requête d'autorisation REQ. Le présent mode de réalisation se distingue essentiellement du premier mode de réalisation, décrit ci-dessus en référence à la figure 2, en ce que le Serveur d'Autorisation Si transmet le message authentifié AM à l'entité B « directement », c'est-à-dire sans utiliser l'entité A comme relais. Ce mode de réalisation présente donc comme inconvénient un surplus de traitement pour le Serveur d'Autorisation Si , mais il peut néanmoins s'avérer pratique dans certaines architectures (voir exemples ci-dessous). On va décrire à présent les étapes principales de ce mode de réalisation. La première étape E'1 est analogue à l'étape El du premier mode de réalisation, si ce n'est que le message MES doit, dans ce deuxième mode de réalisation, être entièrement inclus dans la requête d'autorisation REQ.

La deuxième étape E'2 est analogue à l'étape E2 du premier mode de réalisation, si ce n'est que la réponse d'autorisation RESP ne contient ici ni l'identifiant de transaction IDTRN,s; ni la donnée CHECKNAB,si Lors d'une étape E'3, le Serveur d'Autorisation Si transmet « directement » à l'entité B le message authentifié AM comprenant le message original MES, l'identifiant de transaction IDTRN,si et, optionnellement, la donnée CHECKNB1. Lorsque l'intégrité des échanges entre S, et B n'est pas assurée par le protocole de transport sous-jacent, le message authentifié AM contient de préférence un code d'authentification MAC3 calculé sur tout ou partie des éléments précédemment cités de ce message AM ; pour ce faire, on pourra utiliser, comme dans le premier mode de réalisation, la clé de session KNB, ou une clé secrète KNB I,MAC3 dérivée de la clé de session KNB; ; en variante, on pourra utiliser ici la clé secrète Ks1B ou une clé secrète dérivée de cette clé secrète Ks B . On notera que, comme illustré sur la figure 3, l'étape E'3 peut précéder l'étape E'2. Cet ordre opératoire permet avantageusement d'interrompre la transaction avant que le Serveur d'Autorisation Si n'envoie la réponse d'autorisation RESP à l'entité A, au cas où l'entité B 15 n'envoie pas à Si un accusé de réception du message authentifié AM si un tel accusé de réception était prévu, ou au cas où l'entité B envoie à Si un accusé de réception dans lequel l'entité B déclare refuser cette transaction avec l'entité A. Enfin, l'étape E'4 est analogue à l'étape E4 du premier mode de 20 réalisation. On notera que cette étape E'4 doit naturellement intervenir postérieurement à l'étape E'3, mais qu'elle peut précéder l'étape E'2. On va à présent examiner, à titre d'exemples, diverses architectures possibles pour la mise en oeuvre de l'invention. Les trois premiers exemples s'appliquent à la VoIP. Les services et 25 réseaux VoIP constituent un contexte d'application particulièrement intéressant, car, en plus de fortes contraintes de sécurité, ils ont également des contraintes de temps-réel, de nombre d'entités déployées (actuellement plusieurs millions dans certains réseaux), de puissance des terminaux, ainsi que des contraintes légales qui imposent de pouvoir intercepter les communications sensibles. Ce besoin d'interceptions légales milite naturellement pour le contrôle des clés de session par une entité de confiance (ici, le Serveur d'Autorisation S. ), qui pourrait être alors un proxy d'un opérateur réseau. (a) Communications VoIP intra-domaine Les entités clientes A et B , ainsi que le Serveur d'Autorisation Si font partie du réseau d'un même opérateur. Le Serveur d'Autorisation Si est un proxy VoIP de ce réseau qui dispose classiquement d'un secret partagé avec chacun des terminaux-client, ce secret ayant été établi lors de la phase de souscription au service, puis vérifié lors de la phase d'enregistrement du terminal-client au réseau. La requête d'autorisation REQ envoyée par l'entité A permet au 15 Serveur d'Autorisation Si d'authentifier l'entité A et de déterminer le routage pour atteindre l'entité B. L'appel peut ensuite s'établir directement entre les entités A et B sans qu'il soit nécessaire d'établir une connexion TLS entre A et B pour assurer l'intégrité et la confidentialité de la signalisation. Le message MES 20 correspond à la requête « INVITE ». (b) Interconnexions VoIP mode 1 Dans ce mode de réalisation, les entités expéditrice et destinataire sont localisées dans deux réseaux distincts, appartenant à des opérateurs différents ; le domaine expéditeur est noté D-EXP et le domaine 25 destinataire D-DEST. L'entité A est l'un des proxys sortants du domaine expéditeur DEXP. L'entité A sert plusieurs terminaux clients A' du domaine D-EXP ou des serveurs émetteurs A' dans le même domaine, ou dans un domaine tiers lorsque le terminal-client est en situation de mobilité. Le Serveur d'Autorisation S, est l'un des proxys entrants du domaine destinataire D-DEST. Le Serveur d'Autorisation S, protège et dessert une ou plusieurs entité(s) B pouvant appartenir au domaine destinataire D-DEST ou à des domaines tiers. L'entité B peut correspondre directement au terminal-client destinataire. En variante, l'entité B peut correspondre à un serveur récepteur, faisant partie du domaine destinataire D-DEST ou d'un domaine tiers, auquel cas le véritable terminal-client destinataire correspond à l'entité B' . Dans la requête d'autorisation REQ, l'entité A référence l'entité B destinataire, via un ou plusieurs identifiants de niveau réseau, transport ou applicatif tels que l'adresse réseau de l'entité B , le nom de domaine auquel appartient l'entité B, une SIP_URI ou Tel_URI désignant l'entité cliente destinataire. De même, l'entité A s'identifie par un ou plusieurs identifiants de niveau réseau, transport ou applicatif tels que son adresse réseau, ou le nom de domaine auquel elle appartient, ou une SIP_URI ou une Tel_URI désignant l'entité cliente expéditrice.

La réalisation de la transaction de numéro N permet à A et B de partager la clé primaire de session K1' , . Cette clé de session permet d'authentifier le message d'établissement d'appel INVITE. En complément, elle peut également servir à authentifier les autres phases de l'appel (requêtes « CANCEL », « ACK », « BYE » ou réponses associées). Elle peut aussi permettre de dériver des clés secondaires pour le chiffrement de flux média. La requête d'autorisation REQ et la réponse d'autorisation RESP sont échangées entre un serveur expéditeur et un serveur destinataire, alors que le message AM est envoyé par un serveur expéditeur ou émetteur vers un serveur récepteur. (c) Interconnexions VolP mode 2 Comme ci-dessus, les entités expéditrice et destinataire sont localisées dans deux réseaux distincts notés D-EXP et D-DEST. L'entité A est un terminal client du domaine D-EXP ou bien un serveur émetteur du domaine expéditeur ou d'un domaine tiers. Si l'entité A est un serveur émetteur, alors le véritable client expéditeur correspond à une entité A' .

Le Serveur d'Autorisation S, est l'un des proxys sortants du domaine expéditeur D-EXP, c'est à dire un serveur expéditeur. Le Serveur d'Autorisation S, dessert les entités A du domaine expéditeur ou des domaines tiers, et autorise les communications avec le domaine destinataire.

L'entité B est l'un des proxys entrants du domaine destinataire DDEST. Cette entité sert, et protège, des entités B' qui sont soit directement des terminaux-client, soit des serveurs récepteurs appartenant au domaine destinataire ou à des domaines tiers. La requête d'autorisation REQ et la réponse d'autorisation RESP sont échangées dans le domaine expéditeur ou entre le domaine émetteur et le domaine expéditeur, alors que le message AM est envoyé par une entité cliente ou un serveur émetteur vers le serveur destinataire. (d) Envoi d'e-mail ou de message instantané IM L'architecture est similaire à celle pour les interconnexions VoIP (mode 1 ou mode 2) en ce qui concerne les entités A, A' , S , B, et B' . Les identifiants utilisés dans la demande de transaction pour désigner les entités A ou A' (respectivement B ou B') sont des adresses e-mail, des adresses IM ou des noms de domaines.

La réalisation de la transaction de numéro N permet à A et B de partager la clé de session primaire KNB, . Cette clé de session est utilisée pour authentifier et assurer l'intégrité du message e-mail ou IM envoyé de A vers B. (e) Etablissement de connexion sécurisée L'entité A envoie une requête d'autorisation au Serveur d'Autorisation Si qui protège les accès à l'entité B avec laquelle l'entité A veut communiquer. La requête d'autorisation comporte les identifiants des entités A et 10 B , sous forme d'adresses réseau ou de transport, ou d'adresses applicatives par rapport au service considéré. La réalisation de la transaction de numéro N permet à A et B de partager la clé de session primaire KNB i . Cette clé de session est ensuite utilisée pour établir une connexion sécurisée (IPSec, TLS, DTLS, ou 15 autre) entre les entités A et B. (f) Application à un service de type DNS/ENUM Cette application du procédé selon l'invention concerne un service de mise en relation, où le Serveur d'Autorisation Si est un serveur de type DNS ou ENUM dans le cas des applications VoIP. Cela permet d'éviter 20 des attaques dans lesquelles une entité VolP appelante revendique un numéro de téléphone qui n'est pas attribué à son réseau ou à son domaine applicatif. Dans ce cas d'application, l'entité A est l'un des proxys sortants du domaine « domaines » et dispose d'un secret partagé avec le Serveur 25 d'Autorisation Si. Avant d'émettre un appel vers l'entité B , l'entité A envoie une requête d'autorisation vers le Serveur d'Autorisation S pour authentifier l'appelant et obtenir une clé secrète d'appel vers B.

Le Serveur d'Autorisation Si est un serveur de type DNS/ENUM qui dispose de secrets partagés KsiA, KsiB avec un certain nombre de domaines, grâce à une phase de mise en relation préalable. Le Serveur d'Autorisation Si joue le rôle de tiers de confiance.

L'entité B est l'un des proxys entrants du domaine « domaine2 » et dispose d'un secret partagé avec le Serveur d'Autorisation Si. La réalisation de la transaction permet à l'entité B de vérifier que l'identifiant d'appelant présenté par l'entité A dans la requête INVITE a bien été authentifié par le Serveur d'Autorisation Si. Elle permet de plus aux entités A et B de disposer d'un secret partagé KNB i pouvant être utilisé pour protéger la suite de leur échange ou des flux média. La mise en oeuvre de l'invention au sein des noeuds du réseau de télécommunications (notamment, les terminaux ou serveurs des entités abonnées au service de communications sécurisées selon l'invention, ou les Serveurs d'Autorisation) peut être réalisée au moyen de composants logiciels et/ou matériels. Les composants logiciels pourront être intégrés à un programme d'ordinateur classique de gestion de noeud de réseau. C'est pourquoi, comme indiqué ci-dessus, la présente invention concerne également un système informatique. Ce système informatique comporte de manière classique une unité centrale de traitement commandant par des signaux une mémoire, ainsi qu'une unité d'entrée et une unité de sortie. De plus, ce système informatique peut être utilisé pour exécuter un programme d'ordinateur comportant des instructions pour la mise en oeuvre du procédé de communications sécurisées selon l'invention. En effet, l'invention vise aussi un programme d'ordinateur téléchargeable depuis un réseau de communication comprenant des instructions pour l'exécution de certaines au moins des étapes d'un procédé de communications sécurisées selon l'invention, lorsqu'il est exécuté sur un ordinateur. Ce programme d'ordinateur peut être stocké sur un support lisible par ordinateur et peut être exécutable par un microprocesseur.

Ce programme peut utiliser n'importe quel langage de programmation, et se présenter sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.

L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une clé USB (« USB flash drive » en anglais) ou un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme d'ordinateur selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. En variante, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour être utilisé dans un dispositif de communications sécurisées selon l'invention.

Claims

REVENDICATIONS1. Procédé de communications sécurisées dans un réseau de télécommunications, ledit réseau comprenant un groupe de serveurs S, (où i =1,2,..., p , et p est un entier strictement positif), dits Serveurs d'Autorisation, ledit procédé comprenant, pour une transaction entre une entité A et une entité B dudit réseau, les étapes suivantes : a) l'entité A envoie à l'un des Serveurs d'Autorisation Si une requête d'autorisation (REQ) dans laquelle l'entité A s'identifie et s'authentifie comme le détenteur d'un identifiant IDA ; b) l'entité A déclare audit Serveur d'Autorisation S, son intention de communiquer avec l'entité B ; le Serveur d'Autorisation S, détermine une clé secrète individuelle Ks,B qu'il partage avec cette entité B; c) le Serveur d'Autorisation Si engendre une clé de session KNB, qui est une fonction à sens unique de ladite clé secrète individuelle Ks,B , et est également fonction d'un entier N , appelé numéro de transaction, affecté à ladite transaction ; le Serveur d'Autorisation S, envoie ladite clé de session KNB, à l'entité A ; d) le Serveur d'Autorisation S, engendre également une valeur 20 de filtrage IDTRN , qui est une fonction dépendant au moins dudit numéro de transaction N de manière non-inversible ; puis il engendre un identifiant de transaction IDTRN,s, , qui est une fonction de ladite valeur de filtrage IDTRN , de ladite clé secrète individuelle Ks,B , et d'un identifiant IDs, de ce Serveur d'Autorisation S, ;e) le Serveur d'Autorisation S, fait parvenir à l'entité B des éléments comprenant au moins ledit identifiant de transaction IDTRN,si ; f) à l'aide de l'identifiant de transaction IDTRN s, reçu lors de ladite étape e), l'entité B : - identifie la valeur de filtrage IDTRN courante au sein d'un ensemble de valeurs de filtrage précalculées par l'entité B et associées à au moins une valeur prévue du numéro de transaction, et - obtient l'identifiant de Serveur d'Autorisation IDsi, et en déduit la clé secrète individuelle KstB correspondante ; et g) l'entité B engendre la clé de session KNS i .
2. Procédé de communications sécurisées selon la revendication 1, caractérisé en ce que l'entité B vérifie, lors de ladite étape f), que ce Serveur d'Autorisation Si n'a pas déjà autorisé pour l'entité B une transaction précédente de même numéro N.
3. Procédé de communications sécurisées selon la revendication 1 ou la revendication 2, caractérisé en ce que l'entité B vérifie, lors de ladite étape f), que la valeur dudit identifiant de transaction IDTRN,s, reçu est cohérente avec la clé secrète individuelle Ks B .
4. Procédé de communications sécurisées selon l'une quelconque des revendications 1 à 3, caractérisé en ce que lesdits Serveurs d'Autorisation utilisent, pour déterminer les numéros de transaction N successifs relatifs à une entité B donnée, un algorithme commun à l'ensemble des Serveurs d'Autorisation dudit groupe.
5. Procédé de communications sécurisées selon la revendication 25 4, caractérisé en ce que le numéro de transaction N déterminé, pour une entité B donnée, par un Serveur d'Autorisation S; quelconque à un instant td donné est une fonction prédéterminée de cet instant td et d'un numéro de référence NB, dont la valeur est un secret partagé par l'entité B et par l'ensemble des Serveurs d'Autorisation S, du groupe.
6. Procédé de communications sécurisées selon la revendication 4, caractérisé en ce que le numéro de transaction N déterminé, pour une entité B donnée, par un Serveur d'Autorisation Si quelconque est une fonction de séquencement prédéterminée du numéro de transaction précédent, et en ce que ce Serveur d'Autorisation Si envoie à l'entité B un message de synchronisation à chaque fois que le Serveur d'Autorisation Si détermine pour l'entité B une valeur du numéro de transaction appartenant à une série de valeurs prédéterminées.
7. Procédé de communications sécurisées selon l'une quelconque des revendications 1 à 6, caractérisé en ce que lesdits éléments que le 15 Serveur d'Autorisation Si fait parvenir à l'entité B lors de ladite étape e) comprennent également une donnée CHECKN si dépendant du numéro de transaction N et déduite, au moyen d'une fonction cryptographique dépendant d'une clé secrète KsjB.check dérivée de ladite clé secrète Ks,8 d'un ensemble d'éléments tirés de ladite requête d'autorisation (REQ) et, 20 optionnellement, du numéro de transaction N.
8. Procédé de communications sécurisées selon l'une quelconque des revendications 1 à 7, caractérisé en ce que l'entité A fait parvenir à l'entité B ledit identifiant IDA de l'entité A, ou un identifiant dérivé ID'A .
9. Procédé de communications sécurisées selon la revendication 25 7 et la revendication 8, caractérisé en ce que :- ledit ensemble d'éléments dont est déduite ladite donnée CHECKNB i comprend l'identifiant IDA de l'entité A ou ledit identifiant dérivé ID'A , et - lors de ladite étape f), l'entité B vérifie, au moyen de ladite clé 5 secrète KstB,check la cohérence entre, d'une part, la donnée CHECKNB reçue conformément à la revendication 7, et d'autre part lesdits éléments comprenant l'identifiant IDA ou l'identifiant dérivé ID'A reçus conformément à la revendication 8.
10. Dispositif, dit Serveur d'Autorisation, pour sécuriser les 10 communications dans un réseau de télécommunications lors d'une transaction entre une entité A et une entité B , comprenant des moyens pour : - identifier et authentifier une entité A détentrice d'un identifiant IDA, 15 - déterminer une clé secrète individuelle KsiB que ledit Serveur d'Autorisation Si (où i =1,2,...,p , et p est un entier strictement positif) partage avec une entité B avec laquelle l'entité A déclare son intention de communiquer, - engendrer une clé de session KNB i et l'envoyer à l'entité A, ladite 20 clé de session KNB l étant une fonction à sens unique de ladite clé secrète individuelle KsiB et étant également fonction d'un entier N , appelé numéro de transaction, affecté à ladite transaction, - engendrer une valeur de filtrage IDTRN , qui est une fonction dépendant au moins dudit numéro de transaction N de manière non-25 inversible,- engendrer un identifiant de transaction IDTRN s, , qui est une fonction de ladite valeur de filtrage IDTRN , de ladite clé secrète individuelle Ks,B , et d'un identifiant IDs, de ce Serveur d'Autorisation S; , et - faire parvenir à ladite entité B des éléments comprenant au moins ledit identifiant de transaction IDTRN,si .
11. Dispositif, dit entité B , de communications sécurisées dans un réseau de télécommunications, caractérisé en ce qu'il comprend des moyens pour, lors d'une transaction impliquant ladite entité B et une entité A : - recevoir des éléments comprenant au moins un identifiant de transaction IDTRN,si engendré par un Serveur d'Autorisation Si (où i =1,2,...,p, et p est un entier strictement positif), ledit identifiant de transaction IDTRN sr étant une fonction d'une valeur de filtrage IDTRN , d'une clé secrète individuelle Ks;B partagée par l'entité B et ledit Serveur d'Autorisation S, , et d'un identifiant IDs, de ce Serveur d'Autorisation S, , et ladite valeur de filtrage IDTRN étant une fonction dépendant au moins, de manière non-inversible, d'un entier N , appelé numéro de transaction, affecté à ladite transaction, - à l'aide dudit identifiant de transaction IDTRN,s, , - identifier la valeur de filtrage IDTRN courante au sein d'un ensemble de valeurs de filtrage précalculées par l'entité B et associées à au moins une valeur prévue du numéro de transaction, et - obtenir l'identifiant de Serveur d'Autorisation IDs1 , et en déduire la clé secrète individuelle KsiB correspondante, et- engendrer une clé de session KNB, qui est, d'une part, fonction dudit numéro de transaction N , et d'autre part une fonction à sens unique de ladite clé secrète individuelle Ks B .
12. Dispositif de communications sécurisées selon la revendication 11, caractérisé en ce qu'il comprend en outre une table de correspondance mettant en relation au moins une valeur prévue du numéro de transaction avec la valeur de filtrage précalculée associée.
13. Dispositif, dit entité A, de communications sécurisées dans un réseau de télécommunications, comprenant des moyens pour, lors 10 d'une transaction impliquant ladite entité A et une entité B : - s'identifier et s'authentifier comme le détenteur d'un identifiant IDA auprès d'un Serveur d'Autorisation Si (où i = 1,2,..., p , et p est un entier strictement positif), - déclarer audit Serveur d'Autorisation Si son intention de 15 communiquer avec une certaine entité B , - recevoir de la part du Serveur d'Autorisation Si une clé de session KNB i , ladite clé de session KNB i étant une fonction à sens unique d'une clé secrète individuelle KsiB partagée par le Serveur d'Autorisation Si et ladite entité B , et étant également fonction d'un entier N , appelé numéro 20 de transaction, affecté à ladite transaction, - recevoir de la part du Serveur d'Autorisation Si un identifiant de transaction IDTRN,si , ledit identifiant de transaction IDTRN.si étant une fonction d'une valeur de filtrage IDTRN , de ladite clé secrète individuelle KsiB , et d'un identifiant IDsi de ce Serveur d'Autorisation Si , et ladite 54 valeur de filtrage IDTRN étant une fonction dépendant au moins, de manière non-inversible, dudit numéro de transaction N , et - envoyer à l'entité B des éléments comprenant au moins ledit identifiant de transaction IDTRN,si .
14. Moyen de stockage de données inamovible, ou partiellement ou totalement amovible, comportant des instructions de code de programme informatique pour l'exécution des étapes d'un procédé de communications sécurisées selon l'une quelconque des revendications 1 à 9.
15. Programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, destiné à être installé dans un dispositif de communications sécurisées selon l'une quelconque des revendications 10 à 13, caractérisé en ce qu'il comprend des instructions pour l'exécution des étapes d'un procédé de de communications sécurisées selon l'une quelconque des revendications 1 à 9, lorsqu'il est exécuté par des moyens de traitement dudit dispositif.