Brevet FR2950767A1 — publié le 20110401

PROCEDE 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 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 repose notamment sur les facteurs suivants : - la faiblesse des protocoles utilisés sur Internet, tels que le protocole SMTP ("Simple Mail Transfer Protocof' 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 usereexpé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 +332abcdefghedomain.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 "domain.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 "voix sur IP" VoIP ("Voice over Internet Protocof' en anglais) 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,...) 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. Une solution bien adaptée aux réseaux comprenant un grand nombre d'usagers consiste à mettre en place un tiers de confiance, communément appelé "Centre de 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 l'aide 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. On connaît par exemple, sous le nom de "Kerberos" (cf. document RFC 4120 de l'IETF), un tel procédé de communications sécurisées entre deux entités A et B abonnées au service. Ce procédé Kerberos comprend essentiellement les étapes suivantes : 1) une entité A s'identifie et s'authentifie comme le détenteur d'un identifiant ID4 auprès dudit Serveur d'Autorisation S (après s'être adressée à un Serveur d'Authentification distinct du Serveur d'Autorisation S) ; le Serveur d'Autorisation S détermine la clé secrète KsA qu'il partage avec cette entité A ; 2) l'entité A déclare au Serveur d'Autorisation S son intention de communiquer avec une certaine entité B ; le Serveur d'Autorisation S détermine la clé secrète KsB qu'il partage avec cette entité B ; 3) le Serveur d'Autorisation S engendre une clé de session KAB , et l'envoie à l'entité A, chiffrée au moyen de ladite clé secrète KsA 4) le Serveur d'Autorisation S engendre également un "ticket" T comprenant au moins ledit identifiant ID,, de l'entité A et ladite clé de session KAB ; le Serveur d'Autorisation S envoie à l'entité A une donnée CHECKA résultant du chiffrement dudit ticket T au moyen de ladite clé secrète KsB ; 5) l'entité A déchiffre la clé de session KAB au moyen de sa clé secrète KsA , et envoie à l'entité B , d'une part, la donnée CHECKA (telle que reçue précédemment par l'entité A de la part du Serveur d'Autorisation S ), et d'autre part une donnée VA résultant du chiffrement, avec la clé de session KAB , d'un ensemble d'éléments comprenant au moins son identifiant IDA ; et 6) l'entité B déchiffre le ticket T au moyen de sa clé secrète KsB ; la clé de session KAB lui permet ensuite de déchiffrer l'identifiant IDA de l'entité A ; l'entité B vérifie que cet identifiant est bien le même que celui contenu dans le ticket T ; si l'entité B approuve la transaction, elle en informe l'entité A. 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 KAB. Comme autre exemple, si l'entité B attend un document de la part de 25 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 K4B (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). Le procédé Kerberos prévoit donc la transmission de la clé de session, d'une part, directement à l'entité A, et d'autre part indirectement (en passant par l'entité A) à l'entité B ; cette dernière n'a donc pas besoin de communiquer avec le Serveur d'Autorisation S pour obtenir cette clé de session. Le procédé Kerberos permet en outre avantageusement à l'entité B de vérifier l'identité de l'entité A ; cette vérification empêche une attaque du type "phishing", dans laquelle un attaquant s'identifierait d'abord sous sa véritable identité auprès du Serveur d'Autorisation S , afin d'obtenir une autorisation de transaction de la part ce dernier, puis sous une identité usurpée auprès de l'entité B (par exemple en se faisant passer pour la banque de l'entité B afin d'obtenir des informations bancaires confidentielles). Le procédé Kerberos présente toutefois l'inconvénient que l'entité B est sensible aux attaques par inondation. Retournons en effet à l'étape n° 6 ci-dessus : l'entité B doit, avant de pouvoir identifier une attaque, réaliser deux déchiffrements plus une vérification d'égalité. Or les déchiffrements sont des opérations lourdes en termes de calcul, de sorte qu'un attaquant peut submerger l'entité B en lui envoyant de manière répétée des données CHECKA et SA arbitraires. Pire, un attaquant pourrait envoyer à l'entité B des données CHECKA et (5A que l'attaquant a préalablement lues ou interceptées lors d'une transaction initiée par une entité A légitime (attaques par rejeu) : dans ce cas, l'attaquant inonde non seulement l'entité B , mais également cette entité A légitime qui reçoit de manière répétée des messages de confirmation de la part de l'entité B ; en fait, la "Version 5" du procédé Kerberos protège les entités A légitimes des attaques par inondation en préconisant l'insertion d'un horodatage dans la donnée 8A, mais cela alourdit encore la tâche de l'entité B qui doit vérifier que les données (SA successives qu'elle reçoit d'une certaine entité A présentent toutes un horodatage différent, ce qui ne fait qu'aggraver l'inondation de l'entité B . La présente invention concerne donc un procédé de communications sécurisées dans un réseau de télécommunications, dans lequel une transaction entre une entité A et une entité B dudit réseau comprend 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 de communiquer avec une certaine entité B ; le Serveur 20 d'Autorisation S détermine une clé secrète KSB qu'il partage avec cette entité B ; et c) le Serveur d'Autorisation S engendre une clé de session KAB,N et l'envoie à l'entité A. Ledit procédé est remarquable en ce que ladite clé de session KAB,N est 25 une fonction à sens unique de ladite clé secrète KSB et est également fonction d'un entier N, appelé numéro de transaction, affecté à ladite transaction, et en ce qu'il comprend en outre les étapes suivantes : d) le Serveur d'Autorisation S engendre également un identifiant de transaction IDTRN , qui est une fonction dépendant au moins dudit numéro de transaction N de manière non-inversible, et envoie à l'entité A ledit identifiant de transaction IDTRN ; e) l'entité A envoie à l'entité B des éléments comprenant au moins l'identifiant de transaction IDTRN ; et f) l'entité B vérifie au moins que la valeur de l'identifiant de transaction IDTRN reçue figure au sein d'un ensemble de valeurs pré-calculées correspondant à au moins une valeur 10 prévue du numéro de transaction ; si c'est le cas, l'entité B en déduit d'abord la valeur courante du numéro de transaction N, et ensuite la valeur de la clé de session KAB,N . II est clair que l'étape b) n'est pas nécessairement postérieure à l'étape a). De même, l'étape d) n'est pas nécessairement postérieure à 15 l'étape c). On notera que l'évaluation de l'authenticité de l'entité A peut être effectuée par tout moyen d'authentification connu. De plus, elle peut être réalisée en s'adressant préalablement à un Serveur d'Authentification distinct du Serveur d'Autorisation S (de manière analogue au procédé 20 Kerberos). On notera également qu'en pratique, et pour des besoins de séparation cryptographique, ce n'est pas nécessairement la clé (primaire) de session KAB N qui sera utilisée pour le chiffrement des données, mais plutôt une clé dérivée de K B N . Dans un souci de simplification, les clés 25 dérivées d'une clé primaire ne seront pas systématiquement explicitées, mais, selon l'état de l'art, l'opération de dérivation ou de diversification sera implicite dès lors qu'un même secret partagé sert à plus d'une seule fonction cryptographique. Selon la présente invention, contrairement au procédé Kerberos, le Serveur d'Autorisation S fournit, pour chaque nouvelle transaction repérée par son numéro N, la clé de session KAB.N à l'entité A, mais pas à l'entité B. En effet, selon l'invention, l'entité B possède des 5 moyens pour calculer elle-même cette clé de session à partir de la clé secrète KSB qu'elle partage avec le Serveur d'Autorisation S , et du numéro de transaction courant N, que l'entité B détermine après réception de l'identifiant de transaction IDTRN . Grâce à l'invention, on peut bénéficier des avantages, mentionnés 10 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 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é. 15 De plus, l'invention supprime avantageusement l'inconvénient du procédé Kerberos, mentionné ci-dessus, concernant la sensibilité de l'entité B aux attaques par inondation. Selon l'invention, l'entité B calcule la valeur de l'identifiant de transaction IDTRN pour au moins une valeur N du numéro de transaction, cette valeur étant prévue pour faire suite à 20 une valeur utilisée dans une transaction précédente. L'identifiant de transaction IDTRN est transmis en clair de l'entité A vers l'entité B , ce qui impose de modifier sa valeur à chaque transaction. Vu les risques de désordre à l'arrivée pouvant se produire lorsque plusieurs transactions ont été initiées sur une courte période par une ou plusieurs entité(s) A pour 25 la même entité B , il est en fait préférable que l'entité B calcule la valeur de l'identifiant de transaction IDTRN pour une séquence prédéterminée de plusieurs valeurs de l'entier N, et que, après réception d'un certain identifiant de transaction IDTRN , elle identifie par scrutation dans cet ensemble de valeurs de IDTRN à quel numéro de transaction N correspond l'identifiant de transaction reçu. On rappelle à cet égard 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 5 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, l'entité B détecte facilement une attaque (c'est-à-dire en peu d'opérations de calcul) lorsqu'elle constate qu'un 10 prétendu identifiant de transaction IDTRN reçu ne figure pas au sein dudit ensemble de valeurs pré-calculées (comme expliqué ci-dessous, 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 15 acceptable, même si la fonction IDTRN(N) est rendue publique). On protège ainsi les entités abonnées au service de communications sécurisées contre les attaques par inondation. Un avantage supplémentaire de l'invention par rapport au procédé Kerberos se situe dans la taille (en nombre de bits) des messages 20 protocolaires. En effet, selon le procédé Kerberos, l'entité A envoie à l'entité B la donnée CHECKS obtenue par chiffrement du ticket T ; or ce ticket T est quant à lui nécessairement de grande taille puisqu'il comprend, notamment, la clé de session K`lB. Cela peut poser des problèmes dans le cas de certaines architectures utilisant un mode de 25 transport non-connecté (par exemple, celles utilisant le protocole de signalisation SIP) dans lesquelles la taille nominale des messages de signalisation empêche parfois l'insertion de données de grande taille. En revanche, selon la présente invention, l'entité A n'a avantageusement pas à envoyer un représentant de la clé de session KAB N à l'entité B . Par ailleurs, l'identifiant de transaction 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. On notera enfin que, lorsque la confidentialité des échanges entre le Serveur d'Autorisation S et l'entité A n'est pas assurée par le protocole de transport sous-jacent, le Serveur d'Autorisation S envoie à l'entité A, lors des étapes c) et d) ci-dessus, ladite clé de session KAB,N et ledit identifiant de transaction IDTRN de préférence chiffrés au moyen d'une clé secrète KS4 partagée entre le serveur d'Autorisation S et l'entité A (ou d'une clé dérivée de cette clé secrète KSA ), de manière analogue à la transmission de la clé de session K4B du Serveur d'Autorisation S à l'entité A dans le procédé Kerberos. Dans ce cas, lors 15 de ladite étape e) ci-dessus, l'entité A utilise évidemment sa clé secrète KSA pour déchiffrer la clé de session KAB N et l'identifiant de transaction IDTRN . Selon des caractéristiques particulières, tout ou partie desdits éléments envoyés par l'entité A à l'entité B lors de ladite étape e) sont 20 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. 25 Selon des caractéristiques encore plus particulières, cette protection en intégrité est réalisée au moyen de ladite clé de session KAB N ou d'une clé dérivée de cette clé de session KAB,N. Grâce à ces dispositions, l'entité B pourra s'assurer que l'entité A dispose bien de la clé de session KAB N associée à la transaction courante. Selon d'autres caractéristiques particulières, lors de ladite étape d), le Serveur d'Autorisation S envoie en outre à l'entité A une donnée CHECKA N déduite, au moyen d'une fonction cryptographique dépendant d'une clé secrète KsB,N dérivée de ladite clé secrète KsB et du numéro de transaction N, d'un ensemble d'éléments tirés de ladite requête d'autorisation. Grâce à ces dispositions, le Serveur d'Autorisation S peut prouver à 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, lesdits éléments envoyés par l'entité A à l'entité B lors de ladite étape e) comprennent un identifiant dérivé ID'A de l'entité A, identique ou non audit identifiant IDA. Grâce à ces dispositions, l'entité B est informée de l'identité dérivée ID'A 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 CHECKA N comprend ledit identifiant dérivé ID'A de l'entité A, - lesdits éléments envoyés par l'entité A à l'entité B lors de ladite étape e) comprennent également ladite donnée CHECKA N , et - lors de ladite étape f), l'entité B vérifie, au moyen de ladite clé secrète KsB.N , la cohérence entre, d'une part, la donnée CHECKA N, et d'autre part lesdits éléments comprenant 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é ID'A ("anti-phishing"). Le mécanisme utilisé dans ce mode de réalisation de l'invention est donc équivalent au mécanisme utilisé dans Kerberos par déchiffrement du ticket T. En revanche, dans Kerberos, l'entité A connaît la valeur du ticket T et le résultat du chiffrement du ticket T au moyen de la clé secrète KsB ; si donc l'entité A est malhonnête (et dispose de moyens de calcul puissants), elle pourrait en déduire KsB , par force brute ou un autre moyen cryptographique (l'algorithme de chiffrement étant habituellement public). L'invention, dans ce mode de réalisation, résout ce problème car, 15 s'il est vrai que l'entité A connaît CHECKA N et les éléments dont le chiffrement produit CHECKA N , il ne lui servirait à rien d'en déduire la valeur de la clé secrète KsB,N , car il est impossible à partir de cette dernière de calculer la clé secrète "mère" KsB , ou bien KsB,N+1 (ou même le numéro de transaction courant N). 20 On notera en outre que cette quantité CHECKA N est, contrairement à la quantité CHECKA du procédé Kerberos, de taille modeste puisqu'elle ne résulte pas obligatoirement du chiffrement d'une clé secrète. Corrélativement, l'invention concerne divers dispositifs. 25 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 KSB que ledit Serveur d'Autorisation S partage avec une entité B avec laquelle l'entité A déclare son intention de communiquer, - engendrer une clé de session KAB,N et l'envoyer à l'entité A. Ledit dispositif est remarquable en ce que, ladite clé de session KAB N étant une fonction à sens unique de ladite clé secrète KSB et étant également fonction d'un entier N, appelé numéro de transaction, affecté à ladite transaction, il comprend en outre des moyens pour : - engendrer un identifiant de transaction IDTRN , qui est une fonction dépendant au moins dudit numéro de transaction N de manière non-inversible, et - envoyer à l'entité A ledit identifiant de transaction IDTRN . Elle concerne aussi, deuxiè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 , - déclarer audit Serveur d'Autorisation S son intention de communiquer avec une certaine entité B , et - recevoir de la part du Serveur d'Autorisation S une clé de session 25 Ledit dispositif est remarquable en ce que, ladite clé de session KAB N étant une fonction à sens unique d'une clé secrète KSB partagée par le Serveur d'Autorisation S et l'entité B et étant également fonction d'un entier N, appelé numéro de transaction, affecté à ladite transaction, il comprend en outre des moyens pour : - recevoir de la part du Serveur d'Autorisation S un identifiant de transaction IDTRN , qui est une fonction dépendant au moins dudit numéro de transaction N de manière non-inversible, et - envoyer à l'entité B des éléments comprenant au moins ledit identifiant de transaction IDTRN . Elle concerne aussi, troisièmement, un dispositif, dit entité B , de communications sécurisées dans un réseau de télécommunications, remarquable en ce qu'il comprend des moyens pour, lors d'une transaction impliquant ladite entité B et une entité A : - recevoir de la part de l'entité A des éléments comprenant au moins un identifiant de transaction IDTRN , ledit identifiant de transaction 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, - vérifier que la valeur de l'identifiant de transaction IDTRN reçue figure au sein d'un ensemble de valeurs pré-calculées correspondant à au moins une valeur prévue du numéro de transaction, - en déduire la valeur courante d'un entier N, appelé numéro de transaction, affecté à ladite transaction, et - en déduire une clé de session KAB,N qui est, d'une part, une fonction à sens unique d'une clé secrète KSB partagée par le Serveur d'Autorisation S et l'entité B, et d'autre part fonction dudit numéro de transaction N. L'invention concerne également un dispositif cumulant les moyens des deux derniers dispositifs décrits succinctement ci-dessus (c'est-à-dire pouvant se comporter, selon les circonstances, soit comme une entité A, soit comme une entité B ). Les avantages offerts par ces dispositifs sont essentiellement les 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. 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, et - la figure 2 représente schématiquement les étapes d'un procédé de communications sécurisées selon un mode de réalisation de réalisation. 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ée 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 à A ; de même, l'entité B peut jouer le rôle de serveur ou relais pour une entité B' connectée à B. L'entité S est un "Serveur d'Autorisation" (pouvant, naturellement, être composé en pratique de plusieurs serveurs physiques). II permet à toute entité abonnée A de s'adresser de manière sécurisée à toute entité abonnée B ; de plus, il protège l'entité B contre la réception de messages indésirables. Suivant les applications et les scénarios de déploiement, l'entité S peut être indépendante des domaines applicatifs ou réseaux auxquels appartiennent les entités A et B , ou bien l'entité S peut appartenir au même domaine applicatif ou réseau que l'entité A et/ou que l'entité B. Le Serveur d'Autorisation S prend en compte une séquence de valeurs entières, dites "numéros de transaction", séparément pour chaque entité B abonnée au service de communications sécurisées. Le numéro de transaction N permet d'ordonner les transactions. A l'initialisation du procédé, les entités S et B se mettent d'accord sur un numéro de transaction initial No , 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 S et B. Quoiqu'il en soit, le numéro de transaction n'est jamais transmis en clair 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 d'une entité B. 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. 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 S détermine une clé secrète à long terme KsA qu'il partage avec cette entité A. Cette clé secrète à long terme KsA 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 S. De même, il existe un secret partagé à long terme KsB entre les entités S et B. Cette clé secrète à long terme KsB 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 (indirectement) entre S et B. Pour toute transaction de numéro N , les entités S et B sont capables d'engendrer indépendamment, en utilisant des algorithmes pouvant être publics : - un identifiant de transaction IDTRN , qui doit dépendre au moins de N et être engendré au moyen d'un algorithme tel que, si l'on connaît une ou plusieurs valeurs IDTRN préalablement reçues par l'entité B , on ne peut pas en déduire la valeur courante de N , ou une valeur IDTRN+r (i > 0) ; et - la clé (primaire) de session KAB,N utilisée entre les entités A et B pour la transaction courante ; cette clé de session doit dépendre au moins de N et de KSB , et être engendrée au moyen d'un algorithme tel que, même si l'on connaît la valeur de KAB,N et la valeur de N, on ne peut pas en déduire la valeur de KSB . De manière classique, la clé primaire de session (ou de transaction) KAB N 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 B. La figure 2 représente schématiquement les étapes d'un mode de réalisation du procédé selon l'invention. Dans le présent mode de réalisation, on suppose 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 El, une nouvelle transaction est authentifiée, et autorisée, par un Serveur d'Autorisation S. Plus précisément, lors d'une sous-étape E11, l'entité A initie une transaction en envoyant une requête d'autorisation REQ au Serveur d'Autorisation S , avec qui elle partage une clé secrète KSA. Cette requête d'autorisation REQ contient au moins des éléments 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 permettant d'identifier la transaction entre les entités A et S , - des informations caractérisant le message MES ou permettant d'identifier l'entité A ou l'entité B , et - une valeur aléatoire servant de témoin de transaction entre A et S. 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 MAC 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 KS.A,MACI dérivée de la clé secrète KsA . 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 S ; - 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 S 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 E12, 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 besoin, le Serveur d'Autorisation S détermine l'identité de la, ou les, client(s) destinataire(s) B (ou B' ). Si la transaction est autorisée, le Serveur d'Autorisation S transmet à l'entité A, lors d'une étape E2, une réponse d'autorisation RESP contenant au moins la clé de session KAB N et l'identifiant de transaction IDTRN . On notera que : - lorsque la confidentialité des échanges entre le Serveur d'Autorisation S et l'entité A n'est pas assurée par le protocole de transport sous-jacent, le Serveur d'Autorisation S envoie à l'entité A la clé de session KAB,N de préférence chiffrée au moyen de ladite clé secrète KsA ou d'une clé dérivée de cette clé secrète KsA ; - l'identifiant de transaction IDTRN peut être passé en clair, mais si un attaquant était capable de lire sa valeur, il pourrait envoyer à l'entité B un ou plusieurs messages invalides avant que l'entité A n'émette le message légitime ; pour pouvoir détecter une telle attaque, l'entité B devrait procéder à des vérifications supplémentaires (puisque la valeur de l'identifiant de transaction IDTRN ne serait pas une sécurité suffisante), ce qui exposerait l'entité B à un risque d'attaque par inondation ; aussi, dans le cas où la confidentialité des échanges entre le Serveur d'Autorisation S et l'entité A n'est pas assurée par le protocole de transport sous-jacent, le Serveur d'Autorisation S envoie à l'entité A l'identifiant de transaction IDTRN de préférence chiffré au moyen de la clé secrète KsA ou d'une clé secrète dérivée de cette clé secrète KsA . La réponse d'autorisation RESP peut contenir en outre : - aux fins de vérification, un sous-ensemble des informations contenues dans la requête d'autorisation REQ ; en particulier, si cette dernière contenait un témoin de transaction, alors ce témoin doit de préférence être inclus dans la réponse d'autorisation RESP ; et - une donnée CHECKA N déduite, au moyen d'une fonction cryptographique dépendant d'une clé secrète KSB,N dérivée de ladite clé secrète Kse et du numéro de transaction N, d'un ensemble d'éléments tirés de la requête d'autorisation REQ ainsi que, de préférence, d'un aléa engendré simultanément, lors de chaque transaction, par le Serveur d'Autorisation S et l'entité B (cet aléa empêche une entité A malveillante de trouver la clé secrète KsB,N par inversion de la donnée CHECKA,N ). On notera qu'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, comme éventuellement dans d'autres cas, lesdits éléments tirés de la requête d'autorisation REQ ne contiendront pas l'identifiant IDA de l'entité A. Dans le cas contraire, le Serveur d'Autorisation S inclura de préférence l'identifiant dérivé ID'A de l'entité A dans les éléments dont le chiffrement fournit la donnée CHECKA,N . Enfin, lorsque l'intégrité des échanges entre A et S 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 MAC 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 KSA,MAC2 (égale ou non à ladite clé secrète KsA,MACI) dérivée de la clé secrète KsA . Lors d'une étape E3, l'entité A reçoit la réponse d'autorisation 20 RESP de la part du Serveur d'Autorisation S , et envoie un "message authentifié" AM à l'entité B. Plus précisément, lors d'une sous-étape E31, après réception de la réponse d'autorisation RESP, l'entité A vérifie que : - les informations de vérification contenues dans la réponse d'autorisation 25 RESP correspondent bien à une requête d'autorisation REQ précédemment émise par l'entité A, et - le code MAC utilisant la clé secrète KSA,MAC2 , Si présent, est valide. Si les vérifications sont positives, lors d'une sous-étape E32, l'entité A extrait de la réponse d'autorisation RESP la clé de session KAB,,v , l'identifiant de transaction IDTRN , et, le cas échéant, la donnée CHECKA N . L'entité A envoie alors à l'entité B un "message authentifié" AM comprenant le message original MES, l'identifiant de transaction IDTRN , et, le cas échéant, la donnée CHECKA,.N . 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 MAC ,5,4,N 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 KAB N ou une clé secrète KAB,N,MAC dérivée de la clé de session KAB,N . Dans le cas où l'entité A n'est pas autorisée, ou ne souhaite pas rester anonyme vis-à-vis de l'entité B , l'entité A inclura son identifiant dérivé ID' 4 dans le message authentifié AM. Cet identifiant dérivé ID' 4 pourra naturellement être lui aussi inclus dans lesdits éléments servant de base au calcul du code MAC Ô'A,N . 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, sous réserve que cette entité autorisée ait été identifiée dans les informations contenues dans la requête d'autorisation REQ. 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 E41, après réception d'un message authentifié AM, l'entité B vérifie que l'élément IDTRN reçu correspond bien à un identifiant de transaction attendu. De préférence, l'entité B pré-calcule des valeurs IDTRN pour une séquence prédéterminée de valeurs de N, après la fin de la transaction précédente et donc avant la réception d'un nouveau message authentifié AM. Si la valeur IDTRN reçue est valide, l'entité B en déduit la valeur courante N du numéro de transaction, et récupère ou calcule la clé de session KAB.N , ainsi que, optionnellement, ladite clé secrète KSB,N et/ou ladite clé secrète KAB,N.MAC associées à cette transaction. L'entité B vérifie ensuite optionnellement que : - les informations que l'entité B a reçues sont cohérentes avec le code MAC b'A N (si présent) et la clé de session KAB N ou la clé secrète KAB,N,MAC , et/ou - les informations que l'entité B a reçues sont cohérentes avec la donnée CHECKA N (Si présente) et la clé secrète KsB,N . Notamment, l'entité B vérifie, le cas échéant, au moyen de ladite clé secrète Ks8 N , la cohérence entre, d'une part, la donnée CHECK.4,N et d'autre part lesdits éléments comprenant l'identifiant dérivé ID'A reçus de l'entité A. Enfin, si toutes les vérifications sont positives, lors d'une sous- étape E42, 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' . 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 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 S font partie du réseau d'un même opérateur. Le Serveur d'Autorisation S 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 au réseau. La requête d'autorisation envoyée par l'entité A permet au Serveur d'Autorisation S de l'authentifier 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 AM correspond à la requête INVITE. (b) Interconnexions VolP mode 1 Dans ce mode de réalisation, les entités expéditrice et destinatrice 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 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 sert 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, l'entité A référence l'entité B destinatrice, 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 destinatrice. 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 KAB N . 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 VoIP mode 2 Comme ci-dessus, les entités expéditrice et destinatrice 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 sert 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 clients, 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 K,4B,N . 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 S 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 Kl4B N . Cette clé de session est ensuite utilisée pour établir une connexion sécurisée (IPSec, TLS, 15 DTLS,...) entre les entités A et B. (f) Application à un service de type DNS/ENUM Le principe ici est d'appliquer le procédé selon l'invention à un service de mise en relation, où le Serveur d'Autorisation S est un serveur de type DNS ou ENUM dans le cas des applications VoIP. Cela permet 20 d'éviter des attaques dans lesquelles une entité VoIP appelante revendique un numéro de téléphone qui n'est pas attribué à son réseau ou domaine applicatif. Dans ce cas d'application, l'entité A est l'un des proxys sortants du domaine "domainel" et dispose d'un secret partagé avec le Serveur 25 d'Autorisation S. 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 S est un serveur de type DNS/ENUM qui dispose de secrets partagés KsA , KsB avec un certain nombre de domaines, via une phase de mise en relation préalable. Le Serveur d'Autorisation S 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 S. 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 S. Elle permet de plus aux entités A et B de disposer d'un secret partagé KAB,N pouvant être utilisé pour protéger la suite de l'é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 telles que A ou B abonnées au service de communications sécurisées selon l'invention, ou le Serveur d'Autorisation S) 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 10 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 15 ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette ("floppy disc" 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 20 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 25 utilisé dans un dispositif de communications sécurisées selon l'invention. REVENDICATIONS1. Procédé de communications sécurisées dans un réseau de télécommunications, dans lequel une transaction entre une entité A et une entité B dudit réseau comprend les étapes suivantes : a) l'entité A envoie à un Serveur d'Autorisation S 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 au Serveur d'Autorisation S son intention 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 ; et c) le Serveur d'Autorisation S engendre une clé de session KAB,N et l'envoie à l'entité A ; ledit procédé étant caractérisé en ce que ladite clé de session KAB,N est 15 une fonction à sens unique de ladite clé secrète KSB et est également fonction d'un entier N, appelé numéro de transaction, affecté à ladite transaction, et en ce qu'il comprend en outre les étapes suivantes : d) le Serveur d'Autorisation S engendre également un identifiant de transaction IDTRN , qui est une fonction 20 dépendant au moins dudit numéro de transaction N de manière non-inversible, et envoie à l'entité A ledit identifiant de transaction IDTRN ; e) l'entité A envoie à l'entité B des éléments comprenant au moins l'identifiant de transaction IDTRN ; et 25 f) l'entité B vérifie au moins que la valeur de l'identifiant de transaction IDTRN reçue figure au sein d'un ensemble de valeurs pré-calculées correspondant à au moins une valeurprévue du numéro de transaction ; si c'est le cas, l'entité B en déduit d'abord la valeur courante du numéro de transaction N, et ensuite la valeur de la clé de session KAB N . 2. Procédé de communications sécurisées selon la revendication 1, caractérisé en ce que tout ou partie desdits éléments envoyés par l'entité A à l'entité B lors de ladite étape e) sont protégés en intégrité. 3. Procédé de communications sécurisées selon la revendication 2, caractérisé en ce que cette protection en intégrité est réalisée au 10 moyen de ladite clé de session K4B N ou d'une clé dérivée de cette clé de session KAB,N . 4. Procédé de communications sécurisées selon l'une quelconque des revendications 1 à 3, caractérisé en ce que, lors de ladite étape d), le Serveur d'Autorisation S envoie en outre à l'entité A une donnée 15 CHECKA N déduite, au moyen d'une fonction cryptographique dépendant d'une clé secrète KsB,N dérivée de ladite clé secrète KsB et du numéro de transaction N, d'un ensemble d'éléments tirés de ladite requête d'autorisation (REQ). 5. Procédé de communications sécurisées selon l'une quelconque 20 des revendications 1 à 4, caractérisé en ce que lesdits éléments envoyés par l'entité A à l'entité B lors de ladite étape e) comprennent un identifiant dérivé ID'A de l'entité A, identique ou non audit identifiant ID4. 6. Procédé de communications sécurisées selon la revendication 25 4 et la revendication 5, caractérisé en ce que :- ledit ensemble d'éléments dont est déduite ladite donnée CHECKA N comprend ledit identifiant dérivé ID'A de l'entité A , - lesdits éléments envoyés par l'entité A à l'entité B lors de ladite étape e) comprennent également ladite donnée CHECK4 N , et - lors de ladite étape f), l'entité B vérifie, au moyen de ladite clé secrète KsB.N , la cohérence entre, d'une part, la donnée CHECKA N , et d'autre part lesdits éléments comprenant l'identifiant dérivé ID' a reçus de l'entité A conformément à la revendication 5. 7. 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 ID4 , - déterminer une clé secrète KsB que ledit Serveur d'Autorisation S partage avec une entité B avec laquelle l'entité A déclare son intention de communiquer, - engendrer une clé de session KAB,N et l'envoyer à l'entité A, caractérisé en ce que, ladite clé de session KAB N étant une fonction a sens unique de ladite clé secrète KsB et étant également fonction d'un entier N, appelé numéro de transaction, affecté à ladite transaction, il comprend en outre des moyens pour : - engendrer un identifiant de transaction IDTRN , qui est une fonction dépendant au moins dudit numéro de transaction N de manière non-inversible, et - envoyer à l'entité A ledit identifiant de transaction IDTRN . 8. 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 , - déclarer audit Serveur d'Autorisation S son intention de communiquer avec une certaine entité B , et - recevoir de la part du Serveur d'Autorisation S une clé de session KAB, N caractérisé en ce que, ladite clé de session KAB N étant une fonction à sens unique d'une clé secrète KSB partagée par le Serveur d'Autorisation S et l'entité B et étant également fonction d'un entier N, appelé numéro de transaction, affecté à ladite transaction, il comprend en outre des moyens pour : - recevoir de la part du Serveur d'Autorisation S un identifiant de transaction IDTRN , qui est une fonction dépendant au moins dudit numéro de transaction N de manière non-inversible, et - envoyer à l'entité B des éléments comprenant au moins ledit identifiant de transaction IDTRN . 9. 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 de la part de l'entité A des éléments comprenant au moins un 25 identifiant de transaction IDTRN , ledit identifiant de transaction 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,- vérifier que la valeur de l'identifiant de transaction IDTRN reçue figure au sein d'un ensemble de valeurs pré-calculées correspondant à au moins une valeur prévue du numéro de transaction, - en déduire la valeur courante d'un entier N, appelé numéro de transaction, affecté à ladite transaction, et - en déduire une clé de session KAB,N qui est, d'une part, une fonction à sens unique d'une clé secrète KSB partagée par le Serveur d'Autorisation S et l'entité B, et d'autre part fonction dudit numéro de transaction N. 10. Dispositif de communications sécurisées dans un réseau de 10 télécommunications, caractérisé en ce qu'il comprend des moyens selon la revendication 8 et selon la revendication 9. 11. Moyen de stockage de données inamovible, ou partiellement ou totalement amovible, comportant des instructions de code de programme informatique pour la mise en oeuvre desdits moyens compris 15 dans un dispositif de communications sécurisées selon l'une quelconque des revendications 7 à 10. 12. 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, caractérisé en ce qu'il comprend des 20 instructions pour la mise en oeuvre desdits moyens compris dans un dispositif de communications sécurisées selon l'une quelconque des revendications 7 à 10.