FR2950767A1 - Entities e.g. web server, communication method for e.g. Internet, involves deducing current value of transaction number and value of session key, if value of transaction identifier does not correspond to expected value of transaction number - Google Patents

Entities e.g. web server, communication method for e.g. Internet, involves deducing current value of transaction number and value of session key, if value of transaction identifier does not correspond to expected value of transaction number Download PDF

Info

Publication number
FR2950767A1
FR2950767A1 FR0956821A FR0956821A FR2950767A1 FR 2950767 A1 FR2950767 A1 FR 2950767A1 FR 0956821 A FR0956821 A FR 0956821A FR 0956821 A FR0956821 A FR 0956821A FR 2950767 A1 FR2950767 A1 FR 2950767A1
Authority
FR
France
Prior art keywords
entity
transaction
authorization server
identifier
value
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
FR0956821A
Other languages
French (fr)
Inventor
Patrick Battistello
Henri Gilbert
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Priority to FR0956821A priority Critical patent/FR2950767A1/en
Priority to US13/497,571 priority patent/US8683194B2/en
Priority to PCT/FR2010/052028 priority patent/WO2011039460A2/en
Priority to EP10773652.2A priority patent/EP2484084B1/en
Priority to CN201080054106.XA priority patent/CN102668497B/en
Publication of FR2950767A1 publication Critical patent/FR2950767A1/en
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H04L9/0844—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols with user authentication or key authentication, e.g. ElGamal, MTI, MQV-Menezes-Qu-Vanstone protocol or Diffie-Hellman protocols using implicitly-certified keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/041—Key generation or derivation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0431—Key distribution or pre-distribution; Key agreement
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0433—Key management protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer And Data Communications (AREA)

Abstract

The method involves generating transaction identifier by an authorization server (S), and sending the transaction identifier to an entity (A). Elements containing the transaction identifier are sent to another entity (B) by the former entity. A determination is made to find whether the value of the transaction identifier corresponds to expected value of transaction number. Current value of the transaction number and the value of the session key are deduced, if the value of the transaction identifier does not correspond to expected value of transaction number. Independent claims are also included for the following: (1) an authorization server for securely communicating between entities in a telecommunication network, comprising an identifying unit (2) a fixed data storing unit comprising computer program code instructions to perform a method for securely communicating between entities (3) a downloaded computer program comprising instructions to perform a method for securely communicating between entities.

Description

PROCEDE DE COMMUNICATIONS SECURISEES DANS UN RESEAU DE TELECOMMUNICATIONS METHOD FOR SECURE COMMUNICATIONS IN A TELECOMMUNICATIONS NETWORK

La présente invention concerne la sécurisation des communications dans un réseau de télécommunications. The present invention relates to securing communications in a telecommunications network.

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. Telecommunications networks, such as the Internet, transmit data between different network entities, such as a web server or e-mail server, via a common infrastructure. The invention can be applied for example to the secure access of a network entity to a service platform.

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. The invention can also be applied, for example, to the transmission of an "original message" from a network entity to one or more other network entity (s) (by "original message" here means a set any information, for example an e-mail or a request for VoIP call initiation or an "instant message"). It will generally be said that an original message is sent by a "sending client" attached to a "sender" domain and connected to a "sender" domain, to a "recipient client" attached to a "recipient" domain and connected to a "receiver" domain (in the context of the present invention, it will be said that an entity is "attached" to a network domain when this entity has a service and / or logical and / or administrative link with this domain; case of the electronic mail, the logical address corresponds to the address "email"). The sender domain may or may not be separate from the sender domain, and the receiving domain may or may not be distinct from the recipient domain; this distinction between domains is useful, for example, when a sender domain relays to a recipient client a message sent by a roaming sender client that is connected to this sender domain but is not attached to the sender domain.

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. As is well known, telecommunications networks are attacked by professional, administrative or individual targets. A common attack nowadays is to send as many recipients as possible unwanted messages that they have not solicited, such as "Spam" for e-mails or "Spits" for Internet phone calls. . The term "undesirable" is taken in a broad sense and applies both to the identity of the sender of the message, which may be authentic or falsified, and to the content of the 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. The possibility of Spam-type attacks is mainly due to the following factors: - the weakness of the protocols used on the Internet, such as the Simple Mail Transfer Protocol (SMTP), which is the most used for the transfer of electronic mail and which not including any authentication functions of the sender of a mail - the increase in the power of computers that can send unwanted messages in bulk automatically over a very short period of time - and - the increase the number of networks with access to the Internet and the connectivity between these networks, which presents a very large number of targets to attackers who can shelter behind relatively permissive networks or out of the legal or administrative scope of the target networks. moreover, it is not easy, for a transmitter domain of the type "issuer.fr", to determine if an address of the type usereexpéditeur.fr provided by a customer ex Itinerant sender connected to this sender domain is valid, ie if the address of this client is actually assigned in the domain "sender.fr" and if this client has the rights to send a message from this address: indeed, the sender domain does not manage the identities, that is to say the logical addresses of the type "sender.fr". This control difficulty is often used by attackers to send messages under a false identity from a domain to which attackers have access, or via a corrupt machine located in a legitimate domain. For example, an Internet domain "domaine.fr" created by an attacker can be used to make VoIP calls with a caller ID + 332abcdefghedomain.fr, when in fact the subscriber number " + 332abcdefgh "is attributed, say, to the domain" orange.fr ". Faced with this type of attack, adding a digital signature to the calling domain (see RFC 4474 of the IETF) is inefficient, because if it guarantees to the recipient that the call comes from "domain .fr ", this does not guarantee that the calling number is actually registered in this area. A solution to this difficulty of control is to block in the sending domain the sending of any message whose original address is not attached to the issuer domain, but this solution is too limiting, especially for the mobility of the services of Voice over Internet Protocol (VoIP) which allows a roaming terminal to use a third party relay such as a sender domain to establish a telephone call, which poses the problem of finding ways to a recipient domain to ensure that sufficient controls have been achieved at the level of the domain issuing the message.In the context of the present invention, will be called "transaction" all the protocol exchanges allowing the establishment of a secret shared, or primary session key, between two network entities A and B for the duration of a session The transaction corresponds to the initialization phase of the session, this sess can last much longer than the transaction. In some parts of the description, the terms transaction and session may be considered equivalent. For the sake of simplification, the session primary key will also be noted session key between A and B, independently of derivation or diversification operations that can be applied to it. This session key can for example be used to derivate other secret keys to set up a secure connection (TLS, IPSec, etc.) between the entities A and B. As another example, this session key can make it possible to guarantee the confidentiality or the integrity of an original message sent by the entity A (sending client) to the entity B (recipient customer); each new original message sent from a sending client to one or more client (s) recipient (s) corresponds to a new transaction; conversely, the repetition of a protocol step, for example because of a network problem, is not considered as a new transaction. A network entity can obviously, in principle, authenticate another network entity using a public key infrastructure PKI ("Public Key Infrastructure" in English). But as it is well known, PKI infrastructures are cumbersome to set up and use. Alternatively, some methods, such as the Diffie-Hellman algorithm, provide for the common determination of a session key by two entities prior to any exchange of original messages between them. But such an algorithm does not, in itself, give an entity A any guarantee on the identity of an entity B with which it thus establishes a session key. Alternatively, in networks comprising a small number of users, such as peer networks, provision may be made for a "manual" installation (for example by on-site visit) of a shared secret key for each pair of interested entities. . But such a facility is not suitable for networks with a large number of users. A solution well suited to networks with a large number of users is to set up a trusted third party, commonly called "Key Distribution Center". Each network entity A wishing to use this secure communications service subscribes to the Key Distribution Center, and consequently obtains, for a predetermined period of time or for a predetermined transaction, a secret key KsA shared between A and a server. Authorization S associated with the Key Distribution Center. Advantageously, the subscribers to this service do not have to store secrets or certificates concerning the other subscribers, the security of the communications being done transaction by transaction with the help of the Center of Distribution of Keys. In addition, the Key Distribution Center may, as required, securely transmit secret keys to support entities (storage, gateways, and so on) under its control, or to legal entities for the interception of certain communications. Since the Key Distribution Center is the repository of all the secret keys of the subscribers, it is obviously essential that it be powerfully protected against hostile intrusions, but this does not represent any particular difficulty. For example, under the name "Kerberos" (see RFC 4120 of the IETF), there is known such a method of secure communications between two entities A and B subscribed to the service. This Kerberos process essentially comprises the following steps: 1) An entity A identifies and authenticates itself as the holder of an identifier ID4 to said Authorization Server S (after having addressed an authentication server separate from the Authorization Server S); the Authorization Server S determines the secret key KsA that it shares with this entity A; 2) Entity A declares to Authorization Server S its intention to communicate with a certain entity B; the Authorization Server S determines the secret key KsB that it shares with this entity B; 3) the authorization server S generates a session key KAB, and sends it to the entity A, encrypted by means of said secret key KsA 4) the authorization server S also generates a "ticket" T comprising at least said identifier ID ,, of the entity A and said session key KAB; Authorization Server S sends entity A CHECKA data resulting from the encryption of said ticket T by means of said secret key KsB; 5) the entity A decrypts the session key KAB by means of its secret key KsA, and sends to the entity B, on the one hand, the data CHECKA (as previously received by the entity A from the Authorization Server S), and on the other hand VA data resulting from the encryption, with the session key KAB, of a set of elements comprising at least its IDA identifier; and 6) the entity B decrypts the ticket T by means of its secret key KsB; the KAB session key then allows him to decrypt the IDA identifier of the entity A; Entity B verifies that this identifier is the same as that contained in the ticket T; if Entity B approves the transaction, it informs Entity 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). Entity A can then complete the transaction with Entity B. For example, if Entity B is a service provider, Entity A will be able to request a particular service, and obtain it, by exchanging with the entity B encrypted data by means of the session key KAB. As another example, if the entity B waits for a document from the entity A, the entity A can send to the entity B an original message accompanied by the "MAC" code of this original message obtained by means of the key K4B session (it is recalled in this regard that, conventionally, a message authentication code, called "Message Authentication Code", or "MAC", is a short value - usually a few tens of bits - deduced from the data contained in a message and a secret key shared between the sender and the receiver of the message using a cryptographic algorithm, by sending a message accompanied by its authentication code, the sender allows the receiver to verify that this data does not emanate from another entity and have not been altered between transmission and reception).

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. The Kerberos method therefore provides for the transmission of the session key, on the one hand, directly to the entity A, and on the other hand indirectly (via the entity A) to the entity B; the latter therefore does not need to communicate with the Authorization Server S to obtain this session key. The Kerberos method also advantageously enables entity B to verify the identity of entity A; this check prevents a phishing attack, in which an attacker would first identify himself under his true identity with the Authorization Server S, in order to obtain a transaction authorization from the latter, then under a Identity impersonated from Entity B (for example by impersonating the Bank of Entity B to obtain confidential banking information). However, the Kerberos process has the disadvantage that entity B is susceptible to flood attacks. Let's go back to step # 6 above: Entity B must, before it can identify an attack, perform two decryptions plus an equality check. Decryptions are computationally heavy operations, so an attacker can overwhelm entity B by repeatedly sending arbitrary CHECKA and SA data to it. Worse, an attacker could send to entity B CHECKA and (5A data that the attacker has previously read or intercepted during a transaction initiated by a legitimate A entity (replay attacks): in this case, the attacker not only floods Entity B, but also legitimate Entity A, which repeatedly receives confirmation messages from Entity B. In fact, "Version 5" of the Kerberos process protects legitimate A entities from attacks by flooding by recommending the insertion of a time stamp in the data item 8A, but this further increases the task of the entity B which must verify that the data (SA successive it receives from a certain entity A all have a time stamp The present invention thus relates to a method of secure communications in a telecommunications network, in which a transaction between an entity A e a entity B of said network comprises the following steps: a) the entity A sends to an Authorization Server S an authorization request in which the entity A identifies and authenticates itself as the holder of an identifier IDA; b) Entity A declares to Authorization Server S its intention to communicate with a certain Entity B; the Authorization Server S determines a secret key KSB that it shares with this entity B; and c) the Authorization Server S generates a session key KAB, N and sends it to the entity A. This method is notable in that said session key KAB, N is a one-way function of said secret key KSB and is also a function of an integer N, called transaction number, assigned to said transaction, and in that it further comprises the following steps: d) the Authorization Server S also generates a transaction identifier IDTRN, which is a function dependent at least on said non-invertible transaction number N, and sends to entity A said transaction identifier IDTRN; e) the entity A sends to the entity B elements comprising at least the transaction identifier IDTRN; and f) entity B at least verifies that the value of the received IDTRN transaction identifier is within a set of pre-calculated values corresponding to at least one expected value of the transaction number; if so, the entity B deduces first the current value of the transaction number N, and then the value of the session key KAB, N. It is clear that step b) is not necessarily subsequent to step a). Likewise, step d) is not necessarily subsequent to step c). It should be noted that the evaluation of the authenticity of the entity A can be carried out by any known means of authentication. In addition, it can be done by previously addressing an Authentication Server separate from the Authorization Server S (similar to the Kerberos method). It will also be noted that in practice, and for cryptographic separation purposes, it is not necessarily the (primary) session key KAB N that will be used for data encryption, but rather a key derived from K B N. For the sake of simplification, the keys 25 derived from a primary key will not be systematically explained, but, according to the state of the art, the derivation or diversification operation will be implicit when the same shared secret serves more than one cryptographic function.

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. According to the present invention, unlike the Kerberos method, the Authorization Server S provides, for each new transaction identified by its number N, the session key KAB.N to the entity A, but not to the entity B. Indeed, according to the invention, the entity B has means for calculating itself this session key from the secret key KSB that it shares with the Authorization Server S, and the current transaction number N , that the entity B determines after receiving the transaction identifier IDTRN. Thanks to the invention, the above-mentioned advantages of secure communication methods of the "Key Distribution Center" type can be used. In particular, it imposes a verification of any subscriber entity to the secure communications service before it is addressed to another subscriber entity, to provide security guarantees to the other entity. In addition, the invention advantageously eliminates the disadvantage of the Kerberos method, mentioned above, concerning the sensitivity of entity B to flooding attacks. According to the invention, the entity B calculates the value of the transaction identifier IDTRN for at least one value N of the transaction number, this value being provided to follow a value used in a previous transaction. The IDTRN transaction identifier is transmitted in clear from the entity A to the entity B, which requires modifying its value for each transaction. In view of the potential for disorder of arrival that may occur when several transactions have been initiated over a short period by one or more entity (ies) A for the same entity B, it is actually preferable that the entity B calculate the value of the transaction identifier IDTRN for a predetermined sequence of several values of the integer N, and that, after receiving a certain IDTRN transaction identifier, it identifies by scanning in this set of values of IDTRN which number of transaction N is the received transaction identifier. It is recalled in this respect that the value of IDTRN is a function dependent at least on the integer N in a non-invertible manner, so that it is not possible to calculate the value of the integer N from the value of IDTRN by inverting this function, or calculating any one of the values IDTRN + r (i> 0) by knowing all or part of the previous values IDTRN_ (j 0). Thanks to these provisions, the entity B easily detects an attack (that is to say in few calculation operations) when it finds that an alleged IDTRN transaction identifier received does not appear within said set pre-calculated values (as explained below, an attacker has a small chance of guessing an N transaction value acceptable at a given time by a given B entity, so that this attacker can not compute a value of IDTRN 15 acceptable, even if the IDTRN (N) function is made public). This protects the entities subscribed to the secure communications service against flood attacks. An additional advantage of the invention over the Kerberos method lies in the size (in number of bits) of the protocol messages. In fact, according to the Kerberos method, the entity A sends to the entity B the CHECKS data obtained by encrypting the ticket T; However, this ticket T is necessarily large because it includes, in particular, the K`lB session key. This can be problematic in the case of some architectures using an unconnected transport mode (for example, those using the SIP signaling protocol) in which the nominal size of the signaling messages sometimes prevents the insertion of large data. cut.

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. On the other hand, according to the present invention, the entity A advantageously does not have to send a representative of the session key KAB N to the entity B. Moreover, the IDTRN transaction identifier can be a function of modest size (typically a few bytes) while providing good cryptographic security. Note finally that, when the confidentiality of the exchanges between the Authorization Server S and the entity A is not ensured by the underlying transport protocol, the Authorization Server S sends to the entity A, when steps c) and d) above, said session key KAB, N and said preferably IDTRN transaction identifier encrypted by means of a secret key KS4 shared between the authorization server S and the entity A (or a key derived from this secret key KSA), similarly to the transmission of the session key K4B of the Authorization Server S to the entity A in the Kerberos process. In this case, during said step e) above, the entity A obviously uses its secret key KSA to decrypt the session key KAB N and the transaction identifier IDTRN. According to particular features, all or part of said elements sent by the entity A to the entity B during said step e) are protected in integrity. Thanks to these provisions, these elements are protected against any alteration; however, such tampering would cause the transaction to fail in most cases. This integrity protection can in particular be achieved by means of a MAC code. According to even more particular characteristics, this integrity protection is carried out by means of said session key KAB N or a key derived from this session key 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. With these provisions, entity B will be able to ensure that entity A has the session key KAB N associated with the current transaction. According to other particular characteristics, during said step d), the Authorization Server S sends in addition to the entity A a CHECKA N data item deduced, by means of a cryptographic function dependent on a secret key KsB, N derived from said secret key KsB and the transaction number N, from a set of elements derived from said authorization request.

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. Thanks to these provisions, Authorization Server S can prove to Entity B that it has authorized the transaction and indicate the information on which it relied to do so. According to still other particular characteristics, said elements sent by the entity A to the entity B during said step e) comprise a derived identifier ID'A of the entity A, identical or not to said IDA identifier. Thanks to these provisions, the entity B is informed of the derived identity ID'A of the entity A which initiated with it the transaction number 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. According to even more particular characteristics: said set of elements from which said data CHECKA N is deduced comprises said derived identifier ID'A of the entity A, said elements sent by the entity A to the entity B during said step e) also comprise said data CHECKA N, and - during said step f), the entity B checks, by means of said secret key KsB.N, the coherence between, on the one hand, the data CHECKA N, and on the other hand said elements comprising the ID'A derived identifier received from the entity A as briefly described above. Thanks to these provisions, entity B can verify that the entity A which is addressed to it has been authorized by the Authorization Server S under the same identity ID'A ("anti-phishing"). The mechanism used in this embodiment of the invention is therefore equivalent to the mechanism used in Kerberos by decryption of the ticket T. On the other hand, in Kerberos, the entity A knows the value of the ticket T and the result of the encryption of the ticket T by means of the secret key KsB; if entity A is dishonest (and has powerful computing means), it could deduce KsB, brute force or other cryptographic means (the encryption algorithm is usually public). The invention, in this embodiment, solves this problem because, if it is true that the entity A knows CHECKA N and the elements whose encryption produces CHECKA N, it would be of no use for it to deduce therefrom value of the secret key KsB, N, since it is impossible from this last to calculate the secret key "mother" KsB, or else KsB, N + 1 (or even the current transaction number N). It will further be noted that this quantity CHECKA N is, in contrast to the CHECKA quantity of the Kerberos process, of modest size since it does not necessarily result in the encryption of a secret key. Correlatively, the invention relates to various devices. It thus concerns, firstly, a device, called Authorization Server, for securing communications in a telecommunications network during a transaction between an entity A and an entity B, comprising means for: identifying and authenticating an entity A holder of an IDA identifier, - determining a secret key KSB that said Authorization Server S shares with an entity B with which the entity A declares its intention to communicate, - generating a session key KAB, N and the send to the entity A. The said device is remarkable in that, said session key KAB N being a one-way function of said secret key KSB and also being a function of an integer N, called a transaction number, assigned to said transaction, it further comprises means for: generating a transaction identifier IDTRN, which is a function dependent at least on said non-invertible transaction number N, and sent er to the entity A said IDTRN transaction identifier. It also concerns, secondly, a device, said entity A, of secure communications in a telecommunications network, comprising means for, during a transaction involving said entity A and an entity B: - identify and authenticate as the holder of an IDA identifier with an Authorization Server S, - declare to said Authorization Server S his intention to communicate with a certain entity B, and - receive from the Authorization Server S a key of session 25 Said device is remarkable in that, said session key KAB N being a one-way function of a secret key KSB shared by the Authorization Server S and the entity B and also being a function of an integer N called transaction number, assigned to said transaction, it further comprises means for: receiving from the Authorization Server S a transaction identifier IDTRN, which is a dependent function at least of said transaction number N in a non-invertible manner, and - send to the entity B elements comprising at least said IDTRN transaction identifier. It also concerns, thirdly, a device, said entity B, for secure communications in a telecommunications network, remarkable in that it comprises means for, during a transaction involving said entity B and an entity A: - to receive the part of the entity A of elements comprising at least one IDTRN transaction identifier, said IDTRN transaction identifier being an at least non-invertible dependent function of an integer N, called a transaction number, assigned to said transaction, - check that the value of the received IDTRN transaction identifier is included in a set of pre-calculated values corresponding to at least one expected value of the transaction number, - deduce from it the current value of an integer N , called transaction number, assigned to said transaction, and - deduce a session key KAB, N which is, on the one hand, a one-way function of a secret key KSB shared by the Authorization Server S and entity B, and secondly function of said transaction number 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 ). The invention also relates to a device combining the means of the last two devices described briefly above (that is to say that behave, depending on the circumstances, either as an entity A, or as an entity 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. The advantages offered by these devices are essentially the same as those offered by the correlative methods succinctly set forth above. Note that it is possible to implement the secure communications method according to the invention by means of software instructions and / or by means of electronic circuits. The invention therefore also relates to a computer program downloadable from a communication network and / or stored on a computer readable medium and / or executable by a microprocessor. This computer program is notable in that it includes instructions for implementing said means included in any of the secure communication devices described briefly above. The advantages offered by this computer program are essentially the same as those offered by said devices. Other aspects and advantages of the invention will appear on reading the detailed description below of particular embodiments, given by way of non-limiting examples. The description refers to the figures which accompany it, in which: FIG. 1 schematically represents a telecommunications network and the main entities to which the invention applies, and FIG. 2 schematically represents the steps of a method of secure communications according to an embodiment.

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é. The system illustrated in FIG. 1 comprises at least three entities interconnected via a communication network, for example an Internet type network. The method is particularly advantageous in the case of an unconnected transport mode, but is also suitable for a connected transport mode.

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". Entities A and B subscribe to the same secure communications service. They each use, in a conventional manner, a terminal or a server capable of transmitting or receiving messages of any kind such as, for example, e-mails or telephone calls on fixed or mobile channels. It should be noted that, in the context of the present invention, the word "server" is, to simplify the disclosure, used to designate uniformly any type of computing device, and not only the computing devices conventionally referred to as "servers". .

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. In practice, the entity A can act as a server or relay for an entity A 'connected to A; likewise, the entity B can act as server or relay for a B 'entity connected to B. The entity S is an "Authorization Server" (which can, of course, be composed in practice of several physical servers) . It allows any subscriber A to address securely to any subscriber entity B; in addition, it protects the entity B against the reception of undesirable messages. Depending on the applications and deployment scenarios, the entity S may be independent of the application domains or networks to which the entities A and B belong, or the entity S may belong to the same application domain or network as the entity A and / or that the entity B. The Authorization Server S takes into account a sequence of integer values, called "transaction numbers", separately for each entity B subscribed to the secure communications service. The transaction number N is used to order the transactions. At the initialization of the method, the entities S and B agree on an initial transaction number No, which preferably varies from one entity B to another. Then, at each transaction, the transaction number N is modified according to an algorithm that can be public; for example, N can be incremented by 1 for each new transaction, but this algorithm can also vary from one B entity to another, in which case it must be included in the secrets shared by the S and B entities. , the transaction number is never transmitted in clear from one entity to another. Thanks to these provisions, it is impossible for an attacker to find the current value of the transaction number of an entity B. The transaction of the transaction number N must be authorized by the authorization server S, following a request from authorization issued by the entity A to S. The Authorization Server S responds to this authorization request by providing the entity A with the information necessary to contact the entity B. During each transaction, following An identification of the entity A, the Authorization Server S determines a long-term secret key KsA that it shares with this entity A. This long-term secret key KsA makes it possible to derive other secret keys that are used in need to ensure the integrity or confidentiality of messages exchanged between A and S. Similarly, there is a long-term shared secret KsB between S and B entities. This long-term secret key KsB allows to derive from other secret keys that are used as needed to ensure the integrity or confidentiality of messages exchanged (indirectly) between S and B. For any N number transaction, the S and B entities are capable of independently generating, using algorithms may be public: - an IDTRN transaction identifier, which must depend on at least N and be generated by means of an algorithm such that, if one or more IDTRN values previously received by the entity B are known, no can not deduce the current value of N, or a value IDTRN + r (i> 0); and the (primary) session key KAB, N used between the entities A and B for the current transaction; this session key must depend on at least N and KSB, and be generated by means of an algorithm such that, even if we know the value of KAB, N and the value of N, we can not deduce from it the value of KSB. In a conventional manner, the primary key of session (or transaction) KAB N makes it possible to derive other secret keys which are used as needed to ensure the integrity or the confidentiality of the messages exchanged between A and B. Figure 2 represents schematically the steps of an embodiment of the method according to the invention. In the present embodiment, it is assumed that an entity A, called the "sending client", wishes to send an "original message" MES to one or more entity (s) B, called "customer (s)". recipient (s). " The main steps of this embodiment will now be described. In a first step El, a new transaction is authenticated, and authorized, by an Authorization Server 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 . More specifically, during a substep E11, the entity A initiates a transaction by sending a authorization request REQ to the Authorization Server S, with which it shares a secret key KSA. This REQ authorization request contains at least elements allowing Authorization Server S to authenticate entity A, these elements comprising at least one IDA identifier of this entity. The request REQ authorization may further contain: - information to identify the transaction between the entities A and S, - information characterizing the message MES or to identify the entity A or entity B, and a random value serving as a transaction indicator between A and S. Finally, when the integrity of the exchanges between A and S is not ensured by the underlying transport protocol, the authorization request REQ preferably contains a MAC code calculated on all or part of the aforementioned elements of the REQ request. To do this, use a secret key KS.A, MACI derived from the secret key KsA. It will also be noted, concerning the identities of the entities A and B, that: in certain cases, the entity A does not completely know the identity of the recipient client of its original message MES; this identity is then determined by the Authorization Server S; - in some cases, it is possible that, for reasons of anonymity, the IDA ID of Entity A is not revealed to Entity B, or Entity A requests Authorization Server S to present entity A to entity B under a "derived identifier" ID'A; and where appropriate, depending on the architecture under consideration, the identities of A or B may be replaced or supplemented by those of A 'or B' (see description of FIG. 1 above). During a substep E12, upon receipt of the authorization request REQ, the Authorization Server S decides, according to the information contained in this request, to authorize or not the transaction. If necessary, the Authorization Server S determines the identity of the or the client (s) recipient (s) B (or B '). If the transaction is authorized, the Authorization Server S transmits to the entity A, during a step E2, a response authorization RESP containing at least the session key KAB N and the transaction identifier IDTRN. Note that: - when the confidentiality of the exchanges between the Authorization Server S and the entity A is not ensured by the underlying transport protocol, the Authorization Server S sends the entity A the key KAB session, N preferably encrypted by means of said secret key KsA or a key derived from this secret key KsA; - the IDTRN transaction identifier can be passed in clear, but if an attacker was able to read its value, it could send to entity B one or more invalid messages before the entity A emits the legitimate message; to be able to detect such an attack, Entity B should carry out additional checks (since the value of the IDTRN transaction identifier would not be sufficient security), which would expose Entity B to a risk of attack by flood; also, in the case where the confidentiality of the exchanges between the Authorization Server S and the entity A is not ensured by the underlying transport protocol, the Authorization Server S sends to the entity A the preferably IDTRN transaction identifier encrypted by means of the secret key KsA or a secret key derived from this secret key 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. The RESP authorization response may further contain: - for verification purposes, a subset of the information contained in the REQ authorization request; in particular, if the latter contained a transaction witness, then this cookie should preferably be included in the RESP authorization response; and a CHECKA data item N deduced, by means of a cryptographic function dependent on a secret key KSB, N derived from said secret key Kse and the transaction number N, from a set of elements taken from the request of authorization REQ and, preferably, a randomly generated simultaneously, at each transaction, by the Authorization Server S and the entity B (this hazard prevents a malicious entity A to find the secret key KsB, N by inversion of the data CHECKA, N). Note that it is possible to envisage applications of the invention in which the entity A is allowed to remain anonymous with respect to the entity B; in this case, as possibly in other cases, the said elements taken from the REQ authorization request will not contain the IDA identifier of the entity A. In the opposite case, the Authorization Server S will preferably include the ID'A derived identifier of the entity A in the elements whose encryption provides the data CHECKA, N. Finally, when the integrity of the exchanges between A and S is not ensured by the underlying transport protocol, the authorization response RESP preferably contains a MAC code calculated on all or part of the aforementioned elements of the response. RESP. To do this, use a secret key KSA, MAC2 (equal or not to said secret key KsA, MACI) derived from the secret key KsA. In a step E3, the entity A receives the authorization response 20 RESP from the Authorization Server S, and sends an "authenticated message" AM to the entity B. More precisely, during a Sub-step E31, after receiving the RESP authorization response, the entity A verifies that: the verification information contained in the authorization response RESP corresponds to a REQ authorization request previously issued by the entity A, and - the MAC code using the secret key KSA, MAC2, if present, is valid.

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. If the checks are positive, during a substep E32, the entity A extracts from the authorization response RESP the session key KAB ,, v, the transaction identifier IDTRN, and, if applicable, the given CHECKA N. The entity A then sends to the entity B an "authenticated message" AM comprising the original message MES, the transaction identifier IDTRN, and, where appropriate, the data CHECKA, .N. When the integrity of the exchanges between A and B is not ensured by the underlying transport protocol, the authenticated message AM preferably contains a MAC code, 5.4, N calculated on all or part of the aforementioned elements of this AM message. To do this, the session key KAB N or a secret key KAB, N, MAC derived from the session key KAB, N will advantageously be used. In the case where the entity A is not authorized, or does not wish to remain anonymous with respect to the entity B, the entity A will include its derived identifier ID '4 in the authenticated message AM. This derived identifier ID '4 can of course also be included in said elements serving as a basis for computing the MAC code Ô'A, N. It will be noted that, in a variant (see, in particular, the architecture examples presented below), the authenticated message AM may be sent by an authorized entity other than the entity A itself, for example another network server, under reservation that this authorized entity has been identified in the information contained in the REQ authorization request. In a step E4, the entity B receives the authenticated message AM and determines the session key. More specifically, during a substep E41, after receiving an authenticated message AM, the entity B verifies that the received IDTRN element corresponds to an expected transaction identifier. Preferably, the entity B pre-calculates IDTRN values for a predetermined sequence of values of N, after the end of the previous transaction and therefore before receiving a new authenticated message 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 . If the received IDTRN value is valid, the entity B deduces the current value N from the transaction number, and retrieves or calculates the session key KAB.N, as well as, optionally, said secret key KSB, N and / or said secret key KAB, N.MAC associated with this transaction. Entity B then optionally verifies that: the information that the entity B has received is consistent with the MAC code b'A N (if present) and the session key KAB N or the secret key KAB, N, MAC, and / or - the information that the entity B has received is consistent with the data CHECKA N (Si present) and the secret key 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. In particular, the entity B checks, if necessary, by means of said secret key Ks8 N, the coherence between, on the one hand, the data CHECK.4, N and on the other hand said elements comprising the ID derivative ID Received from the entity A. Finally, if all the checks are positive, during a substep E42, the entity B extracts the original message MES from the authenticated message AM, and transmits, if necessary, this message. original MES to a recipient customer B '. We will now examine, as examples, various possible architectures for the implementation of the 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. The first three examples apply to VoIP. VoIP services and networks are a particularly interesting application context, because in addition to strong security constraints, they also have real-time constraints, the number of deployed entities (currently several million in some networks), power terminals, as well as legal constraints that require the ability to intercept sensitive communications. This need for legal interceptions naturally militates for the control of session keys by a trusted entity (here the Authorization Server S), which could then be a proxy of a network operator. (a) Intra-domain VoIP Communications The client entities A and B, as well as the Authorization Server S belong to the network of the same operator. The Authorization Server S is a VoIP proxy of this network which conventionally has a shared secret with each of the client terminals, this secret having been established during the subscription phase to the service, and then checked during the registration phase. from the terminal to the network.

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. The authorization request sent by the entity A allows the Authorization Server S to authenticate it and determine the routing to reach the entity B. The call can then be established directly between the entities A and B without that it is necessary to establish a TLS connection between A and B to ensure the integrity and confidentiality of the signaling. The message AM corresponds to the INVITE request. (b) VolP Mode 1 Interconnections In this embodiment, the sending and receiving entities are located in two separate networks belonging to different operators; the sender domain is noted D-EXP and the destination domain D-DEST. Entity A is one of the outgoing proxies of the DEXP sender domain. Entity A serves several client terminals A 'of the D-EXP domain or A' sending servers in the same domain, or in a third domain when the client terminal is in a mobility situation. The Authorization Server S is one of the incoming proxies of the destination domain D-DEST. The Authorization Server S protects and serves one or more entities B that may belong to the destination domain D-DEST or to third-party domains. Entity B can correspond directly to the destination client terminal. Alternatively, the entity B may correspond to a receiving server, belonging to the recipient domain D-DEST or a third domain, in which case the real recipient client terminal corresponds to the entity B '. In the authorization request, the entity A references the destination entity B via one or more network, transport or application level identifiers such as the network address of the entity B, the domain name to which the entity belongs. entity B, a SIP_URI or Tel_URI designating the destination client entity. Similarly, the entity A identifies itself by one or more network, transport or application level identifiers such as its network address, or the domain name to which it belongs, or a SIP_URI or Tel_URI designating the sending client entity.

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' . Performing the number N transaction allows A and B to share the KAB N session primary key. This session key authenticates the INVITE call setup message. In addition, it can also be used to authenticate the other phases of the call (CANCEL requests, ACK, BYE or associated responses). It can also be used to derive secondary keys for media stream encryption. The REQ authorization request and the RESP authorization response are exchanged between a sending server and a destination server, whereas the AM message is sent by a sending or sending server to a receiving server. (c) Mode 2 VoIP Interconnections As above, the sending and receiving entities are located in two separate networks denoted D-EXP and D-DEST. Entity A is a client terminal of the D-EXP domain or a sender server of the sender domain or a third domain. If the entity A is a sending server, then the real sending client corresponds to an entity 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. Authorization Server S is one of the outgoing proxies of the sending domain D-EXP, that is to say a sender server. The Authorization Server S serves the entities A of the sender domain or third-party domains, and authorizes the communications with the destination domain.

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. Entity B is one of the incoming proxies of the destination domain DDEST. This entity serves and protects entities B 'which are either directly client terminals or receiving servers belonging to the destination domain or to third-party domains. The REQ authorization request and the RESP authorization response are exchanged in the sender domain or between the sender domain and the sender domain, while the AM message is sent by a client entity or sender server to the recipient server. (d) IM e-mail or instant message sending The architecture is similar to that for VoIP interconnects (mode 1 or mode 2) with respect to entities A, A ', S, B, and B' . The identifiers used in the transaction request to designate the entities A or A '(respectively B or B') are e-mail addresses, IM addresses or domain names.

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. Performing the number N transaction allows A and B to share the primary session key K, 4B, N. This session key is used to authenticate and ensure the integrity of the e-mail or IM message sent from A to B. (e) Secured connection establishment Entity A sends an authorization request to the Authorization Server S which protects access to Entity B with which Entity A wants to communicate. The authorization request includes the identifiers of the entities A and B, in the form of network or transport addresses, or application addresses with respect to the service in question. Performing the number N transaction allows A and B to share the primary session key Kl4B N. This session key is then used to establish a secure connection (IPSec, TLS, DTLS, ...) between the A and B entities. (F) Application to a DNS / ENUM type service The principle here is to apply the method according to the invention to a connection service, where the Authorization Server S is a DNS or ENUM type server in the case of VoIP applications. This avoids attacks in which a calling VoIP entity claims a telephone number that is not assigned to its network or application domain. In this case of application, the entity A is one of the outgoing proxies of the "domainel" domain and has a secret shared with the Authorization Server S. Before issuing a call to the entity B , the entity A sends an authorization request to the Authorization Server S to authenticate the caller and obtain a secret call key to 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. Authorization Server S is a DNS / ENUM server that has shared secrets KsA, KsB with a number of domains, via a prior linking phase. Authorization Server S acts as a trusted third party.

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. Entity B is one of the incoming proxies of domain "domain2" and has a shared secret with Authorization Server S. The completion of the transaction allows Entity B to verify that the identifier of caller presented by the entity A in the INVITE request has been authenticated by the Authorization Server S. It also allows the entities A and B to have a shared secret KAB, N that can be used to protect the continuation of the exchange or media streams. The implementation of the invention within the nodes of the telecommunications network (in particular, the terminals or servers of entities such as A or B subscribed to the secure communications service according to the invention, or the Authorization Server S) can be realized by means of software and / or hardware components. The software components can be integrated into a typical network node management computer program. Therefore, as indicated above, the present invention also relates to a computer system. This computer system conventionally comprises a central processing unit controlling signals by a memory, as well as an input unit and an output unit. In addition, this computer system can be used to execute a computer program comprising instructions for implementing the secure communications method according to the invention. Indeed, the invention also relates to a downloadable computer program from a communication network comprising instructions for performing at least some of the steps of a secure communications method according to the invention, when it is executed on a computer. This computer program may be stored on a computer readable medium and may be executable by a microprocessor. This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any another desirable form. The invention is also directed to a computer-readable information carrier having instructions of a computer program as mentioned above. The information carrier may be any entity or device capable of storing the program. For example, the medium may comprise storage means, such as a ROM, for example a CD-ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a diskette ("floppy disc"). English) or a hard drive. On the other hand, the information medium may be a transmissible medium such as an electrical or optical signal, which may be routed via an electrical or optical cable, by radio or by other means. The computer program according to the invention can in particular be downloaded to an Internet type network. Alternatively, the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted for use in a secure communications device according to the invention.

Claims (12)

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 . REVENDICATIONS1. A method of secure communications in a telecommunications network, wherein a transaction between an entity A and a B entity of said network comprises the following steps: a) the entity A sends to an Authorization Server S an authorization request (REQ ) in which entity A identifies and authenticates itself as the holder of an IDA ID; b) Entity A declares to Authorization Server S its intention to communicate with a certain Entity B; the Authorization Server S determines a secret key KSB that it shares with this entity B; and c) the Authorization Server S generates a session key KAB, N and sends it to the entity A; said method being characterized in that said session key KAB, N is a one-way function of said secret key KSB and is also a function of an integer N, called a transaction number, assigned to said transaction, and that it further comprises the following steps: d) Authorization Server S also generates a transaction identifier IDTRN, which is a function at least dependent on said transaction number N in a non-invertible manner, and sends to the entity A said IDTRN transaction identifier; e) the entity A sends to the entity B elements comprising at least the transaction identifier IDTRN; and f) Entity B at least verifies that the value of the received IDTRN transaction identifier is within a set of pre-calculated values corresponding to at least one expected value of the transaction number; if so, the entity B deduces first the current value of the transaction number N, and then the value of the session key 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é. 2. secure communication method according to claim 1, characterized in that all or part of said elements sent by the entity A to the entity B during said step e) are protected in integrity. 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 . 3. secure communication method according to claim 2, characterized in that this integrity protection is performed by means of said session key K4B N or a key derived from this session key 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). 4. secure communication method according to any one of claims 1 to 3, characterized in that, in said step d), the Authorization Server S further sends to the entity A a data item CHECKA N deduced, by means of a cryptographic function dependent on a secret key KsB, N derived from said secret key KsB and the transaction number N, of a set of elements derived from said authorization request (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. 5. secure communication method according to any one of claims 1 to 4, characterized in that said elements sent by the entity A to the entity B during said step e) comprise a derived identifier ID'A of the entity A, identical or not to said identifier 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. 6. Secure communication method according to claim 4 and claim 5, characterized in that: said set of elements from which said data CHECKA N is deduced comprises said derived ID'A identifier of the entity A, said elements sent by the entity A to the entity B during said step e) also comprise said data CHECK4 N, and - during said step f), the entity B checks, by means of said secret key KsB.N, the coherence between, on the one hand, the data CHECKA N, and on the other hand said elements comprising the derived identifier ID 'a received from the entity A according to claim 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 . 7. Device, called Authorization Server, for securing communications in a telecommunications network during a transaction between an entity A and an entity B, comprising means for: identifying and authenticating an entity A holding an identifier ID4, - determining a secret key KsB that said Authorization Server S shares with an entity B with which the entity A declares its intention to communicate, - generating a session key KAB, N and sending it to the entity A characterized in that, said session key KAB N being a one-way function of said secret key KsB and also being a function of an integer N, called transaction number, assigned to said transaction, it further comprises means for generating a transaction identifier IDTRN, which is a function dependent at least on said transaction number N in a non-invertible manner, and sending to the entity A said IDTRN transaction identifier. 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 . 8. Device, said entity A, of secure communications in a telecommunications network, comprising means for, during a transaction involving said entity A and an entity B: - identify and authenticate as the holder of a identifier IDA with an Authorization Server S, - declare to said Authorization Server S its intention to communicate with a certain entity B, and - receive from the Authorization Server S a session key KAB, N characterized in that, said session key KAB N being a one-way function of a secret key KSB shared by the Authorization Server S and the entity B and also being a function of an integer N, called the transaction number, assigned to said transaction, it further comprises means for: - receiving from the Authorization Server S a transaction identifier IDTRN, which is a function dependent at least on said transaction number N in a non-invertible manner , and - send to the entity B elements comprising at least said IDTRN transaction identifier. 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. 9. Device, said entity B, for secure communications in a telecommunications network, characterized in that it comprises means for, during a transaction involving said entity B and an entity A: - receive from the entity A elements comprising at least one transaction identifier IDTRN, said IDTRN transaction identifier being an at least non-invertible dependent function of an integer N, called transaction number, assigned to said transaction, - check the value of the received IDTRN transaction identifier is included in a set of pre-calculated values corresponding to at least one expected value of the transaction number, - deducing from it the current value of an integer N, called the number of transaction, assigned to said transaction, and - deriving a session key KAB, N which is, on the one hand, a one-way function of a secret key KSB shared by the Authorization Server S and the B, and secondly according to said transaction number 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. 10. Device for secure communications in a telecommunications network, characterized in that it comprises means according to claim 8 and according to claim 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. An immovable, or partially removable, or removable data storage means having computer program code instructions for implementing said means included in a secure communications device according to any one of claims 7 to 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. Computer program downloadable from a communication network and / or stored on a computer readable medium and / or executable by a microprocessor, characterized in that it comprises instructions for the implementation of said means included in a secure communication device according to one of claims 7 to 10.
FR0956821A 2009-09-30 2009-09-30 Entities e.g. web server, communication method for e.g. Internet, involves deducing current value of transaction number and value of session key, if value of transaction identifier does not correspond to expected value of transaction number Pending FR2950767A1 (en)

Priority Applications (5)

Application Number Priority Date Filing Date Title
FR0956821A FR2950767A1 (en) 2009-09-30 2009-09-30 Entities e.g. web server, communication method for e.g. Internet, involves deducing current value of transaction number and value of session key, if value of transaction identifier does not correspond to expected value of transaction number
US13/497,571 US8683194B2 (en) 2009-09-30 2010-09-28 Method and devices for secure communications in a telecommunications network
PCT/FR2010/052028 WO2011039460A2 (en) 2009-09-30 2010-09-28 Method and devices allowing secure communication in a telecommunications network
EP10773652.2A EP2484084B1 (en) 2009-09-30 2010-09-28 Method and devices allowing communication secure against denial of services (dos) and against flooding attacks in a telecommunications network
CN201080054106.XA CN102668497B (en) 2009-09-30 2010-09-28 Method and device allowing secure communication in a telecommunications protected against denial of service (Dos) and flooding attack

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0956821A FR2950767A1 (en) 2009-09-30 2009-09-30 Entities e.g. web server, communication method for e.g. Internet, involves deducing current value of transaction number and value of session key, if value of transaction identifier does not correspond to expected value of transaction number

Publications (1)

Publication Number Publication Date
FR2950767A1 true FR2950767A1 (en) 2011-04-01

Family

ID=42245967

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0956821A Pending FR2950767A1 (en) 2009-09-30 2009-09-30 Entities e.g. web server, communication method for e.g. Internet, involves deducing current value of transaction number and value of session key, if value of transaction identifier does not correspond to expected value of transaction number

Country Status (1)

Country Link
FR (1) FR2950767A1 (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007062672A1 (en) * 2005-11-30 2007-06-07 Telecom Italia S.P.A. Method and system for automated and secure provisioning of service access credentials for on-line services to users of mobile communication terminals
EP1887758A2 (en) * 2002-11-26 2008-02-13 Cisco Technology, Inc. 802.11 Using a Compressed Reassociation Exchange to Facilitate Fast Handoff
WO2008091517A1 (en) * 2007-01-19 2008-07-31 Kabushiki Kaisha Toshiba Kerberized handover keying

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1887758A2 (en) * 2002-11-26 2008-02-13 Cisco Technology, Inc. 802.11 Using a Compressed Reassociation Exchange to Facilitate Fast Handoff
WO2007062672A1 (en) * 2005-11-30 2007-06-07 Telecom Italia S.P.A. Method and system for automated and secure provisioning of service access credentials for on-line services to users of mobile communication terminals
WO2008091517A1 (en) * 2007-01-19 2008-07-31 Kabushiki Kaisha Toshiba Kerberized handover keying

Similar Documents

Publication Publication Date Title
EP2484084B1 (en) Method and devices allowing communication secure against denial of services (dos) and against flooding attacks in a telecommunications network
US9432340B1 (en) System and method for secure end-to-end chat system
US7899185B2 (en) Real privacy management authentication system
CA2636780C (en) Method and device for anonymous encrypted mobile data and speech communication
US8850203B2 (en) Secure key management in multimedia communication system
EP2449744B1 (en) Restriction of communication in voip address discovery system
KR101013427B1 (en) End-to-end protection of media stream encryption keys for voice-over-IP systems
EP2577901A1 (en) Method and devices for secure communications in a telecommunications network
FR2788914A1 (en) AUTHENTICATION METHOD, WITH ESTABLISHMENT OF A SECURE CHANNEL, BETWEEN A SUBSCRIBER AND A SERVICE PROVIDER ACCESSIBLE VIA A TELECOMMUNICATION OPERATOR
CN110493367B (en) Address-free IPv6 non-public server, client and communication method
US8923279B2 (en) Prevention of voice over IP spam
EP3219077B1 (en) Method and system for managing user identities intended to be implemented during communication between two web browsers
Jabel et al. A study of SIP trunk security and challenges
FR2950767A1 (en) Entities e.g. web server, communication method for e.g. Internet, involves deducing current value of transaction number and value of session key, if value of transaction identifier does not correspond to expected value of transaction number
Patil et al. VoIP security
FR3081653A1 (en) METHOD OF MODIFYING MESSAGES BY EQUIPMENT ON A COMMUNICATION PATH ESTABLISHED BETWEEN TWO NODES
Abdullahi Examining the network & security infrastructure of skype mobile application
Zhuang et al. A hybrid session key exchange algorithm for highly-sensitive IP-based institutional communications
WO2010133783A1 (en) Method for protecting against unwanted messages in a telecommunication network
WO2023117802A1 (en) Methods for identifying at least one server for mitigating and protecting a client domain against a computer attack, corresponding devices and signal
Zhang et al. Side effects of identity management in SIP VoIP environment
Veigner et al. On email spamming under the shadow of large scale use of identity-based encryption
López Luque Comparison of different ways to avoid internet traffic interception
Sinha Analysis of VoIP Forensics with Digital Evidence Procedure
Wing et al. Voip Security