EP2577901A1 - Procede et dispositifs de communications securisees dans un reseau de telecommunications - Google Patents

Procede et dispositifs de communications securisees dans un reseau de telecommunications

Info

Publication number
EP2577901A1
EP2577901A1 EP11727272.4A EP11727272A EP2577901A1 EP 2577901 A1 EP2577901 A1 EP 2577901A1 EP 11727272 A EP11727272 A EP 11727272A EP 2577901 A1 EP2577901 A1 EP 2577901A1
Authority
EP
European Patent Office
Prior art keywords
entity
transaction
idtr
authorization server
identifier
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.)
Withdrawn
Application number
EP11727272.4A
Other languages
German (de)
English (en)
Inventor
Patrick Battistello
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
Publication of EP2577901A1 publication Critical patent/EP2577901A1/fr
Withdrawn 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/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • 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
    • 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/3271—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 using challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/76—Proxy, i.e. using intermediary entity to perform cryptographic operations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless

Definitions

  • the present invention relates to securing communications in a telecommunications network.
  • Telecommunications networks such as the Internet
  • Telecommunications networks 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.
  • 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” means here any set of information, for example an email, or a request for initiation of VoIP call (initials of the words “Voice over Internet Protocol” meaning “Voice over IP”) or an "instant message”.
  • 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 not attached to the sender domain.
  • SMS Simple Mail Transfer Protocol
  • an Internet domain "domain.fr” created by an attacker can be used to make VoIP calls with a caller identity + 332abcdefqh (a ) domaine.fr, whereas in fact the number Subscriber "+ 332abcdefgh” is attributed, say, to the domain “orange.fr”.
  • adding a digital signature to the calling domain is inefficient, because if it guarantees 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 VoIP that allows a roaming terminal to use a third party relay such as a sender domain to make a phone call.
  • This situation poses the problem of finding means enabling a recipient domain to ensure that sufficient checks have been made at the domain sending the message.
  • the term "transaction” will be used to refer to all the protocol exchanges allowing the establishment of a shared secret, or "primary session key", between two network entities A and H for the duration of one session.
  • the transaction is the initialization phase of the session, this session can last much longer than the transaction.
  • the terms transaction and session may be considered equivalent.
  • the session primary key will also be marked “session key” between A and B, independently of derivation or diversification operations that may be applied to it.
  • This session key can for example be used for the derivation of other secret keys to set up a secure connection (TLS, IPSec, or other) between the entities A and H.
  • this session key may make it possible to guarantee the confidentiality or integrity of an original message sent by the entity A (sending client) to the entity B (recipient client); 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). But as it is well known, PKI infrastructures are cumbersome to set up and use.
  • PKI Public Key Infrastructure
  • 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.
  • IPACF Identity-Based Privacy-Protected Access Control FHter
  • This protocol is intended for an architecture comprising a set of entities A all of which can communicate securely with a single entity B; in practice, the entities A are clients and the unique entity H is a server or an access control entity. There is a separate shared secret between B and each of the A entities.
  • the IPACF protocol comprises three phases: an initial configuration phase allowing the setting up of shared secrets, an authentication phase during the establishment of a new session, and finally the secure communication phase itself.
  • an entity A sends a frame containing a user identifier (which is a function of the shared secret and a frame number), as well as a filtering value (also a function of the shared secret and the frame number).
  • Entity B checks whether the received identifier is valid with respect to all the possible identifiers for all the entities A at a given instant; if necessary, entity B checks the filtering value for the identified entity A.
  • entity A and the entity B update their values of identifiers and filtering.
  • the IPACF protocol provides good protection against flood attacks, since any frame received by A or H not associated with a valid identifier and filtering value is rejected. This check is trivial for the receiver because it is a comparison with pre-calculated values. In addition, this protocol offers good protection against replay, since the ID and filter values change at each frame. But the IPACF protocol has some disadvantages. In the first place, the mechanism is sensitive to the loss of frames, since to every frame sent by A must answer a frame sent by B; this disadvantage is particularly troublesome in the case of a transport protocol in non-connected mode, where the signaling packets can arrive in any order, and possibly get lost on the way. Secondly, the mechanism is "asymmetric" in the sense that each entity A can only communicate with an entity B with which it has a shared secret; thus, it is not possible to envisage direct secure communications between two user entities A.
  • a "symmetrical" mechanism 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 duration or for a predetermined transaction, a secret key K SA shared between A and a server.
  • Authorization S associated with the Key Distribution Center is associated with the Key Distribution Center.
  • 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 participation of the Center of Distribution of Keys.
  • 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.
  • the entity A sends to a Authorization Server S a request for authorization in which the entity A identifies and authenticates itself as the holder of an identifier ID A ;
  • Entity A declares to Authorization Server S its intention to communicate with a certain Entity B; the Authorization Server S determines a secret key K SB which it shares with this entity B;
  • the Authorization Server S generates a session key ⁇ ⁇ , said session key K ⁇ B being a one-way function of said secret key K SB and also being a function of an integer N, called the transaction number, assigned to said transaction; then the Authorization Server S sends said session key K ⁇ B to the entity A;
  • the Authorization Server S also generates a "filtering value" IDTR N , which is a function dependent at least on said transaction number N in a non-invertible manner;
  • the Authorization Server S sends to the entity B elements comprising at least said filtering value IDTR N ;
  • the entity B verifies that the filtering value IDTR N received during said step e) is part of a set of values precalculated by the entity B and associated with at least one expected value of the transaction number, and then deduce the current value of the transaction number N;
  • Entity B generates session key K ⁇ B. 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 and obtain a particular service by exchanging encrypted data with Entity B using session key K ⁇ B.
  • the entity A can send to the entity B an original message accompanied by the code "MAC" of this original message obtained by means of the key of session K ⁇ B (it is recalled in this regard that, conventionally, a message authentication code, called in English "Message Authentication Code” or "MAC” is a short value - usually a few tens of bits - deduced 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 these data do not emanate from another entity and have not been altered between their transmission and reception).
  • MAC message authentication code
  • the entity B receives, during step e) above, the filtering value IDTR N from the Authorization Server S.
  • the entity B calculates the filtering value IDTR N for at least one value N of the transaction number, this value being provided for following, according to a predetermined algorithm, a value used in a previous transaction.
  • the filtering value IDTR N for at least one value N of the transaction number, this value being provided for following, according to a predetermined algorithm, a value used in a previous transaction.
  • the elements sent to this entity B during said step e) do not reach it in the order of the numbers of transaction N prescribed by the algorithm.
  • the protocol IDDR-CEP provides that, preferably, the entity B precalculates the filtering value IDTR N for a predetermined sequence of several values of the integer N, and that, after receiving a certain value for filtering IDTR N , entity B identifies, by scanning in this set of IDTR values N , which transaction number N corresponds to the received filtering value.
  • IDTR N 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 IDTR N inverting this function, nor compute any one of the values IDTR N + i (/> 0) knowing all or part of the previous values IDTR N _ j (j ⁇ 0).
  • the entity B detects such an attack easily (that is to say in few calculation operations) when it finds that a value received and supposed to represent a valid filtering value IDTR N is not included within said precomputed set of values (an attacker has a small chance of guessing a transaction number value N acceptable at a given time by a given entity B, so that this attacker can not calculate an acceptable value of IDTR N , even if the way the IDTR filtering value N is a function of N is made public).
  • the size (in number of bits) of the protocol messages in the IDDR-CEP protocol is advantageously low.
  • the IDDR-CEP protocol therefore provides for the establishment of an Authorization Server S.
  • the entities S ( and B) belong to the same domain or network, and the number of entities S t is limited to a few units so as to ensure load sharing or redundancy in case of failure, and / or
  • entities S typically, entities S ( and B all belong to different domains, for example entity B is the incoming proxy of the domain "orange.fr", and each entity S t is an outgoing proxy of a third-party domain that can send messages to the orange.fr domain.
  • Entity B needs to know which of the Authorization Servers S t is handling the current transaction because, as in the IDDR-CEP protocol, it is highly desirable that the authentication of Entity A is the responsibility of Authorization Server therefore, for defend against attacks by impersonation, B must be able to authenticate this Authorization Server, that is to say identify it (among the p servers of the group) in a secure manner;
  • the size of the protocol messages is sufficiently small to allow the use of an unconnected transport mode (for example, associated with the SIP signaling protocol), in which the nominal size of the signaling messages prevents the insertion of large data; and
  • the protocol can easily accommodate a scalability if it is desired to allow a large number of entities S ( (for example, several hundred) to manage transactions involving the same entity B.
  • This method comprises, for a transaction between an entity A and a B entity of said network, the following steps:
  • the entity A sends to one of the Authorization Servers S (an authorization request in which the entity A identifies and authenticates itself as the holder of an identifier ID A ;
  • the entity A declares to said Authorization Server S ( its intention to communicate with the entity B; the Authorization Server S t determines an individual secret key K SiB that it shares with this entity B;
  • the Authorization Server S t generates a session key K ⁇ B Si which is a one-way function of said individual secret key K SiB , and is also a function of an integer N, called the transaction number, assigned to said transaction; the Authorization Server sends said session key K ⁇ B Si to the entity A; d) the Authorization Server S t also generates a filtering value IDTR N , which is a function dependent at least on said non-invertible transaction number N; then it generates an IDTR transaction identifier N Si , which is a function of said IDTR filtering value N , of said individual secret key K SiB , and an identifier ID Si of this Authorization Server S t ;
  • Authorization Server S sends entity B elements comprising at least said transaction identifier IDTR N Si ; f) using the transaction identifier IDTR N Si received during said step e), the entity B:
  • step b) is not necessarily subsequent to step a).
  • step d) is not necessarily subsequent to step c).
  • the invention applies to any number of Authorization Servers (including only one), but is particularly advantageous when the number p of Authorization Servers is high.
  • the evaluation of the authenticity of the entity A can be performed by any known authentication means.
  • this evaluation can be done by contacting an Authentication Server separate from the Authorization Server S beforehand.
  • an Authorization Server S t determines, for a new transaction having a certain entity B as recipient, a transaction number N. Then the Authorization Server
  • the entity B has means for calculating the session key itself, according to the present invention the entity B uses for this purpose an individual secret key K SiB , as well as the current transaction number N, whose entity B determines the value after receiving a "transaction identifier" IDTR N Si from the Authorization Server S - either directly or via another entity, which may advantageously be the entity A (see the embodiments described in detail below).
  • Each Authorization Server S determines the successive transaction numbers N relative to a given entity B according to a predetermined algorithm (examples of which will be given below) Entity B precalculates a "filtering value" IDTR N for minus a value of the transaction number N. For the same reasons as in the IDDR-CEP protocol, the entity B preferably precalculates the filtering values IDTR N for several expected values of the transaction number N (which, in the context of of the present invention, a "transaction window" will be called.) In this respect, it should be noted that the Authorization Servers S ( do not need, as for them, to manage the transaction window.
  • sequence of transaction numbers used, according to said algorithm, by a given Authorization Server S t for a given entity B is (except for a particular arrangement) independent of the sequence of transaction numbers used by the same Authorization Server S ( for another entity B; therefore, the transaction windows used by the various B entities are (except special arrangement) mutually independent.
  • the transaction identifier IDTR N Si is a function of the filtering value IDTR N , the individual secret key K SiB , and an identifier ID Si of this Authorization Server S, as will be explained in detail below.
  • entity B obtains, after receiving the IDTR transaction identifier N Si , the current IDTR filtering value N by scanning in all of said precalculated filtering values associated with the current transaction window. Entity B then deduces the identifier ID Si .
  • the filtering value IDTR N is not transmitted to the entity B in the clear, but in a more or less partially masked form (see example embodiments below), to prevent an attacker (other than a corrupted Authorization Server separate from the present Authorization Server S t ) from being able to, from the transaction ID IDTR N Si and the value of filtering IDTR N , obtain the identifier ID Si of the Authorization Server S
  • Entity B can therefore detect an attack easily, that is to say in few calculation operations, when it finds:
  • the value of the transaction identifier IDTR N Si received is not compatible with any of the precalculated IDTR filtering values N , or
  • the invention thus advantageously offers (as did the IDDR-CEP protocol, although with other means) an excellent protection for entities subscribed to the secure communications service against attacks by flooding or replay.
  • the present invention also maintains the property of the protocol
  • IDDR-CEP regarding the small size of the protocol messages.
  • the entity B verifies, during step f) above, that the value of the transaction identifier IDTR N Si received is coherent with the individual secret key K SiB .
  • the entity B can authenticate the Authorization Server S (which is supposed to have authorized the current transaction.
  • said Authorization Servers use, to determine the successive transaction numbers N relative to a given entity B, an algorithm common to all the Authorization Servers of said group.
  • each entity B manages only one transaction window (as defined above), regardless of the number of Authorization Servers in said group.
  • the task of managing the entity B is greatly simplified, and this, especially since the number p of Authorization Servers is high.
  • the Authorization Servers of the group share a common transaction window with any given B entity.
  • these Authorization Servers can receive, a priori, requests requesting authorization to communicate with this entity B with a reception rate quite different from one Authorization Server to another.
  • a synchronization mechanism will preferably be provided to ensure that the transaction numbers N determined by the various Authorization Servers fall, under normal operating conditions, into the transaction window managed by the Entity B, and conversely, the transaction window managed by the entity B "slips" in concert with the Authorization Server S ( having the highest transaction rate.
  • the transaction number N determined, for a given entity B, by an authorization server S t any at a given time t d is a predetermined function of this instant t d and a reference number N B , the value of which is a secret shared by the entity
  • the width of the transaction window managed by the entity H at a given instant t d must reflect only the uncertainty on the corresponding instant t r at which the entity B receives the elements that the
  • the value of the reference number N B is updated periodically by means of a predetermined one-way function.
  • This first variant then has, essentially, the property known as "Forward Secrecy" in English, namely the property that the compromise of long-term secrets (private key or shared secret) should not allow an attacker to reconstruct the keys of session prior to this compromise. We can verify that this is the case here, even when the attacker is a corrupted Authorization Server. Indeed, if an attacker manages to compromise an Authorization Server S ( , he will have access to his individual secret key
  • the transaction number N determined, for a given entity B, by any Authorization Server S t is a predetermined sequencing function of the number of the previous transaction, and this Authorization Server S t sends to the entity B a synchronization message each time the Authorization Server S ( determines for the entity B a value of the transaction number belonging to a series of predetermined values.
  • the entity B which receives such synchronization messages from each of the Authorization Servers of the group, can then calibrate its transaction window according to the last transaction number N determined by the server. Authorization S t with the highest transaction rate.
  • this entity B may send synchronization messages to all the Authorization Servers in the group so that the Authorization Servers with the lowest transaction rates can update their current transaction number accordingly.
  • sequence of the transaction numbers N can, in this second variant, simply be the ascending order of the natural numbers, but one will preferably choose a one-way function for said sequencing function; indeed, this second variant will then advantageously have the property of "Forward Secrecy" mentioned above.
  • this integrity protection is achieved by means of said session key
  • Entity B will be able to ensure that the entity that sent them elements including a transaction identifier
  • IDTR N If valid has the session key K ⁇ B If associated with the current transaction.
  • said elements that the Authorization Server S ( send to the entity B during the step e) above also include a data CHECK ⁇ B Si depending on the transaction number N and deduced, by means of a cryptographic function dependent on a secret key K SiB check derived from said secret key K SiB , from a set of elements taken from said authorization request and, optionally, from the transaction number N.
  • the Authorization Server S can prove to the entity B that it authorized the transaction and to indicate the information on which it relied to do it.
  • the entity A sends to the entity B said identifier ID A of the entity A, or a derived identifier ID ' A used for example for the purposes of anonymity.
  • Entity B is informed of the identity of Entity A who initiated with it the transaction of number N.
  • said set of elements from which said data item CHECK ⁇ B Si is deduced comprises the identifier ID A of the entity A or the said derived identifier ID ' A , and - during the said step f), the entity B checks, at by means of said secret key K SiB check , the coherence between, on the one hand, the data CHECK ⁇ B If received (directly or indirectly) of the Authorization Server S t as described briefly above, and secondly said elements comprising the identifier ID A or the derived ID ' A received from the entity A as briefly described ci -above.
  • the entity B can verify that the entity A which is addressed to it has been authorized by the Authorization Server S t under the same identity ID A or ID ' A. This protects entity B against identity theft ("phishing").
  • the invention relates to various devices.
  • a device for securing communications in a telecommunications network during a transaction between an entity A and an entity B, comprising means for:
  • session key K ⁇ B Si being a one-way function of said individual secret key K SiB and also being a function of an integer N , called transaction number, assigned to said transaction,
  • a device 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:
  • said entity B further comprises a correspondence table relating at least one expected value of the transaction number with the associated precalculated filtering value.
  • the entity B can conveniently, by simple scanning of this correspondence table, deduce the current filtering value of the received transaction identifier, and then read the value of the transaction number associated with this current filter value.
  • entity B may conveniently, by simple polling of this correspondence table, read the filtering value associated with the current transaction number, which entity B has previously deduced from the received transaction identifier.
  • the invention also relates, thirdly, to a device, said entity A, for secure communications in a telecommunications network, comprising means for, during a transaction involving said entity A and an entity B:
  • said session key K ⁇ B Si being a one-way function of an individual secret key K SiB shared by the Authorization Server S t and said entity B, and also being a function of an integer N, called the transaction number, assigned to said transaction,
  • an IDTR transaction identifier N Si receiving from the authorization server S t an IDTR transaction identifier N Si , said transaction identifier IDTR N Si being a function of an IDTR filtering value N , of said individual secret key K SiB , and of an identifier ID Si of this Authorization Server S it and said filtering value IDTR N being a function dependent at least, in a non-invertible manner, of said transaction number N, and
  • This third device is therefore associated with the embodiment of the invention, briefly mentioned above, in which the transmission of the transaction identifier IDTR N Si of the Authorization Server S ( to the entity B is relayed by the entity A.
  • the invention also relates to a device combining the means of the last two devices described briefly above; such a device may, depending on the circumstances, behave either as a sending entity A or as a receiving entity B.
  • 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 remarkable in that it includes instructions for implementing said means included in any of the secure communication devices described briefly above.
  • FIG. 1 schematically represents a telecommunications network and the main entities to which the invention applies
  • FIG. 2 diagrammatically represents the steps of a secure communication method according to a first embodiment of the invention
  • FIG. 3 schematically represents the steps of a secure communication method according to a second embodiment of the invention.
  • the system illustrated in FIG. 1 comprises at least three entities interconnected via a communication network, for example an Internet type network.
  • 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.
  • Entities A and H 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.
  • server is, to simplify the description, used to designate uniformly any type of computing device, not just the computing devices conventionally referred to as “servers”.
  • entity A can act as server or relay for an entity A connected to the entity A; likewise, entity B can act as a server or relay for an entity H 'connected to entity B.
  • This entity S (can, of course, be composed in practice of several physical servers) belonging to a group of p Authorization Servers.
  • This entity S allows a subscriber entity A to address securely to another subscriber entity B, and it protects the entity B against the receipt of unwanted messages
  • the entity S t 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 or that entity B.
  • the Authorization Server S takes into account a sequence of integer values, called "transaction numbers", separately for each entity B.
  • the transaction number N makes it possible to order the transactions in which the entity B participates, but which are initiated by a subscriber entity other than entity B (or other than an entity for which, where appropriate, entity B serves as a server or relay) .
  • the sequence of transaction numbers N for a given entity B Only this entity B and the Authorization Server S t (or all of the Authorization Servers in the group) are known, and no transaction number is transmitted from one entity to another. Thanks to these provisions, it is impossible for an attacker to find the value of the transaction number relating to a subscriber entity in the secure communications service.
  • Transaction number transaction N must be authorized by the Authorization Server S-, following a request for authorization issued by the entity A to S In case of approval, the Authorization Server S ( responds to this authorization request by providing entity A with the information necessary to contact entity B.
  • the Authorization Server S t determines a long-term secret key K SiA that it shares with this entity A.
  • This long-term secret key K SiA allows to derive other secret keys that are used as needed to ensure the integrity or confidentiality of messages exchanged between A and
  • entities S t and B are able to independently generate, using publicly available algorithms, an IDTR filtering value N , which must depend on at least N and be generated by means of a an algorithm such that, if one or more IDTR values N used in previous transactions are known, it is not possible to deduce the current value of N, or an IDTR value N + i (i> 0).
  • the Authorization Server S t also generates an IDTR transaction identifier N Si , which is a function of said IDTR filtering value N , of said individual secret key K SiB , and an identifier ID Si of this server.
  • the entities S t and B are able to independently generate, using publicly available algorithms, the (primary) session key K ⁇ B Si used between the entities A and H for the current transaction and session; this session key must depend on at least N and K SiB, and be generated by means of an algorithm such that, even if we know the value of K ⁇ B Si and the value of N, we can not deduce the value of K SiB .
  • the primary session key (or transaction) K ⁇ B Si allows to derive other secret keys that are used as needed to ensure the integrity or confidentiality of messages exchanged between A and B.
  • the entity B precalculates the filtering values IDTR N for a predetermined sequence of values of the integer N.
  • the Authorization Servers S in the group will all preferably use the same algorithm to determine the successive transaction numbers N relative to this entity B, so that the entity B does not have to manage only one transaction window.
  • the chosen algorithm should preferably incorporate a synchronization mechanism vis-à-vis the various Authorization Servers S t , and this, to minimize the width of the transaction window.
  • the transaction number N determined, for a given entity B, by an authorization server S t any at a given time t d is a predetermined function of this instant t d and a reference number N B , the value of which is a secret shared by the entity B and by all the Authorization Servers S t of the group.
  • the instant t d is a time indication ("timestamp" in English) evaluated with a predetermined precision, for example to the nearest second.
  • the reference number N B its value is preferably periodically updated (for example, every 10 minutes) by means of a predetermined one-way function.
  • an Authorization Server S t may allow several transactions during the same unit of time t (corresponding to said predetermined precision).
  • the transaction identifier IDTR N Si and the session key K ⁇ B Si will also depend on a sub-transaction number j. It is furthermore possible to provide for the number of subtransactions per unit of time that an Authorization Server S can authorize ( can not exceed a predetermined value j max .
  • the transaction number N determined, for a given entity B, by an Authorization Server S ( any one is a predetermined sequencing function of the previous transaction number, and this authorization server S t sends to the entity B a synchronization message each time the authorization server S ( determines for the entity B a value of the transaction number belonging to a series of predetermined values (for example, every 10 transactions).
  • the entities S t of the group and B agree on an initial transaction number N B , which preferably varies from one entity B to another .
  • 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 in the secrets shared by the entities S t of the group and the entity B .
  • FIG. 2 diagrammatically represents the steps of a first embodiment of the method according to the invention, in which the transmission of the transaction ID IDTR N Si of the Authorization Server S t to the entity B is relayed by the entity A.
  • the present embodiment mainly relates to the secure implementation of a session key K ⁇ B Si between the entities A and H for the transaction number N, the subsequent use (for example, confidential transmission of multimedia streams , or electronic payment) that will make these entities A and H of this session key K ⁇ B Si during the session being independent of the invention.
  • sending client wishes to send an "original message” MES to one or more entity (s) B, called “recipient customer (s)” ( s) ".
  • recipient customer s
  • a new transaction is authenticated, and authorized, by an Authorization Server S ( of the group. More specifically, during a substep E1 .1, the entity A initiates a transaction by sending a request for authorization REQ to an Authorization Server S-, with which it shares a secret key K SiA .
  • This REQ authorization request contains at least INFO elements allowing the Authorization Server S t to authenticate the entity A, these elements comprising at least one identifier ID A of this entity.
  • the authorization request REQ may further contain information characterizing the message MES or identifying the entity B.
  • the authorization request REQ preferably contains a MAC1 authentication code calculated on all or part of the elements previously quoted from the REQ request.
  • K SiA secret key
  • Entity A does not completely know the identity of the recipient client of its original MES message; this identity is then determined by the Authorization Server S ( ;
  • the identifier ID A of the entity A is not revealed to the entity B, or that the entity A asks the authorization server S ( to present entity A to entity B under a "derived identifier" ID ' A , and
  • the identities of A or B may be replaced or supplemented by those of A 'or B' (see description of FIG. 1 above).
  • the Authorization Server S t decides, according to the information contained in this request, to authorize or not the transaction.
  • the Authorization Server S If the received REQ authorization request is associated with a MAC1 authentication code, the Authorization Server S ( then verifies the integrity of the elements of the REQ authorization request concerned.
  • the Authorization Server S t determines the identity of the customer (s) recipient (s) B (or B '). Finally, the Authorization Server S ( optionally checks the possible white or black lists of the entity B relative to the entity A, in the event that the entity B has declared, for example, to refuse any transaction with this entity In particular.
  • the Authorization Server S t then transmits to the entity A, during a step E2, a response authorization RESP containing at least the session key K ⁇ B Si .
  • the Authorization Server S sends to the entity A the session key K ⁇ B If in confidential form
  • This confidential form can for example be the result of the encryption of the session key K ⁇ B Si by means of an algorithm using said secret key K SiA or a key derived from this secret key K SiA
  • the session key K ⁇ B Si can then be computed by the entity A from this encrypted form by means of a decryption algorithm using the secret key K SiA or said key derived from the secret key K i; .
  • the Authorization Server S t also transmits, in this first embodiment, an IDTR transaction identifier N S T to the entity A, which will be responsible for retransmitting it to the entity B during the substep E3.2. described below.
  • the transaction identifier IDTR N Si is a function of the filtering value IDTR N , the individual secret key K SiB , and an identifier ID Si of the Authorization Server S t .
  • the filtering value IDTR N (long, for example, 16 bytes) is composed of at least two logical parts, namely V Q and V x , where the length of V 1 is equal to that of ID Si (by example, 8 bytes)
  • the transaction identifier IDTR N Si is the concatenation of at least three parts, namely P 0 , P 1 and P 2 ,
  • the part P 2 makes it possible to authenticate cryptographically the Authorization Server S it which has been previously identified by the value ID Si contained in P1.
  • the part P 2 protects P 0 and P 1 in integrity.
  • the part P 1 is obtained by masking a part V 1 of the filtering value IDTR N by means of the identifier ID Si .
  • This identifier ID Si is constant over time, but since the filtering value IDTR N changes with each transaction, P 1 also changes with each transaction, so that an attacker who does not know the transaction number N can not predict the following values of P x nor find ID If from Reading P x in step E4, described below, will allow entity B, by operation inverse to that which made it possible to calculate P x , to find the value ID Si contained in P x , and to verify the validity of the filtering value IDTR N and the identifier ID Si . This double verification can not be performed simultaneously: indeed, the entity B must first deduce the filter value IDTR N of the transaction identifier
  • t d denotes, let us recall, the time indication
  • entity B first calculates the transaction number N corresponding to this time indication, and verifies that it appears in the current transaction window; then the entity B recovers the pre-calculated IDTR filtering value N corresponding to this value of the transaction number.
  • the clock-based synchronization is chosen and the transactions are further characterized by a sub-transaction number j, the part P 2 of the transaction identifier IDTR N If will also depend on this sub-transaction number.
  • the RESP authorization response may also contain, for verification purposes, an INFO subset 'of the INFO information contained in the REQ authorization request.
  • the authorization response RESP may also contain a data CHECK ⁇ B If dependent on the transaction number N and deduced, by means of a cryptographic function dependent on a secret key K SiB check derived from said secret key K SiB , a set of elements taken from said REQ authorization request and, optionally, from the transaction number N. Note that to do this, we can consider (at least) two variants:
  • the variables to which said cryptographic function is applied comprise only elements taken from said authorization request; in this case, it is necessary for the secret key K SiB check to be a one-way function of the transaction number N (and the secret key K SiB );
  • the transaction number N is actually included in the variables to which said cryptographic function is applied; in this case, said secret key K SiB check does not necessarily depend on N, and must only be a one-way function of the secret key K SiB .
  • this cryptographic function will also depend on a random generated simultaneously, at each transaction, by the Authorization Server S t and Entity B (this hazard prevents a malicious A entity from finding the secret key K SiB check by inverting the data
  • the authorization response RESP preferably contains a MAC2 authentication code calculated on all or part of the elements previously In this case, we will use a secret key derived from the secret key K SiA , which we will note K SiA MAC2 .
  • the entity A receives the authorization response RESP from the Authorization Server S it and sends an "authenticated message" AM to the entity B.
  • the entity A after receiving the RESP authorization response, the entity A preferably performs the following checks:
  • the entity A verifies that this information corresponds to a REQ authorization request previously issued by she ; and if the received RESP authorization response is associated with a MAC2 authentication code, the entity A checks the integrity of the elements of the RESP authorization response concerned.
  • Entity A extracts the session key from the RESP authorization response.
  • Entity A then sends entity B an authenticated message
  • AM comprising the original message MES, the transaction identifier
  • the authenticated message AM preferably contains a MAC3 authentication code calculated on all or part of the aforementioned elements of this AM message. ; to do this, the session key K ⁇ B Si or a secret key K ⁇ B Si MAC3 derived from the session key K ⁇ B Si will advantageously be used.
  • the authenticated message AM will include the identifier ID A or the derived identifier ID ' A of the entity A.
  • This identifier can naturally, too, be part of said elements serving as a basis for calculating the MAC3 authentication code.
  • the authenticated message AM may be sent by an authorized entity other than the entity A itself, for example another network server.
  • the authenticated message AM is sent "directly" by the Authorization Server S t will be described below with reference to FIG.
  • the entity B receives the authenticated message AM and determines the session key. More specifically, during a substep E4.1, after receiving an authenticated message AM, the entity B obtains, as explained above, the current IDTR filtering value N and the current transaction number N to from the transaction ID IDTR N If received.
  • the entity B verifies:
  • the entity B retrieves or calculates the session key K ⁇ B Si , as well as, optionally, said secret key K SiB check and / or said secret key K ⁇ B Si MAC3 associated with this transaction.
  • Entity B then verifies that:
  • the information that the entity B has received is consistent with the authentication code MAC3 (if present) and the session key K ⁇ B Si or the secret key K ⁇ B If MAC3 , and / or
  • entity B extracts the original message MES of the authenticated message AM, and transmits, if necessary, this original message MES to a recipient client B '.
  • FIG. 3 schematically represents the steps of a second embodiment of the method according to the invention.
  • an entity A wishes to send to one or more entity (s) B, said (s) "client (s) recipient (s)” an original message MES.
  • this original message MES can, in certain applications (for example, if the MES message is a request for VoIP call initiation), simultaneously play the REQ authorization request role.
  • the present embodiment differs essentially from the first embodiment, described above with reference to FIG. 2, in that the Authorization Server S ( transmits the authenticated message
  • the first step ⁇ is similar to the step E1 of the first embodiment, except that the message MES must, in this second embodiment, be fully included in the authorization request REQ.
  • the second step E'2 is analogous to the step E2 of the first embodiment, except that the authorization response RESP contains here neither the transaction ID IDTR N Si nor the data CHECK ⁇ B Si .
  • the Authorization Server S t transmits "directly" to the entity B the authenticated message AM including the original message MES, the transaction identifier IDTR N Si and, optionally, the data CHECK ⁇ B Si .
  • the authenticated message AM preferably contains a MAC3 authentication code calculated on all or part of the aforementioned elements of this message.
  • step E'3 may precede step E'2.
  • This operating order advantageously makes it possible to interrupt the transaction before the Authorization Server S ( sends the RESP authorization response to the entity A, in the event that the entity B does not send an accused to S t receiving the authenticated message AM if such an acknowledgment was provided, or if the entity B sends to S ( an acknowledgment in which the entity B declares to refuse this transaction with the entity A.
  • step E'4 is analogous to step E4 of the first embodiment. Note that this step E'4 must naturally occur after step E'3, but it may precede step E'2.
  • 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 millions in some networks), terminal power, 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 which could then be a proxy of a network operator.
  • a trusted entity here, the Authorization Server which could then be a proxy of a network operator.
  • the client entities A and fi, as well as the Authorization Server S t 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 phase of the subscription. registration of the terminal-client to the network.
  • the REQ authorization request sent by the entity A allows the authorization server S t to authenticate the entity A and to determine the routing to reach the entity B.
  • the call can then be established directly between the entities A and H without it being necessary to establish a TLS connection between A and H to ensure the integrity and confidentiality of the signaling.
  • the message MES corresponds to the request "INVITE".
  • the sending and receiving entities are located in two distinct 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 D-EXP sending domain. Entity A serves several A 'client terminals of the D-EXP domain or transmitters A 'in the same domain, or in a third domain when the client terminal is in a mobility situation.
  • the Authorization Server S t is one of the incoming proxies of the destination domain D-DEST.
  • the Authorization Server S ( protects and serves one or more entity (s) B that may belong to the destination domain D-DEST or to third-party domains.
  • Entity B can correspond directly to the receiving client terminal.
  • the entity B may correspond to a receiving server, part of the recipient domain D-DEST or a third domain, in which case the real recipient client terminal corresponds to the entity B '.
  • the entity A references the recipient 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 SIPJJRI or TelJJRI designating the recipient client entity.
  • 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 SIPJJRI or Tel_URI designating the sending client entity.
  • 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”, "ACK”, "BYE” requests 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 sender server and a recipient server, while the AM message is sent by a sender or sender server to a receiving server.
  • the sending and receiving entities are located in two distinct 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 entity A is a sending server, then the real sending client is an entity.
  • the authorization server S t is one of the outgoing proxies of the sending domain D-EXP, that is to say a sender server.
  • the Authorization Server S t serves the A entities of the sender domain or third-party domains, and authorizes communications with the destination domain.
  • Entity B is one of the incoming proxies of the destination domain D-
  • 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.
  • the architecture is similar to that for VoIP interconnects (mode 1 or mode 2) with respect to the 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.
  • Performing the number N transaction allows A and H to share the primary session key K ⁇ B Si .
  • This session key is used to authenticate and ensure the integrity of the e-mail or IM message sent from A to B.
  • Entity A sends an authorization request to Authorization Server S (which protects access to entity B with which the entity
  • the authorization request comprises 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 H to share the primary session key K ⁇ B Si .
  • This session key is then used to establish a secure connection (IPSec, TLS, DTLS, or other) between the A and B entities.
  • This application of the method according to the invention relates to a connection service, where the Authorization Server S t is a server type
  • DNS or ENUM for 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.
  • the entity A is one of the outgoing proxies domain "domainel" and has a shared secret with the Authorization Server S
  • l entity A Before issuing a call to the entity B, l entity A sends an authorization request to the Authorization Server S to authenticate the caller and obtain a secret call key to B.
  • the Authorization Server S t is a server of the DNS / ENUM type which has shared secrets K SiA , K SiB with a certain number of domains, thanks to a prior connection phase.
  • the Authorization Server S t acts as a trusted third party.
  • Entity B is one of the incoming proxies in domain "domain2" and has a shared secret with the Authorization Server S
  • Entity B The completion of the transaction enables Entity B to verify that the Caller ID presented by Entity A in the INVITE request has been authenticated by the Authorization Server S t . It also allows the entities A and H to have a shared secret K ⁇ B Si that can be used to protect the rest of their exchange or media streams.
  • the implementation of the invention within the nodes of the telecommunications network can be implemented by means of components software and / or hardware.
  • 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.
  • this computer system can be used to execute a computer program comprising instructions for implementing the secure communications method according to the invention.
  • the invention also relates to a downloadable computer program from a communication network comprising instructions for executing at least some of the steps of a method of secure communications according to the invention, when 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 also relates to an information carrier, irremovable, or partially or completely removable, readable by a computer, and comprising instructions of a computer program as mentioned above.
  • the information carrier may be any entity or device capable of storing the program.
  • 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 USB flash drive ("USB flash drive"). in English) or a hard drive.
  • the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed 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.
  • 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.

Abstract

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

Description

PROCEDE ET DISPOSITIFS DE COMMUNICATIONS SECURISEES DANS UN RESEAU DE TELECOMMUNICATIONS
La présente invention concerne la sécurisation des communications dans un réseau de télécommunications.
Les réseaux de télécommunications, comme l'Internet, transmettent des données entre différentes entités réseau, telles qu'un serveur web ou un serveur de messagerie électronique, via une infrastructure commune. L'invention peut s'appliquer par exemple à l'accès sécurisé d'une entité réseau à une plateforme de service.
L'invention peut également s'appliquer, par exemple, à la transmission d'un « message original » d'une entité réseau à une ou plusieurs autre(s) entité(s) réseau ; par « message original », on entend ici un ensemble quelconque d'informations, par exemple un courrier électronique, ou une demande d'initiation d'appel VoIP (initiales des mots anglais « Voice over Internet Protocol » signifiant « Voix sur IP »), ou encore un « message instantané ». On dira de manière générale qu'un message original est envoyé par un « client expéditeur » rattaché à un domaine « expéditeur » et connecté à un domaine « émetteur », vers un « client destinataire » rattaché à un domaine « destinataire » et connecté à un domaine « récepteur » (dans le cadre de la présente invention, on dira qu'une entité est « rattachée » à un domaine réseau lorsque cette entité possède un lien de service et/ou logique et/ou administratif avec ce domaine ; dans le cas du courrier électronique, l'adresse logique correspond à l'adresse « email »). Le domaine émetteur peut ou non être distinct du domaine expéditeur, et le domaine récepteur peut ou non être distinct du domaine destinataire ; cette distinction entre domaines est utile, par exemple, lorsqu'un domaine émetteur relaie vers un client destinataire un message émis par un client expéditeur itinérant qui est connecté à ce domaine émetteur mais qui n'est pas rattaché au domaine émetteur.
Comme il est bien connu, les réseaux de télécommunications subissent des attaques à destination de cibles professionnelles, administratives ou individuelles. Une attaque courante de nos jours consiste à envoyer vers le plus grand nombre de destinataires possible des messages indésirables qu'ils n'ont pas sollicités, tels que des « spam » pour des courriers électroniques ou des « spit » pour des appels téléphoniques sur Internet. Le qualificatif « indésirable » est pris au sens large et s'applique à la fois à l'identité de l'expéditeur du message, qui peut être authentique ou falsifiée, et au contenu du message.
La possibilité d'attaques du type spam/spit repose notamment sur les facteurs suivants :
- la faiblesse des protocoles utilisés sur Internet, tels que le protocole SMTP (« Simple Mail Transfer Protocol » en anglais) le plus utilisé pour le transfert de courrier électronique et qui n'incorpore notamment pas de fonctions d'authentification de l'émetteur d'un courrier ;
- l'augmentation de la puissance des ordinateurs qui peuvent envoyer des messages indésirables en masse de façon automatique sur une période très courte ; et
- l'augmentation du nombre de réseaux ayant accès à Internet et de la connectivité entre ces réseaux, ce qui présente un très grand nombre de cibles à des attaquants qui peuvent s'abriter derrière des réseaux relativement permissifs ou hors de portée légale ou administrative des réseaux cibles.
De plus, il n'est pas aisé, pour un domaine émetteur du type « émetteur.fr », de déterminer si une adresse du type user@expéditeur.fr fournie par un client expéditeur itinérant connecté à ce domaine émetteur est valide, c'est-à-dire si l'adresse de ce client est effectivement attribuée dans le domaine « expéditeur.fr » et si ce client dispose des droits pour envoyer un message depuis cette adresse : en effet, le domaine émetteur ne gère pas les identités, c'est-à-dire les adresses logiques du type « expéditeur.fr ». Cette difficulté de contrôle est souvent utilisée par des attaquants pour émettre des messages sous une fausse identité depuis un domaine auquel les attaquants ont accès, ou bien via une machine corrompue située dans un domaine légitime. Par exemple, un domaine Internet « domaine.fr » créé par un attaquant peut tout-à-fait être utilisé pour émettre des appels VoIP avec une identité d'appelant +332abcdefqh(a)domaine.fr, alors qu'en fait le numéro d'abonné "+332abcdefgh" est attribué, disons, au domaine « orange.fr ». Face à ce genre d'attaque, le fait d'ajouter une signature numérique par le domaine appelant (cf. document RFC 4474 de l'IETF) est inefficace, car, si cela garantit au destinataire que l'appel provient bien de « domaine.fr », cela ne lui garantit pas que le numéro appelant est effectivement enregistré dans ce domaine.
Une solution à cette difficulté de contrôle consiste à bloquer dans le domaine émetteur l'envoi de tout message dont l'adresse d'origine n'est pas rattachée au domaine émetteur, mais cette solution est trop limitative, notamment pour la mobilité des services de VoIP qui permettent à un terminal itinérant d'utiliser un relais tiers tel qu'un domaine émetteur pour établir un appel téléphonique. Cette situation pose le problème de trouver des moyens permettant à un domaine destinataire de s'assurer que des contrôles suffisants ont été réalisés au niveau du domaine émetteur du message.
Dans le cadre de la présente invention, on appellera « transaction » l'ensemble des échanges protocolaires permettant l'établissement d'un secret partagé, ou « clé primaire de session », entre deux entités réseau A et H pour la durée d'une session. La transaction correspond à la phase d'initialisation de la session, cette session pouvant durer beaucoup plus longtemps que la transaction. Dans certaines parties de la description, les termes transaction et session pourront être considérés comme équivalents. Dans un souci de simplification, la clé primaire de session sera également notée « clé de session » entre A et B , indépendamment des opérations de dérivation ou de diversification qui peuvent lui être appliquées. Cette clé de session peut par exemple servir à la dérivation d'autres clés secrètes pour mettre en place une connexion sécurisée (TLS, IPSec, ou autre) entre les entités A et H . Comme autre exemple, cette clé de session peut permettre de garantir la confidentialité ou l'intégrité d'un message original envoyé par l'entité A (client expéditeur) à l'entité B (client destinataire) ; à chaque nouveau message original envoyé depuis un client expéditeur vers un ou plusieurs client(s) destinataire(s) correspond une nouvelle transaction ; à l'inverse, la répétition d'une étape protocolaire, par exemple du fait d'un problème réseau, n'est pas considérée comme une nouvelle transaction.
Une entité réseau peut évidemment, en principe, authentifier une autre entité réseau au moyen d'une infrastructure à clé publique PKI (« Public Key Infrastructure » en anglais). Mais comme il est bien connu, les infrastructures PKI sont lourdes à mettre en place et à utiliser.
En variante, certains procédés, tels que l'algorithme de Diffie- Hellman, prévoient la détermination commune d'une clé de session par deux entités préalablement à tout échange de messages originaux entre elles. Mais un tel algorithme ne donne, en lui-même, à une entité A aucune garantie sur l'identité d'une entité B avec laquelle elle établit ainsi une clé de session.
En variante, dans les réseaux comprenant un faible nombre d'usagers, tels que les réseaux de pairs, on peut prévoir une installation « manuelle » (par exemple par visite sur place) d'une clé secrète partagée pour chaque paire d'entités intéressées. Mais une telle installation ne convient pas aux réseaux comprenant un grand nombre d'usagers. On connaît aussi un protocole de communciations sécurisées appelé « IPACF » (voir l'article « Using Identity-Based Privacy-Protected Access Control FHter (IPACF) to Against Déniai of Service Attacks and Protect User Privacy », de C.-H. Wu et al., http://portal.acm.org/citation.cf m?id=1404806, 2007). Ce protocole est destiné à une architecture comprenant un ensemble d'entités A pouvant toutes communiquer de façon sécurisée avec une entité unique B ; en pratique, les entités A sont des clients et l'entité unique H est un serveur ou une entité de contrôle d'accès. Il existe un secret partagé distinct entre B et chacune des entités A .
Le protocole IPACF comprend trois phases : une phase de configuration initiale permettant la mise en place de secrets partagés, une phase d'authentification lors de l'établissement d'une nouvelle session, et enfin la phase de communication sécurisée proprement dite. Lors de cette phase de communication sécurisée, une entité A envoie une trame contenant un identifiant d'utilisateur (qui est fonction du secret partagé et d'un numéro de trame), ainsi qu'une valeur de filtrage (également fonction du secret partagé et du numéro de trame). L'entité B vérifie si l'identifiant reçu est valide par rapport à l'ensemble des identifiants possibles pour toutes les entités A à un instant donné ; le cas échéant, l'entité B vérifie la valeur de filtrage pour l'entité A identifiée. Le même principe s'applique lorsque B envoie une trame à A . Pour chaque trame reçue, l'entité A et l'entité B mettent à jour leurs valeurs d'identifiants et de filtrage.
Le protocole IPACF offre une bonne protection contre les attaques par inondation, puisque toute trame reçue par A ou H non associée à un identifiant et à une valeur de filtrage valides est rejetée. Cette vérification est triviale pour le récepteur, car il s'agit d'une comparaison avec des valeurs pré-calculées. Par ailleurs, ce protocole offre une bonne protection contre le rejeu, puisque les valeurs d'identifiant et de filtrage changent à chaque trame. Mais le protocole IPACF présente certains inconvénients. En premier lieu, le mécanisme est sensible aux pertes de trames, puisqu'à toute trame émise par A doit répondre une trame émise par B ; cet inconvénient est notamment gênant dans le cas d'un protocole de transport en mode non-connecté, où les paquets de signalisation peuvent arriver dans un ordre quelconque, et éventuellement se perdre en route. En second lieu, le mécanisme est « asymétrique » en ce sens que chaque entité A ne peut communiquer qu'avec une entité B avec laquelle elle dispose d'un secret partagé ; ainsi, il n'est pas possible d'envisager des communications sécurisées directes entre deux entités utilisateur A .
Un mécanisme « symétrique » bien adapté aux réseaux comprenant un grand nombre d'usagers consiste à mettre en place un tiers de confiance, communément appelé « Centre 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 la participation du Centre de Distribution de Clés. De plus, le Centre de Distribution de Clés peut selon les besoins transmettre de manière sécurisée des clés secrètes à des entités de support (stockage, passerelles, et ainsi de suite) placées sous son contrôle, ou à des entités légales pour l'interception de certaines communications. Comme le Centre de Distribution de Clés est le dépositaire de toutes les clés secrètes des abonnés, il est évidemment indispensable qu'il soit puissamment protégé contre les intrusions hostiles, mais cela ne représente pas de difficulté particulière. L'article intitulé « IDDR-CEP: Inter-Domain and DoS- Résistent Call Establishment Protocol » de P. Battistello (soumis pour la conférence IPTComm 2010) divulgue un tel protocole de communications sécurisées entre deux entités A et H abonnées au service. Ce protocole IDDR-CEP comprend essentiellement les étapes suivantes :
a) l'entité A envoie à un Serveur d'Autorisation S une requête d'autorisation dans laquelle l'entité A s'identifie et s'authentifie comme le détenteur d'un identifiant IDA ;
b) l'entité A déclare au Serveur d'Autorisation S son intention de communiquer avec une certaine entité B ; le Serveur d'Autorisation S détermine une clé secrète KSB qu'il partage avec cette entité B ;
c) le Serveur d'Autorisation S engendre une clé de session Κ Β , ladite clé de session K^B é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 ; puis le Serveur d'Autorisation S envoie ladite clé de session K^B à l'entité A ;
d) le Serveur d'Autorisation S engendre également une « valeur de filtrage » IDTRN , qui est une fonction dépendant au moins dudit numéro de transaction N de manière non-inversible ;
e) le Serveur d'Autorisation S fait parvenir à l'entité B des éléments comprenant au moins ladite valeur de filtrage IDTRN ;
f) l'entité B vérifie que la valeur de filtrage IDTRN reçue lors de ladite étape e) figure au sein d'un ensemble de valeurs précalculées par l'entité B et associées à au moins une valeur prévue du numéro de transaction, puis en déduit la valeur courante du numéro de transaction N ; et
g) l'entité B engendre la clé de session K^B . 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 K^B . Comme autre exemple, si l'entité B attend un document de la part de l'entité A , cette dernière pourra envoyer à l'entité B un message original accompagné du code « MAC » de ce message original obtenu au moyen de la clé de session K^B (on rappelle à cet égard que, de manière classique, un code d'authentification de message, appelé en anglais « Message Authentication Code », ou « MAC », est une valeur courte - généralement quelques dizaines de bits - déduite des données contenues dans un message et d'une clé secrète partagée entre l'émetteur et le récepteur du message à l'aide d'un algorithme cryptographique ; en envoyant un message accompagné de son code d'authentification, l'émetteur permet au récepteur de vérifier que ces données n'émanent pas d'une autre entité et n'ont pas été altérées entre leur émission et leur réception).
On bénéficie ainsi des avantages, mentionnés ci-dessus, des procédés de communications sécurisées du type « Centre de Distribution de Clés ». Notamment, on impose une vérification de l'authenticité de toute entité abonnée au service de communications sécurisées avant qu'elle ne s'adresse à une autre entité abonnée, afin d'offrir des garanties de sécurité à cette autre entité.
Par ailleurs, selon le protocole IDDR-CEP, l'entité B reçoit, lors de l'étape e) ci-dessus, la valeur de filtrage IDTRN de la part du Serveur d'Autorisation S . En outre, l'entité B calcule la valeur de filtrage IDTRN pour au moins une valeur N du numéro de transaction, cette valeur étant prévue pour faire suite, selon un algorithme prédéterminé, à une valeur utilisée dans une transaction précédente. Or, lorsque plusieurs transactions ont été autorisées sur une courte période par le Serveur d'Autorisation S pour une même entité B , il peut se produire que les éléments envoyés à cette entité B lors de ladite étape e) ne lui parviennent pas dans l'ordre des numéros de transaction N prescrits par l'algorithme. Pour résoudre ce problème, le protocole IDDR-CEP prévoit que, de préférence, l'entité B précalcule la valeur de filtrage IDTRN pour une séquence prédéterminée de plusieurs valeurs de l'entier N , et que, après réception d'une certaine valeur de filtrage IDTRN , l'entité B identifie, par scrutation dans cet ensemble de valeurs de IDTRN , à quel numéro de transaction N correspond la valeur de filtrage reçue.
On notera que la valeur de IDTRN est une fonction dépendant au moins de l'entier N de manière non-inversible, de sorte qu'il n'est pas possible de calculer la valeur de l'entier N à partir de la valeur de IDTRN en inversant cette fonction, ni de calculer l'une quelconque des valeurs IDTRN+i ( / > 0) en connaissant toute ou partie des valeurs précédentes IDTRN_j ( j≥0).
Grâce à ces dispositions, les entités abonnées au service de communications sécurisées sont avantageusement protégées contre les attaques par inondation ou par rejeu. En effet, l'entité B détecte une telle attaque facilement (c'est-à-dire en peu d'opérations de calcul) lorsqu'elle constate qu'une valeur reçue et censée représenter une valeur de filtrage IDTRN valide ne figure pas au sein dudit ensemble de valeurs précalculées (un attaquant a une chance infime de deviner une valeur de numéro de transaction N acceptable à un moment donné par une entité B donnée, de sorte que cet attaquant ne peut pas calculer une valeur de IDTRN acceptable, même si la façon dont la valeur de filtrage IDTRN est fonction de N est rendue publique). De plus, la taille (en nombre de bits) des messages protocolaires dans le protocole IDDR-CEP est avantageusement faible. En effet, d'une part, ni Serveur d'Autorisation S ni l'entité A n'ont à envoyer la clé de session K^B à l'entité B . D'autre part, la transmission de la valeur de filtrage IDTRN du Serveur d'Autorisation S à l'entité B lors de l'étape e) ci-dessus ne requiert pas non plus de message(s) de grande taille, car la valeur de filtrage IDTRN peut être une fonction de taille modeste (de manière caractéristique, quelques octets) tout en offrant une bonne sécurité sur le plan cryptographique.
Le protocole IDDR-CEP prévoit donc la mise en place d'un Serveur d'Autorisation S . Or il est souhaitable, dans de nombreux cas pratiques, de disposer d'une pluralité de Serveurs d'Autorisation St (où i = 1,2,..., p ) plutôt que d'un seul. Il peut s'agir par exemple :
- de besoins de redondance ; typiquement, les entités S( et B appartiennent au même domaine ou réseau, et le nombre d'entités St se limite à quelques unités de manière à assurer le partage de charge ou la redondance en cas de panne ; et/ou
- de besoins de service : typiquement, les entités S( et B appartiennent toutes à des domaines différents ; par exemple l'entité B est le proxy entrant du domaine « orange.fr », et chaque entité St est un proxy sortant d'un domaine tiers pouvant émettre des messages vers le domaine orange.fr.
Mais pour pouvoir réaliser cet objectif de Serveurs d'Autorisation multiples, il faut pouvoir résoudre toute une série de problèmes :
- l'entité B doit savoir lequel des Serveurs d'Autorisation St gère la transaction en cours, car, comme dans le protocole IDDR-CEP, il est fortement souhaitable que l'authentification de l'entité A soit de la responsabilité d'un Serveur d'Autorisation ; par conséquent, pour se défendre contre des attaques par usurpation d'identité, B doit pouvoir authentifier ce Serveur d'Autorisation, c'est-à-dire l'identifier (parmi les p serveurs du groupe) de manière sécurisée ;
- sauf cas particuliers (petit groupe de Serveurs d'Autorisation appartenant à un même domaine), il faut empêcher que l'un quelconque des Serveurs d'Autorisation du groupe ne puisse découvrir les éléments secrets utilisés par un quelconque autre Serveur d'Autorisation du groupe ;
- il est fortement souhaitable qu'un nombre quelconque k de Serveurs d'Autorisation S( distincts soient autorisés à gérer k transactions ayant toutes le même numéro de transaction N , et ceci, afin d'éviter que les Serveurs d'Autorisation S( du groupe ne soient obligés de se coordonner entre eux de manière à ce qu'il ne puisse y avoir, pour l'ensemble du groupe, qu'une seule transaction possible associée à un numéro de transaction N donné ; mais alors, par sécurité, et pour des besoins légaux (séquestre), il ne faut pas pas que deux transactions de même numéro de transaction N gérées par des Serveurs d'Autorisation distincts puissent engendrer la même clé de session ;
- il est fortement souhaitable que la taille des messages protocolaires soit suffisamment faible pour permettre l'utilisation d'un mode de transport non-connecté (par exemple, associé au protocole de signalisation SIP), dans lequel la taille nominale des messages de signalisation empêche l'insertion de données de grande taille ; et
- il est fortement souhaitable que le protocole puisse s'accommoder aisément d'une montée en charge (« scalability » en anglais) si l'on souhaite autoriser un grand nombre d'entités S( (par exemple, plusieurs centaines) à gérer des transactions impliquant une même entité B .
La présente invention concerne donc un procédé de communications sécurisées dans un réseau de télécommunications, ledit réseau comprenant un groupe de serveurs St (où i = 1,2,..., p , et p est un entier strictement positif), dits Serveurs d'Autorisation. Ce procédé comprend, pour une transaction entre une entité A et une entité B dudit réseau, les étapes suivantes :
a) l'entité A envoie à l'un des Serveurs d'Autorisation S( une requête d'autorisation dans laquelle l'entité A s'identifie et s'authentifie comme le détenteur d'un identifiant IDA ;
b) l'entité A déclare audit Serveur d'Autorisation S( son intention de communiquer avec l'entité B ; le Serveur d'Autorisation St détermine une clé secrète individuelle KSiB qu'il partage avec cette entité B ;
c) le Serveur d'Autorisation St engendre une clé de session K^B Si qui est une fonction à sens unique de ladite clé secrète individuelle KSiB , et est également fonction d'un entier N , appelé numéro de transaction, affecté à ladite transaction ; le Serveur d'Autorisation S'envoie ladite clé de session K^B Si à l'entité A ; d) le Serveur d'Autorisation St engendre également une valeur de filtrage IDTRN , qui est une fonction dépendant au moins dudit numéro de transaction N de manière non-inversible ; puis il engendre un identifiant de transaction IDTRN Si , qui est une fonction de ladite valeur de filtrage IDTRN , de ladite clé secrète individuelle KSiB , et d'un identifiant IDSi de ce Serveur d'Autorisation St ;
e) le Serveur d'Autorisation S( fait parvenir à l'entité B des éléments comprenant au moins ledit identifiant de transaction IDTRN Si ; f) à l'aide de l'identifiant de transaction IDTRN Si reçu lors de ladite étape e), l'entité B :
- identifie la valeur de filtrage IDTRN courante au sein d'un ensemble de valeurs de filtrage précalculées par l'entité B et associées à au moins une valeur prévue du numéro de transaction, et
- obtient l'identifiant de Serveur d'Autorisation IDSi , et en déduit la clé secrète individuelle KSiB correspondante ; et g) l'entité B engendre la clé de session K^B Si .
Il 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 à l'étape c).
On notera que l'invention s'applique à un nombre quelconque de Serveurs d'Autorisation (y compris un seul), mais elle est particulièrement avantageuse lorsque le nombre p de Serveurs d'Autorisation est élevé.
On notera également que l'évaluation de l'authenticité de l'entité A peut être effectuée par tout moyen d'authentification connu. De plus, cette évaluation peut être effectuée en s'adressant préalablement à un Serveur d'Authentification distinct du Serveur d'Autorisation S
On notera également qu'en pratique, et pour des besoins de séparation cryptographique, ce n'est pas nécessairement la clé (primaire) de session K^B Si qui sera utilisée pour le chiffrement des échanges entre les entités A et H , mais, le cas échéant, une ou plusieurs clé(s) dérivée(s) de K^B Si . Dans un souci de simplification, les clés dérivées d'une clé primaire ne seront pas systématiquement explicitées dans le présent document, mais une opération de dérivation ou de diversification selon l'état de l'art sera implicite dès lors qu'un même secret partagé sert à mettre en œuvre une pluralité de fonctions cryptographiques. Selon l'invention, donc, un Serveur d'Autorisation St détermine, pour une nouvelle transaction ayant une certaine entité B comme destinataire, un numéro de transaction N . Puis le Serveur d'Autorisation
S( fournit une clé de session K^B Si à l'entité A . Comme dans le protocole IDDR-CEP, l'entité B possède des moyens pour calculer elle- même cette clé de session ; selon la présente invention, l'entité B utilise pour ce faire une clé secrète individuelle KSiB , ainsi que le numéro de transaction courant N , dont l'entité B détermine la valeur après réception d'un « identifiant de transaction » IDTRN Si en provenance du Serveur d'Autorisation S- , soit directement, soit via une autre entité, qui peut avantageusement être l'entité A (cf. les modes de réalisation décrits en détail ci-dessous).
Chaque Serveur d'Autorisation S( détermine les numéros de transaction N successifs relatifs à une entité B donnée selon un algorithme prédéterminé (dont on donnera des exemples ci-dessous). L'entité B précalcule une « valeur de filtrage » IDTRN pour au moins une valeur du numéro de transaction N . Pour les mêmes raisons que dans le protocole IDDR-CEP, l'entité B précalcule de préférence les valeurs de filtrage IDTRN pour plusieurs valeurs prévues du numéro de transaction N (ce que, dans le cadre de la présente invention, on appellera une « fenêtre de transactions »). On notera à cet égard que les Serveurs d'Autorisation S( n'ont pas, quant à eux, besoin de gérer de fenêtre de transactions. On notera également que la séquence de numéros de transaction utilisée, conformément audit algorithme, par un Serveur d'Autorisation St donné pour une entité B donnée, est (sauf agencement particulier) indépendante de la séquence de numéros de transaction utilisée par le même Serveur d'Autorisation S( pour une autre entité B ; par conséquent, les fenêtres de transactions utilisées par les diverses entités B sont (sauf agencement particulier) mutuellement indépendantes.
L'identifiant de transaction IDTRN Si est une fonction de la valeur de filtrage IDTRN , de la clé secrète individuelle KSiB , et d'un identifiant IDSi de ce Serveur d'Autorisation S Comme il sera expliqué en détail ci- dessous, l'entité B obtient, après réception de l'identifiant de transaction IDTRN Si , la valeur de filtrage IDTRN courante par scrutation dans l'ensemble desdites valeurs de filtrage précalculées associées à la fenêtre de transactions courante. L'entité B en déduit ensuite l'identifiant IDSi . On notera que, contrairement au protocole IDDR-CEP, la valeur de filtrage IDTRN n'est pas transmise à l'entité B en clair, mais sous une forme plus ou moins partiellement masquée (cf. exemples de réalisation ci- dessous), et ce, afin d'empêcher qu'un attaquant (autre qu'un Serveur d'Autorisation corrompu distinct du présent Serveur d'Autorisation St ) ne puisse, à partir de l'identifiant de transaction IDTRN Si et de la valeur de filtrage IDTRN , obtenir l'identifiant IDSi du Serveur d'Autorisation S
L'entité B peut dès lors détecter une attaque facilement, c'est-à- dire en peu d'opérations de calcul, lorsqu'elle constate :
- que la valeur de l'identifiant de transaction IDTRN Si reçu n'est compatible avec aucune des valeurs de filtrage IDTRN précalculées, ou
- que la valeur IDSi déduite n'est l'identifiant d'aucun des Serveurs d'Autorisation du groupe, ou encore
- que ce Serveur d'Autorisation S( a déjà autorisé pour l'entité B une transaction précédente de même numéro N . L'invention offre donc avantageusement (comme le faisait le protocole IDDR-CEP, bien qu'avec d'autres moyens) une excellente protection des entités abonnées au service de communications sécurisées contre les attaques par inondation ou par rejeu.
La présente invention maintient également la propriété du protocole
IDDR-CEP concernant la faible taille des messages protocolaires. En effet, d'une part, ni Serveur d'Autorisation St ni l'entité A n'ont à envoyer la clé de session K^B Si à l'entité B ; d'autre part, la transmission (directe ou indirecte) de l'identifiant de transaction IDTRN Si à l'entité B lors de l'étape e) ci-dessus ne requiert pas de message(s) de grande taille, car l'identifiant de transaction IDTRN Si peut être une fonction de taille modeste (de manière caractéristique, quelques dizaines d'octets) tout en offrant une bonne sécurité sur le plan cryptographique.
Selon des caractéristiques particulières, l'entité B vérifie, lors de l'étape f) ci-dessus, que la valeur de l'identifiant de transaction IDTRN Si reçu est cohérente avec la clé secrète individuelle KSiB .
Grâce à ces dispositions, l'entité B peut authentifier le Serveur d'Autorisation S( qui est censé avoir autorisé la transaction courante.
Selon d'autres caractéristiques particulières, lesdits Serveurs d'Autorisation utilisent, pour déterminer les numéros de transaction N successifs relatifs à une entité B donnée, un algorithme commun à l'ensemble des Serveurs d'Autorisation dudit groupe.
Grâce à ces dispositions, chaque entité B ne gère qu'une seule fenêtre de transactions (telle que définie ci-dessus), quel que soit le nombre de Serveurs d'Autorisation dans ledit groupe. La tâche de gestion de l'entité B est donc grandement simplifiée, et ce, d'autant plus que le nombre p de Serveurs d'Autorisation est élevé. Dans ces conditions, les Serveurs d'Autorisation du groupe partagent une fenêtre de transactions commune avec toute entité B donnée. Or ces Serveurs d'Autorisation peuvent recevoir, a priori, des requêtes demandant l'autorisation de communiquer avec cette entité B avec un débit de réception tout-à-fait différent d'un Serveur d'Autorisation à l'autre. On prévoira donc, de préférence, un mécanisme de synchronisation destiné à garantir que les numéros de transaction N déterminés par les divers Serveurs d'Autorisation tombent, dans des conditions de fonctionnement normales, à l'intérieur de la fenêtre de transactions gérée par l'entité B , et que, inversement, la fenêtre de transactions gérée par l'entité B « glisse » de concert avec le Serveur d'Autorisation S( ayant le débit de transactions le plus élevé.
Selon une première variante (qui sera appellée « synchronisation à base d'horloge » ci-après), le numéro de transaction N déterminé, pour une entité B donnée, par un Serveur d'Autorisation St quelconque à un instant td donné est une fonction prédéterminée de cet instant td et d'un numéro de référence NB , dont la valeur est un secret partagé par l'entité
B et par l'ensemble des Serveurs d'Autorisation du groupe.
Grâce à ces dispositions, la largeur de la fenêtre de transactions gérée par l'entité H à un instant td donné ne doit refléter que l'incertitude sur l'instant tr correspondant auquel l'entité B reçoit les éléments que le
Serveur d'Autorisation St lui a fait parvenir conformément à l'étape e) du procédé selon l'invention. Cette incertitude résulte, d'une part, des délais de transmission (directe ou indirecte, rappelons-le) de ces éléments, et d'autre part des limitations techniques dans la synchronisation des horloges internes respectives de l'entité B et du Serveur d'Autorisation Sr Somme toute, cette incertitude, et donc la largeur de la fenêtre de transactions, est habituellement assez faible, de sorte que le nombre de valeurs de filtrage qu'une entité B doit précalculer est avantageusement petit.
De préférence, la valeur du numéro de référence NB est mise à jour périodiquement au moyen d'une fonction à sens unique prédéterminée.
Cette première variante possède alors, essentiellement, la propriété dite « Forward Secrecy » en anglais, à savoir la propriété selon laquelle la compromission de secrets à long terme (clé privée ou secret partagé) ne doit pas permettre à un attaquant de reconstituer les clés de session antérieures à cette compromission. On peut vérifier que c'est bien le cas en l'occurrence, même lorsque l'attaquant est un Serveur d'Autorisation corrompu. En effet, si un attaquant parvient à compromettre un Serveur d'Autorisation S( , il aura accès à sa clé secrète individuelle
KSiB , ainsi qu'à la valeur courante du numéro de transaction N , ce qui lui permet de calculer la clé de session K^B Si associée à la transaction courante ainsi qu'aux transactions suivantes gérées par ce Serveur d'Autorisation S( corrompu. Cependant, comme la mise à jour du numéro de référence NB est réalisée au moyen d'une fonction à sens unique, cet attaquant n'aura pas accès aux valeurs du numéro de transaction N antérieures à la dernière mise à jour. On peut donc, selon la période choisie pour la mise à jour du numéro de référence NB , ajuster la sécurité offerte par le système, c'est-à-dire la durée antérieure pendant laquelle la propriété « Forward Secrecy » n'est pas assurée en cas de compromission.
Selon une deuxième variante (qui sera appellée « synchronisation à base de messages réseau » ci-après), le numéro de transaction N déterminé, pour une entité B donnée, par un Serveur d'Autorisation St quelconque est une fonction de séquencement prédéterminée du numéro de transaction précédent, et ce Serveur d'Autorisation St envoie à l'entité B un message de synchronisation à chaque fois que le Serveur d'Autorisation S( détermine pour l'entité B une valeur du numéro de transaction appartenant à une série de valeurs prédéterminées.
Grâce à ces dispositions, l'entité B , qui reçoit de tels messages de synchronisation de la part de chacun des Serveurs d'Autorisation du groupe, peut alors caler sa fenêtre de transactions en fonction du dernier numéro de transaction N déterminé par le Serveur d'Autorisation St ayant le débit de transactions le plus élevé. De plus, cette entité B peut envoyer des messages de synchronisation à l'ensemble des Serveurs d'Autorisation du groupe afin que les Serveurs d'Autorisation ayant les débits de transaction les plus faibles puissent mettre à jour leur numéro de transaction courant en conséquence.
La séquence des numéros de transaction N peut, dans cette deuxième variante, être simplement l'ordre croissant des entiers naturels, mais on choisira, de préférence, une fonction à sens unique pour ladite fonction de séquencement ; en effet, cette deuxième variante possédera alors, avantageusement, la propriété de « Forward Secrecy » mentionnée ci-dessus.
Selon d'autres caractéristiques particulières, tout ou partie desdits éléments envoyés à l'entité B lors l'étape e) ci-dessus sont protégés en intégrité.
Grâce à ces dispositions, on protège ces éléments contre toute altération ; or une telle altération ferait échouer la transaction dans la plupart des cas. Cette protection en intégrité peut notamment être réalisée au moyen d'un code MAC.
Selon des caractéristiques encore plus particulières, cette protection en intégrité est réalisée au moyen de ladite clé de session
K B Ç. ou d'une clé dérivée de cette clé de session K B,; . Grâce à ces dispositions, l'entité B pourra s'assurer que l'entité qui lui a envoyé des éléments comprenant un identifiant de transaction
IDTRN Si valide dispose bien de la clé de session K^B Si associée à la transaction courante. Ces dispositions permettent également d'adresser les identifiants de transaction IDTRN Si à l'entité B en clair par mesure de simplicité.
Selon encore d'autres caractéristiques particulières, lesdits éléments que le Serveur d'Autorisation S( fait parvenir à l'entité B lors de l'étape e) ci-dessus comprennent également une donnée CHECK^B Si dépendant du numéro de transaction N et déduite, au moyen d'une fonction cryptographique dépendant d'une clé secrète KSiB check dérivée de ladite clé secrète KSiB , d'un ensemble d'éléments tirés de ladite requête d'autorisation et, optionnellement, du numéro de transaction N .
Grâce à ces dispositions, le Serveur d'Autorisation S( peut prouver à l'entité B qu'il a bien autorisé la transaction et lui indiquer les informations sur lesquelles il s'est appuyé pour le faire.
Selon encore d'autres caractéristiques particulières, l'entité A fait parvenir à l'entité B ledit identifiant IDA de l'entité A , ou un identifiant dérivé ID'A utilisé par exemple pour des besoins d'anonymat.
Grâce à ces dispositions, l'entité B est informée de l'identité de l'entité A qui a initié avec elle la transaction de numéro N .
Selon des caractéristiques encore plus particulières :
- ledit ensemble d'éléments dont est déduite ladite donnée CHECK^B Si comprend l'identifiant IDA de l'entité A ou ledit identifiant dérivé ID'A , et - lors de ladite étape f), l'entité B vérifie, au moyen de ladite clé secrète KSiB check , la cohérence entre, d'une part, la donnée CHECK^B Si reçue (directement ou indirectement) du Serveur d'Autorisation St comme décrit succinctement ci-dessus, et d'autre part lesdits éléments comprenant l'identifiant IDA ou l'identifiant dérivé ID'A reçus de l'entité A comme décrit succinctement ci-dessus.
Grâce à ces dispositions, l'entité B peut vérifier que l'entité A qui s'adresse à elle a bien été autorisée par le Serveur d'Autorisation St sous la même identité IDA ou ID'A . On protège ainsi l'entité B contre les usurpations d'identité (« phishing » en anglais).
Corrélativement, l'invention concerne divers dispositifs.
Elle concerne ainsi, premièrement, un dispositif, dit Serveur d'Autorisation, pour sécuriser les communications dans un réseau de télécommunications lors d'une transaction entre une entité A et une entité B , comprenant des moyens pour :
- identifier et authentifier une entité A détentrice d'un identifiant IDA ,
- déterminer une clé secrète individuelle KSiB que ledit Serveur d'Autorisation S( (où i = 1,2,..., p , et p est un entier strictement positif) partage avec une entité B avec laquelle l'entité A déclare son intention de communiquer,
- engendrer une clé de session K^B Si et l'envoyer à l'entité A , ladite clé de session K^B Si étant une fonction à sens unique de ladite clé secrète individuelle KSiB et étant également fonction d'un entier N , appelé numéro de transaction, affecté à ladite transaction,
- engendrer une valeur de filtrage IDTRN , qui est une fonction dépendant au moins dudit numéro de transaction N de manière non- inversible, - engendrer un identifiant de transaction IDTRN Si , qui est une fonction de ladite valeur de filtrage IDTRN , de ladite clé secrète individuelle KSiB , et d'un identifiant IDSi de ce Serveur d'Autorisation S- , et
- faire parvenir à ladite entité B des éléments comprenant au moins ledit identifiant de transaction IDTRN Si .
Elle concerne aussi, deuxièmement, un dispositif, dit entité B , de communications sécurisées dans un réseau de télécommunications, caractérisé en ce qu'il comprend des moyens pour, lors d'une transaction impliquant ladite entité B et une entité A :
- recevoir des éléments comprenant au moins un identifiant de transaction IDTRN Si engendré par un Serveur d'Autorisation St (où i = \,2,..., p , et p est un entier strictement positif), ledit identifiant de transaction IDTRN Si étant une fonction d'une valeur de filtrage IDTRN , d'une clé secrète individuelle KSiB partagée par l'entité B et ledit Serveur d'Autorisation Si t et d'un identifiant IDSi de ce Serveur d'Autorisation Si t et ladite valeur de filtrage IDTRN étant une fonction dépendant au moins, de manière non-inversible, d'un entier N , appelé numéro de transaction, affecté à ladite transaction,
- à l'aide dudit identifiant de transaction IDTRN Si ,
• identifier la valeur de filtrage IDTRN courante au sein d'un ensemble de valeurs de filtrage précalculées par l'entité B et associées à au moins une valeur prévue du numéro de transaction, et
· obtenir l'identifiant de Serveur d'Autorisation IDSi , et en déduire la clé secrète individuelle KSiB correspondante, et - engendrer une clé de session KN Si qui est, d'une part, fonction dudit numéro de transaction N , et d'autre part une fonction à sens unique de ladite clé secrète individuelle KSiB .
Selon des caractéristiques particulières, ladite entité B comprend en outre une table de correspondance mettant en relation au moins une valeur prévue du numéro de transaction avec la valeur de filtrage précalculée associée.
Grâce à ces dispositions (cf. modes de réalisation ci-dessous), l'entité B peut commodément, par simple scrutation de cette table de correspondance, déduire la valeur de filtrage courante de l'identifiant de transaction reçu, puis lire la valeur du numéro de transaction associée à cette valeur de filtrage courante. Inversement, l'entité B peut commodément, par simple scrutation de cette table de correspondance, lire la valeur de filtrage associée au numéro de transaction courant, que l'entité B a préalablement déduit de l'identifiant de transaction reçu.
L'invention concerne aussi, troisièmement, un dispositif, dit entité A , de communications sécurisées dans un réseau de télécommunications, comprenant des moyens pour, lors d'une transaction impliquant ladite entité A et une entité B :
- s'identifier et s'authentifier comme le détenteur d'un identifiant IDA auprès d'un Serveur d'Autorisation St (où i = 1,2,..., p , et p est un entier strictement positif),
- déclarer audit Serveur d'Autorisation S( son intention de communiquer avec une certaine entité B ,
- recevoir de la part du Serveur d'Autorisation St une clé de session
K^B Si , ladite clé de session K^B Si étant une fonction à sens unique d'une clé secrète individuelle KSiB partagée par le Serveur d'Autorisation St et ladite entité B , et étant également fonction d'un entier N , appelé numéro de transaction, affecté à ladite transaction,
- recevoir de la part du Serveur d'Autorisation St un identifiant de transaction IDTRN Si , ledit identifiant de transaction IDTRN Si étant une fonction d'une valeur de filtrage IDTRN , de ladite clé secrète individuelle KSiB , et d'un identifiant IDSi de ce Serveur d'Autorisation Si t et ladite valeur de filtrage IDTRN étant une fonction dépendant au moins, de manière non-inversible, dudit numéro de transaction N , et
- envoyer à l'entité B des éléments comprenant au moins ledit identifiant de transaction IDTRN Si .
Ce troisième dispositif est donc associé au mode de réalisation de l'invention, brièvement mentionné ci-dessus, dans lequel la transmission de l'identifiant de transaction IDTRN Si du Serveur d'Autorisation S( à l'entité B est relayée par l'entité A .
L'invention concerne également un dispositif cumulant les moyens des deux derniers dispositifs décrits succinctement ci-dessus ; un tel dispositif peut se comporter, selon les circonstances, soit comme une entité expéditrice A , soit comme une entité destinataire B .
Les avantages offerts par ces dispositifs sont essentiellement les 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 œuvre 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 œuvre desdits moyens compris dans l'un quelconque des dispositifs de communications sécurisées décrits succinctement ci-dessus.
Les avantages offerts par ce programme d'ordinateur sont essentiellement les mêmes que ceux offerts par lesdits dispositifs.
D'autres aspects et avantages de l'invention apparaîtront à la lecture de la description détaillée ci-dessous de modes de réalisation particuliers, donnés à titre d'exemples non limitatifs. La description se réfère aux figures qui l'accompagnent, dans lesquelles :
- la figure 1 représente schématiquement un réseau de télécommunications et les principales entités auxquelles s'applique l'invention,
- la figure 2 représente schématiquement les étapes d'un procédé de communications sécurisées selon un premier mode de réalisation de l'invention, et
- la figure 3 représente schématiquement les étapes d'un procédé de communications sécurisées selon un deuxième mode de réalisation de l'invention.
Le système illustré sur la figure 1 comprend au moins trois entités interconnectées via un réseau de communication, par exemple un réseau de type Internet. Le procédé est particulièrement avantageux dans le cas d'un mode de transport non-connecté, mais convient également à un mode de transport connecté.
Les entités A et H sont abonnées au même service de communications sécurisées. Elles utilisent chacune, de manière classique, un terminal ou un serveur apte à émettre ou recevoir des messages de nature quelconque tels que, par exemple, des courriers électroniques ou des appels téléphoniques sur des canaux fixes ou mobiles. On notera que, dans le cadre de la présente invention, le mot « serveur » est, pour simplifier l'exposé, utilisé pour désigner uniformément tout type de dispositif informatique, et non uniquement les dispositifs informatiques classiquement désignés sous le nom de « serveurs ».
En pratique, l'entité A peut jouer le rôle de serveur ou relais pour une entité A connectée à l'entité A ; de même, l'entité B peut jouer le rôle de serveur ou relais pour une entité H' connectée à l'entité B .
L'entité St (où i = 1,2,..., p ) est un « Serveur d'Autorisation »
(pouvant, naturellement, être composé en pratique de plusieurs serveurs physiques) appartenant à un groupe de p Serveurs d'Autorisation. Cette entité S( permet à une entité abonnée A de s'adresser de manière sécurisée à une autre entité abonnée B ; de plus, elle protège l'entité B contre la réception de messages indésirables. Suivant les applications et les scénarios de déploiement (cf. exemples ci-dessous), l'entité St 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 . Le numéro de transaction N permet d'ordonner les transactions auxquelles participe l'entité B , mais qui sont initiées par une entité abonnée autre que l'entité B (ou autre qu'une entité pour laquelle, le cas échéant, l'entité B sert de serveur ou de relais). La séquence des numéros de transaction N pour une entité B donnée n'est connue que de cette entité B et du Serveur d'Autorisation St (ou de l'ensemble des Serveurs d'Autorisation du groupe) ; de plus, aucun numéro de transaction n'est transmis d'une entité à une autre. Grâce à ces dispositions, il est impossible pour un attaquant de trouver la valeur courante du numéro de transaction relatif à une entité abonnée au service de communications sécurisées.
La transaction de numéro de transaction N doit être autorisée par le Serveur d'Autorisation S- , suite à une requête d'autorisation émise par l'entité A vers S En cas d'approbation, le Serveur d'Autorisation S( répond à cette requête d'autorisation en fournissant à l'entité A les informations nécessaires pour entrer en contact avec l'entité B .
Lors de chaque transaction, suite à une identification de l'entité A , le Serveur d'Autorisation St détermine une clé secrète à long terme KSiA qu'il partage avec cette entité A . Cette clé secrète à long terme KSiA permet de dériver d'autres clés secrètes qui sont utilisées au besoin pour assurer l'intégrité ou la confidentialité des messages échangés entre A et
De même, il existe un secret partagé à long terme KSiB entre l'entité B et chacun des Serveurs d'Autorisation S Cette clé secrète à long terme KSiB permet de dériver d'autres clés secrètes qui sont utilisées au besoin pour assurer l'intégrité ou la confidentialité des messages échangés (directement ou indirectement) entre St et B .
Pour toute transaction de numéro N , les entités St et B sont capables d'engendrer indépendamment, en utilisant des algorithmes pouvant être publics, une valeur de filtrage IDTRN , qui doit dépendre au moins de N et être engendrée au moyen d'un algorithme tel que, si l'on connaît une ou plusieurs valeurs IDTRN utilisées dans des transactions précédentes, on ne peut pas en déduire la valeur courante de N , ou une valeur IDTRN+i ( i > 0). Le Serveur d'Autorisation St engendre en outre un identifiant de transaction IDTRN Si , qui est une fonction de ladite valeur de filtrage IDTRN , de ladite clé secrète individuelle KSiB , et d'un identifiant IDSi de ce Serveur d'Autorisation S(
De plus, les entités St et B sont capables d'engendrer indépendamment, en utilisant des algorithmes pouvant être publics, la clé (primaire) de session K^B Si utilisée entre les entités A et H pour la transaction et la session courantes ; cette clé de session doit dépendre au moins de N et de KSiB , et être engendrée au moyen d'un algorithme tel que, même si l'on connaît la valeur de K^B Si et la valeur de N , on ne peut pas en déduire la valeur de KSiB .
De manière classique, la clé primaire de session (ou de transaction) K^B Si 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 .
De préférence, l'entité B précalcule les valeurs de filtrage IDTRN pour une séquence prédéterminée de valeurs de l'entier N . Dans ce cas, les Serveurs d'Autorisation S( du groupe utiliseront tous, de préférence, le même algorithme pour déterminer les numéros de transaction N successifs relatifs à cette entité B , de manière à ce que l'entité B n'ait à gérer qu'une seule fenêtre de transactions.
Divers algorithmes peuvent être choisis à cet effet, mais l'algorithme choisi devra de préférence incorporer un mécanisme de synchronisation vis-à-vis des divers Serveurs d'Autorisation St , et ce, afin de minimiser la largeur de la fenêtre de transactions. Par exemple, dans la « synchronisation à base d'horloge », le numéro de transaction N déterminé, pour une entité B donnée, par un Serveur d'Autorisation St quelconque à un instant td donné est une fonction prédéterminée de cet instant td et d'un numéro de référence NB , dont la valeur est un secret partagé par l'entité B et par l'ensemble des Serveurs d'Autorisation St du groupe. L'instant td est une indication horaire (« timestamp » en anglais) évaluée avec une précision prédéterminée, par exemple à la seconde près. Quant au numéro de référence NB , sa valeur est de préférence mise à jour périodiquement (par exemple, toutes les 10 minutes) au moyen d'une fonction à sens unique prédéterminée.
Par ailleurs, il est souhaitable dans certains cas (par exemple, pour les applications en temps-réel) qu'un Serveur d'Autorisation St puisse autoriser plusieurs transactions pendant une même unité de temps t (correspondant à ladite précision prédéterminée). Dans ce cas, l'identifiant de transaction IDTRN Si et la clé de session K^B Si dépendront également d'un numéro de sous-transaction j . On pourra de plus prévoir que le nombre de sous-transactions par unité de temps que peut autoriser un Serveur d'Autorisation S( ne peut pas dépasser une valeur prédéterminée jmax .
Comme autre exemple, dans la « synchronisation à base de messages réseau », le numéro de transaction N déterminé, pour une entité B donnée, par un Serveur d'Autorisation S( quelconque est une fonction de séquencement prédéterminée du numéro de transaction précédent, et ce Serveur d'Autorisation St envoie à l'entité B un message de synchronisation à chaque fois que le Serveur d'Autorisation S( détermine pour l'entité B une valeur du numéro de transaction appartenant à une série de valeurs prédéterminées (par exemple, toutes les 10 transactions).
Dans cette deuxième variante, à l'initialisation du système de la figure 1 , les entités St du groupe et B se mettent d'accord sur un numéro de transaction initial NB , qui varie de préférence d'une entité B à une autre. Ensuite, à chaque transaction, le numéro de transaction N est modifié selon un algorithme pouvant être public ; par exemple, N peut être incrémenté de 1 à chaque nouvelle transaction, mais cet algorithme peut également varier d'une entité B à une autre, auquel cas il doit figurer dans les secrets partagés par les entités St du groupe et l'entité B .
La figure 2 représente schématiquement les étapes d'un premier mode de réalisation du procédé selon l'invention, dans lequel la transmission de l'identifiant de transaction IDTRN Si du Serveur d'Autorisation St à l'entité B est relayée par l'entité A .
Le présent mode de réalisation a principalement pour objet la mise en place sécurisée d'une clé de session K^B Si entre les entités A et H pour la transaction de numéro N , l'usage subséquent (par exemple, transmission confidentielle de flux multimédias, ou paiement électronique) que feront ces entités A et H de cette clé de session K^B Si au cours de la session étant indépendant de l'invention.
Pour fixer les idées, on supposera qu'une entité A , dite « client expéditeur », souhaite envoyer un « message original » MES à une, ou plusieurs, entité(s) B , dite(s) « client(s) destinataire(s) ». On va décrire à présent les étapes principales de ce mode de réalisation.
Lors d'une première étape E1 , une nouvelle transaction est authentifiée, et autorisée, par un Serveur d'Autorisation S( du groupe. Plus précisément, lors d'une sous-étape E1 .1 , l'entité A initie une transaction en envoyant une requête d'autorisation REQ à un Serveur d'Autorisation S- , avec qui elle partage une clé secrète KSiA . Cette requête d'autorisation REQ contient au moins des éléments INFO permettant au Serveur d'Autorisation St d'authentifier l'entité A , ces éléments comprenant au moins un identifiant IDA de cette entité.
La requête d'autorisation REQ peut contenir en outre des informations caractérisant le message MES ou permettant d'identifier l'entité B .
Enfin, lorsque l'intégrité des échanges entre A et St n'est pas assurée par le protocole de transport sous-jacent, la requête d'autorisation REQ contient de préférence un code d'authentification MAC1 calculé sur tout ou partie des éléments précédemment cités de la requête REQ. Pour ce faire, on utilisera une clé secrète dérivée de la clé secrète KSiA , que l'on notera KSiA MAC1.
On notera également, concernant les identités des entités A et H , 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 E1 .2, sur réception de la requête d'autorisation REQ, le Serveur d'Autorisation St décide, en fonction des informations contenues dans cette requête, d'autoriser ou non la transaction.
Si la requête d'autorisation REQ reçue est associée à un code d'authentification MAC1 , le Serveur d'Autorisation S( vérifie alors l'intégrité des éléments de la requête d'autorisation REQ concernés.
Si besoin, le Serveur d'Autorisation St détermine l'identité du, ou des, client(s) destinataire(s) B (ou B' ). Enfin, le Serveur d'Autorisation S( vérifie, optionnellement, les éventuelles listes blanches ou noires de l'entité B relativement à l'entité A , au cas où l'entité B aurait déclaré, par exemple, refuser toute transaction avec cette entité A en particulier.
Si la transaction est autorisée, le Serveur d'Autorisation St transmet alors à l'entité A , lors d'une étape E2, une réponse d'autorisation RESP contenant au moins la clé de session K^B Si .
Lorsque la confidentialité des échanges entre le Serveur d'Autorisation St 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 K^B Si sous une forme confidentielle. Cette forme confidentielle peut par exemple être le résultat du chiffrement de la clé de session K^B Si au moyen d'un algorithme utilisant ladite clé secrète KSiA ou une clé dérivée de cette clé secrète KSiA . La clé de session K^B Si pourra alors être calculée par l'entité A à partir de cette forme chiffrée au moyen d'un algorithme de déchiffrement utilisant la clé secrète KSiA ou ladite clé dérivée de la clé secrète K,;i . Le Serveur d'Autorisation St transmet également, dans ce premier mode de réalisation, un identifiant de transaction IDTRN Si à l'entité A , qui se chargera de le retransmettre à l'entité B lors de la sous-étape E3.2 décrite ci-dessous.
On notera qu'il est possible, optionnellement, de transmettre l'identifiant de transaction IDTRN Si en clair. Néanmoins, dans le cas où la confidentialité des échanges entre le Serveur d'Autorisation St et l'entité A n'est pas assurée par le protocole de transport sous-jacent, si un attaquant était capable de lire sa valeur, il pourrait envoyer très rapidement à l'entité B un ou plusieurs messages invalides de façon à ce qu'ils soient reçus par l'entité B avant le message légitime émis par l'entité A . L'entité B détecterait en fait une telle attaque, mais seulement après voir procédé à des vérifications supplémentaires (voir ci-dessous) car la valeur de l'identifiant de transaction IDTRN Si lui paraîtrait correcte. L'entité B serait donc exposée à un risque d'attaque par inondation. Aussi, dans le cas considéré, le Serveur d'Autorisation St enverra à l'entité A l'identifiant de transaction IDTRN Si de préférence chiffré ou masqué de manière connue, en utilisant pour ce faire la clé secrète KSiA ou une clé secrète dérivée de cette clé secrète KSiA .
Comme mentionné ci-dessus, l'identifiant de transaction IDTRN Si est une fonction de la valeur de filtrage IDTRN , de la clé secrète individuelle KSiB , et d'un identifiant IDSi du Serveur d'Autorisation St . On va donner à présent des exemples de réalisation de cette fonction. Dans ces exemples : - la valeur de filtrage IDTRN (longue, par exemple, de 16 octets) est composée d'au moins deux parties logiques, à savoir VQ et Vx , où la longueur de V1 est égale à celle de IDSi (par exemple, 8 octets),
- l'identifiant de transaction IDTRN Si est la concaténation d'au moins trois parties, à savoir P0 , P1 et P2 ,
- la partie P1 vaut
XOR IDSi ,
où le symbole « XOR » désigne l'addition bit à bit (opération « ou exclusif »), et
- la partie P2 vaut
P2 = HMAC ( P0 I P ,
où le symbole « (...| ...) » désigne la concaténation, et où HMAC est une fonction cryptographique dépendant de la clé secrète individuelle KSiB .
Ainsi, la partie P2 permet d'authentifier de façon cryptographique le Serveur d'Autorisation Si t qui a été préalablement identifié grâce à la valeur IDSi contenue dans P1 . De plus, la partie P2 protège P0 et P1 en intégrité.
La partie P1 est obtenue par masquage d'une partie V1 de la valeur de filtrage IDTRN au moyen de l'identifiant IDSi . Cet identifiant IDSi est constant au cours du temps, mais comme la valeur de filtrage IDTRN change à chaque transaction, P1 change également à chaque transaction, de sorte qu'un attaquant ne connaissant pas le numéro de transaction N ne peut ni prédire les valeurs suivantes de Px ni retrouver IDSi à partir de La lecture de Px à l'étape E4, décrite ci-dessous, permettra à l'entité B , par opération inverse à celle qui a permis de calculer Px , de retrouver la valeur IDSi contenue dans Px , et de vérifier la validité de la valeur de filtrage IDTRN et de l'identifiant IDSi . Cette double vérification ne peut être réalisée de façon simultanée : en effet, l'entité B doit d'abord déduire la valeur de filtrage IDTRN de l'identifiant de transaction
IDTRN Si reçu.
A cet effet, on pourra prendra par exemple simplement : P0 = V0. Ainsi, l'entité B va comparer la partie PQ reçue à la partie VQ des valeurs IDTRN précalculées pour la fenêtre de transactions courante. Cette partie V0 de IDTRN qui apparaît en clair dans IDTRN Si sera appelée
« amorce de IDTRN ».
Dans le cas de la synchronisation à base d'horloge, il est toutefois envisageable, pour plus de sécurité, de masquer complètement IDTRN par IDSi dans P1. Ainsi un attaquant observant les échanges ne verrait aucune partie de IDTRN en clair. Dans ce cas, « l'amorce de IDTRN » V0 est vide, V1 = IDTRN , et il est nécessaire de fournir à l'entité B un autre moyen pour récupérer et vérifier la validité de la valeur de filtrage. Par exemple, on pourra prendre :
P0 = td ,
où td désigne, rappelons-le, l'indication horaire ; l'entité B calcule d'abord le numéro de transaction N correspondant à cette indication horaire, et vérifie qu'il figure bien dans la fenêtre de transactions courante ; puis l'entité B récupère la valeur de filtrage IDTRN précalculée correspondant à cette valeur du numéro de transaction. Dans le cas, mentionné ci-dessus, où l'on choisit la synchronisation à base d'horloge et où les transactions sont caractérisées en complément par un numéro de sous-transaction j , la partie P2 de l'identifiant de transaction IDTRN Si dépendra également de ce numéro de sous- transaction.
La réponse d'autorisation RESP peut contenir également, aux fins de vérification, un sous-ensemble INFO' des informations INFO contenues dans la requête d'autorisation REQ.
La réponse d'autorisation RESP peut contenir également une donnée CHECK^B Si dépendant du numéro de transaction N et déduite, au moyen d'une fonction cryptographique dépendant d'une clé secrète KSiB check dérivée de ladite clé secrète KSiB , d'un ensemble d'éléments tirés de ladite requête d'autorisation REQ et, optionnellement, du numéro de transaction N . On notera que, pour ce faire, on peut envisager (au moins) deux variantes :
- selon une première variante, les variables auxquelles est appliquée ladite fonction cryptographique ne comprennent que des éléments tirés de ladite requête d'autorisation ; dans ce cas, il est nécessaire que la clé secrète KSiB check soit une fonction à sens unique du numéro de transaction N (et de la clé secrète KSiB) ;
- selon une deuxième variante, le numéro de transaction N est effectivement inclus dans les variables auxquelles est appliquée ladite fonction cryptographique ; dans ce cas, ladite clé secrète KSiB check ne dépend pas nécessairement de N , et doit seulement être une fonction à sens unique de la clé secrète KSiB .
De préférence, cette fonction cryptographique dépendra en outre d'un aléa engendré simultanément, lors de chaque transaction, par le Serveur d'Autorisation St et l'entité B (cet aléa empêche une entité A malveillante de trouver la clé secrète KSiB check par inversion de la donnée
CHECK^B Si ).
Comme indiqué ci-dessus, il est possible d'envisager des applications de l'invention dans lesquelles l'entité A est autorisée à rester anonyme vis-à-vis de l'entité B ; dans ce cas (ainsi que dans d'autres cas éventuellement), lesdits éléments tirés de la requête d'autorisation REQ et dont le chiffrement fournit la donnée CHECK^B Si ne contiendront aucun identifiant de l'entité A , ou contiendront ledit identifiant dérivé ID'A de l'entité A .
Enfin, lorsque l'intégrité des échanges entre A et 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 d'authentification MAC2 calculé sur tout ou partie des éléments précédemment cités de la réponse RESP. Pour ce faire, on utilisera une clé secrète dérivée de la clé secrète KSiA , que l'on notera KSiA MAC2 .
Lors d'une étape E3, l'entité A reçoit la réponse d'autorisation RESP de la part du Serveur d'Autorisation Si t et envoie un « message authentifié » AM à l'entité B .
Plus précisément, lors d'une sous-étape E3.1 , après réception de la réponse d'autorisation RESP, l'entité A effectue de préférence les vérifications suivantes :
- si la réponse d'autorisation RESP reçue contient des données censées appartenir à un sous-ensemble des informations contenues dans la requête d'autorisation REQ, l'entité A vérifie que ces informations correspondent bien à une requête d'autorisation REQ précédemment émise par elle ; et - si la réponse d'autorisation RESP reçue est associée à un code d'authentification MAC2, l'entité A vérifie l'intégrité des éléments de la réponse d'autorisation RESP concernés.
Si ces vérifications sont positives, lors d'une sous-étape E3.2, l'entité A extrait de la réponse d'autorisation RESP la clé de session
K^B Si , l'identifiant de transaction IDTRN Si , et, le cas échéant, la donnée
CHECK^B Si . L'entité A envoie alors à l'entité B un message authentifié
AM comprenant le message original MES, l'identifiant de transaction
IDTRN Si , et, le cas échéant, la donnée CHECK^B Si .
Lorsque l'intégrité des échanges entre A et H n'est pas assurée par le protocole de transport sous-jacent, le message authentifié AM contient de préférence un code d'authentification MAC3 calculé sur tout ou partie des éléments précédemment cités de ce message AM ; pour ce faire, on utilisera avantageusement la clé de session K^B Si ou une clé secrète K^B Si MAC3 dérivée de la clé de session K^B Si .
Sauf en cas de besoin d'anonymat complet, le message authentifié AM comprendra l'identifiant IDA ou l'identifiant dérivé ID'A de l'entité A .
Cet identifiant pourra naturellement, lui aussi, faire partie desdits éléments servant de base au calcul du code d'authentification MAC3.
On notera que, en variante (cf. notamment les exemples d'architecture présentés ci-dessous), le message authentifié AM peut être envoyé par une entité autorisée autre que l'entité A elle-même, par exemple un autre serveur réseau. Le cas où le message authentifié AM est envoyé « directement » par le Serveur d'Autorisation St sera décrit ci- dessous en référence à la figure 3.
Lors d'une étape E4, l'entité B reçoit le message authentifié AM et détermine la clé de session. Plus précisément, lors d'une sous-étape E4.1 , après réception d'un message authentifié AM, l'entité B obtient, comme expliqué ci-dessus, la valeur de filtrage IDTRN courante et le numéro de transaction N courant à partir de l'identifiant de transaction IDTRN Si reçu.
Comme expliqué ci-dessus, après avoir vérifié la validité de la valeur IDTRN obtenue, l'entité B vérifie :
- à partir de la valeur de filtrage IDTRN et de l'identifiant de transaction IDTRN Si , l'identité du Serveur d'Autorisation S( qui a autorisé la présente transaction,
- que le couple ( IDTRN , IDSi ) n'a pas déjà été « consommé », et
- à partir de l'identifiant de transaction IDTRN Si et de la clé secrète individuelle KSiB , l'authenticité du Serveur d'Autorisation S
Si toutes ces vérifications sont positives, l'entité B récupère ou calcule la clé de session K^B Si , ainsi que, optionnellement, ladite clé secrète KSiB check et/ou ladite clé secrète K^B Si MAC3 associées à cette transaction.
Optionnellement, l'entité B vérifie ensuite que :
- les informations que l'entité B a reçues sont cohérentes avec le code d'authentification MAC3 (si présent) et la clé de session K^B Si ou la clé secrète K^B Si MAC3 , et/ou
- les informations que l'entité B a reçues sont cohérentes avec la donnée CHECK^B Si (si présente) et la clé secrète KSiB check .
Enfin (sauf si ces vérifications optionnelles donnent un résultat négatif), lors d'une sous-étape E4.2, l'entité B extrait le message original MES du message authentifié AM, et transmet, le cas échéant, ce message original MES à un client destinataire B' .
La figure 3 représente schématiquement les étapes d'un deuxième mode de réalisation du procédé selon l'invention.
Dans ce mode de réalisation, une entité A , dite « client expéditeur », souhaite envoyer à une, ou plusieurs, entité(s) B , dite(s) « client(s) destinataire(s) » un message original MES. Par ailleurs, ce message original MES peut, dans certaines applications (par exemple, si le message MES est une demande d'initiation d'appel VoIP), jouer simultanément le rôle de requête d'autorisation REQ.
Le présent mode de réalisation se distingue essentiellement du premier mode de réalisation, décrit ci-dessus en référence à la figure 2, en ce que le Serveur d'Autorisation S( transmet le message authentifié
AM à l'entité B « directement », c'est-à-dire sans utiliser l'entité A comme relais. Ce mode de réalisation présente donc comme inconvénient un surplus de traitement pour le Serveur d'Autorisation S- , mais il peut néanmoins s'avérer pratique dans certaines architectures (voir exemples ci-dessous).
On va décrire à présent les étapes principales de ce mode de réalisation.
La première étape ΕΊ est analogue à l'étape E1 du premier mode de réalisation, si ce n'est que le message MES doit, dans ce deuxième mode de réalisation, être entièrement inclus dans la requête d'autorisation REQ.
La deuxième étape E'2 est analogue à l'étape E2 du premier mode de réalisation, si ce n'est que la réponse d'autorisation RESP ne contient ici ni l'identifiant de transaction IDTRN Si ni la donnée CHECK^B Si .
Lors d'une étape E'3, le Serveur d'Autorisation St transmet « directement » à l'entité B le message authentifié AM comprenant le message original MES, l'identifiant de transaction IDTRN Si et, optionnellement, la donnée CHECK^B Si . Lorsque l'intégrité des échanges entre St et B n'est pas assurée par le protocole de transport sous-jacent, le message authentifié AM contient de préférence un code d'authentification MAC3 calculé sur tout ou partie des éléments précédemment cités de ce message AM ; pour ce faire, on pourra utiliser, comme dans le premier mode de réalisation, la clé de session K^B Si ou une clé secrète K^B Si MAC3 dérivée de la clé de session K^B Si ; en variante, on pourra utiliser ici la clé secrète KSiB ou une clé secrète dérivée de cette clé secrète KSiB .
On notera que, comme illustré sur la figure 3, l'étape E'3 peut précéder l'étape E'2. Cet ordre opératoire permet avantageusement d'interrompre la transaction avant que le Serveur d'Autorisation S( n'envoie la réponse d'autorisation RESP à l'entité A , au cas où l'entité B n'envoie pas à St un accusé de réception du message authentifié AM si un tel accusé de réception était prévu, ou au cas où l'entité B envoie à S( un accusé de réception dans lequel l'entité B déclare refuser cette transaction avec l'entité A .
Enfin, l'étape E'4 est analogue à l'étape E4 du premier mode de réalisation. On notera que cette étape E'4 doit naturellement intervenir postérieurement à l'étape E'3, mais qu'elle peut précéder l'étape E'2.
On va à présent examiner, à titre d'exemples, diverses architectures possibles pour la mise en œuvre de l'invention.
Les trois premiers exemples s'appliquent à la VoIP. Les services et réseaux VoIP constituent un contexte d'application particulièrement intéressant, car, en plus de fortes contraintes de sécurité, ils ont également des contraintes de temps-réel, de nombre d'entités déployées (actuellement plusieurs millions dans certains réseaux), de puissance des terminaux, ainsi que des contraintes légales qui imposent de pouvoir intercepter les communications sensibles. Ce besoin d'interceptions légales milite naturellement pour le contrôle des clés de session par une entité de confiance (ici, le Serveur d'Autorisation qui pourrait être alors un proxy d'un opérateur réseau.
(a) Communications VoIP intra-domaine
Les entités clientes A et fi , ainsi que le Serveur d'Autorisation St 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-client au réseau.
La requête d'autorisation REQ envoyée par l'entité A permet au Serveur d'Autorisation St d'authentifier l'entité A et de déterminer le routage pour atteindre l'entité B .
L'appel peut ensuite s'établir directement entre les entités A et H sans qu'il soit nécessaire d'établir une connexion TLS entre A et H pour assurer l'intégrité et la confidentialité de la signalisation. Le message MES correspond à la requête « INVITE ».
(b) Interconnexions VoIP mode 1
Dans ce mode de réalisation, les entités expéditrice et destinataire sont localisées dans deux réseaux distincts, appartenant à des opérateurs différents ; le domaine expéditeur est noté D-EXP et le domaine destinataire D-DEST.
L'entité A est l'un des proxys sortants du domaine expéditeur D- EXP. 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 St est l'un des proxys entrants du domaine destinataire D-DEST. Le Serveur d'Autorisation S( protège et dessert une ou plusieurs entité(s) B pouvant appartenir au domaine destinataire D-DEST ou à des domaines tiers.
L'entité B peut correspondre directement au terminal-client destinataire. En variante, l'entité B peut correspondre à un serveur récepteur, faisant partie du domaine destinataire D-DEST ou d'un domaine tiers, auquel cas le véritable terminal-client destinataire correspond à l'entité B' .
Dans la requête d'autorisation REQ, l'entité A référence l'entité B destinataire, via un ou plusieurs identifiants de niveau réseau, transport ou applicatif tels que l'adresse réseau de l'entité B , le nom de domaine auquel appartient l'entité B , une SIPJJRI ou TelJJRI désignant l'entité cliente destinataire. De même, l'entité A s'identifie par un ou plusieurs identifiants de niveau réseau, transport ou applicatif tels que son adresse réseau, ou le nom de domaine auquel elle appartient, ou une SIPJJRI ou une Tel_URI désignant l'entité cliente expéditrice.
La réalisation de la transaction de numéro N permet à A et H de partager la clé primaire de session K^B Si . 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 destinataire sont localisées dans deux réseaux distincts notés D-EXP et D-DEST.
L'entité A est un terminal client du domaine D-EXP ou bien un serveur émetteur du domaine expéditeur ou d'un domaine tiers. Si l'entité A est un serveur émetteur, alors le véritable client expéditeur correspond à une entité .
Le Serveur d'Autorisation St est l'un des proxys sortants du domaine expéditeur D-EXP, c'est à dire un serveur expéditeur. Le Serveur d'Autorisation St dessert les entités A du domaine expéditeur ou des domaines tiers, et autorise les communications avec le domaine destinataire.
L'entité B est l'un des proxys entrants du domaine destinataire D-
DEST. Cette entité sert, et protège, des entités B' qui sont soit directement des terminaux-client, soit des serveurs récepteurs appartenant au domaine destinataire ou à des domaines tiers.
La requête d'autorisation REQ et la réponse d'autorisation RESP sont échangées dans le domaine expéditeur ou entre le domaine émetteur et le domaine expéditeur, alors que le message AM est envoyé par une entité cliente ou un serveur émetteur vers le serveur destinataire.
(d) Envoi d'e-mail ou de message instantané IM
L'architecture est similaire à celle pour les interconnexions VoIP (mode 1 ou mode 2) en ce qui concerne les entités A , A' , S , B , et B' .
Les identifiants utilisés dans la demande de transaction pour désigner les entités A ou A' (respectivement B ou B' ) sont des adresses e-mail, des adresses IM ou des noms de domaines. La réalisation de la transaction de numéro N permet à A et H de partager la clé de session primaire K^B Si . 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 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 H de partager la clé de session primaire K^B Si . Cette clé de session est ensuite utilisée pour établir une connexion sécurisée (IPSec, TLS, DTLS, ou autre) entre les entités A et B .
(f) Application à un service de type DNS/ENUM
Cette application du procédé selon l'invention concerne un service de mise en relation, où le Serveur d'Autorisation St est un serveur de type
DNS ou ENUM dans le cas des applications VoIP. Cela permet 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 à son 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 d'Autorisation S Avant d'émettre un appel vers l'entité B , l'entité A envoie une requête d'autorisation vers le Serveur d'Autorisation S pour authentifier l'appelant et obtenir une clé secrète d'appel vers B . Le Serveur d'Autorisation St est un serveur de type DNS/ENUM qui dispose de secrets partagés KSiA , KSiB avec un certain nombre de domaines, grâce à une phase de mise en relation préalable. Le Serveur d'Autorisation St joue le rôle de tiers de confiance.
L'entité B est l'un des proxys entrants du domaine « domaine2 » et dispose d'un secret partagé avec le Serveur d'Autorisation S
La réalisation de la transaction permet à l'entité B de vérifier que l'identifiant d'appelant présenté par l'entité A dans la requête INVITE a bien été authentifié par le Serveur d'Autorisation St . Elle permet de plus aux entités A et H de disposer d'un secret partagé K^B Si pouvant être utilisé pour protéger la suite de leur échange ou des flux média.
La mise en œuvre de l'invention au sein des nœuds du réseau de télécommunications (notamment, les terminaux ou serveurs des entités abonnées au service de communications sécurisées selon l'invention, ou les Serveurs d'Autorisation) peut être réalisée au moyen de composants logiciels et/ou matériels.
Les composants logiciels pourront être intégrés à un programme d'ordinateur classique de gestion de nœud 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 œuvre 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, inamovible, ou partiellement ou totalement amovible, lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.
Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une clé USB (« USB flash drive » en anglais) ou un disque dur.
D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme d'ordinateur selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
En variante, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour être utilisé dans un dispositif de communications sécurisées selon l'invention.

Claims

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

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1054220A FR2960734A1 (fr) 2010-05-31 2010-05-31 Procede et dispositifs de communications securisees dans un reseau de telecommunications
PCT/FR2011/051200 WO2011151573A1 (fr) 2010-05-31 2011-05-26 Procede et dispositifs de communications securisees dans un reseau de telecommunications

Publications (1)

Publication Number Publication Date
EP2577901A1 true EP2577901A1 (fr) 2013-04-10

Family

ID=43402138

Family Applications (1)

Application Number Title Priority Date Filing Date
EP11727272.4A Withdrawn EP2577901A1 (fr) 2010-05-31 2011-05-26 Procede et dispositifs de communications securisees dans un reseau de telecommunications

Country Status (5)

Country Link
US (1) US8738900B2 (fr)
EP (1) EP2577901A1 (fr)
CN (1) CN103039033A (fr)
FR (1) FR2960734A1 (fr)
WO (1) WO2011151573A1 (fr)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102868665B (zh) * 2011-07-05 2016-07-27 华为软件技术有限公司 数据传输的方法及装置
US9075953B2 (en) 2012-07-31 2015-07-07 At&T Intellectual Property I, L.P. Method and apparatus for providing notification of detected error conditions in a network
US9237133B2 (en) * 2012-12-12 2016-01-12 Empire Technology Development Llc. Detecting matched cloud infrastructure connections for secure off-channel secret generation
US10027722B2 (en) * 2014-01-09 2018-07-17 International Business Machines Corporation Communication transaction continuity using multiple cross-modal services
US11888844B2 (en) * 2014-02-18 2024-01-30 Secuve Co., Ltd. Electrical circuit testing device and method
AU2015301279A1 (en) * 2014-08-04 2017-03-16 Mobile Search Security LLC Secure mobile contact system (SMCS)
EP3059920B1 (fr) * 2015-02-20 2020-02-12 Siemens Aktiengesellschaft Procédé et appareil permettant d'assurer un fonctionnement sûr d'un sous-système à l'intérieur d'un système de sécurité critique
US10079754B2 (en) * 2015-12-15 2018-09-18 Nxp Usa, Inc. Adapative message caches for replay/flood protection in mesh network devices
ES2878082T3 (es) * 2016-12-06 2021-11-18 Enrico Maim Procedimientos y entidades especialmente transaccionales que emplean dispositivos seguros

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5590199A (en) * 1993-10-12 1996-12-31 The Mitre Corporation Electronic information network user authentication and authorization system
US7024692B1 (en) * 2000-01-21 2006-04-04 Unisys Corporation Non pre-authenticated kerberos logon via asynchronous message mechanism
US6986040B1 (en) * 2000-11-03 2006-01-10 Citrix Systems, Inc. System and method of exploiting the security of a secure communication channel to secure a non-secure communication channel
CN1329418A (zh) * 2001-07-24 2002-01-02 巨龙信息技术有限责任公司 网络用户身份认证的方法及克服Kerberos认证体制中用户口令漏洞的方法
DE10353853A1 (de) * 2003-11-18 2005-06-30 Giesecke & Devrient Gmbh Autorisierung einer Transaktion

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
CHWAN-HWA WU ET AL: "Using Identity-Based Privacy-Protected Access Control Filter (IPACF) to against denial of service attacks and protect user privacy", PROCEEDINGS OF THE 2007 SPRING SIMULATION MULTICONFERENCE, vol. 3, 25 March 2007 (2007-03-25), pages 362 - 369, XP055148798, ISBN: 978-1-56-555314-9 *
PATRICK BATTISTELLO: "Inter-domain and DoS-resistant call establishment protocol (IDDR-CEP)", PRINCIPLES, SYSTEMS AND APPLICATIONS OF IP TELECOMMUNICATIONS ON, IPTCOMM '10, 1 January 2010 (2010-01-01), New York, New York, USA, pages 22, XP055016414, ISBN: 978-1-45-030631-7, DOI: 10.1145/1941530.1941534 *
See also references of WO2011151573A1 *
TONG LIU ET AL: "Intrusion-resilient, DDoS-resistant and agent-assisted network security system", BROADBAND COMMUNICATIONS, NETWORKS AND SYSTEMS, 2007. BROADNETS 2007. FOURTH INTERNATIONAL CONFERENCE ON, IEEE, PISCATAWAY, NJ, USA, 10 September 2007 (2007-09-10), pages 306 - 308, XP031276648, ISBN: 978-1-4244-1432-1 *

Also Published As

Publication number Publication date
CN103039033A (zh) 2013-04-10
FR2960734A1 (fr) 2011-12-02
US8738900B2 (en) 2014-05-27
WO2011151573A1 (fr) 2011-12-08
US20130086649A1 (en) 2013-04-04

Similar Documents

Publication Publication Date Title
EP2484084B1 (fr) Procédé et dispositifs de communications securisées contre les attaques par innondation et denis de service (dos) dans un réseau de télécommunications
WO2011151573A1 (fr) Procede et dispositifs de communications securisees dans un reseau de telecommunications
EP1022922B1 (fr) Procédé d'authentification, avec établissement d'un canal sécurise, entre un abonné et un fournisseur de services accessible via un opérateur de télécommunications
EP3506556B1 (fr) Méthode d'échange de clés authentifié par chaine de blocs
CA2636780C (fr) Methode et dispositif pour transmission de donnees et de communication vocale chiffrees anonymes
CA2423024C (fr) Systeme de telecommunication, notamment de type ip, et equipements pour un tel systeme
EP2092703B1 (fr) Contrôle de message a transmettre depuis un domaine d'émetteur vers un domaine de destinataire
EP2206276A1 (fr) Dispositif et procede pour aiguiller des flux d'echange de valeurs publiques ou non sensibles permettant de creer des cles secretes communes entre plusieurs zones
EP2186252B1 (fr) Procede de distribution de cles cryptographiques dans un reseau de communication
EP3219077B1 (fr) Procédé et système de gestion d'identités d'utilisateurs destiné à être mis en oeuvre lors d'une communication entre deux navigateurs web
FR2866168A1 (fr) Emission de cle publique par terminal mobile
Jefferys et al. Session: A model for end-to-end encrypted conversations with minimal metadata leakage
FR2950767A1 (fr) Procede de communications securisees dans un reseau de telecommunications
FR2846819A1 (fr) Procede d'echange securise entre deux unites de communication, systeme de controle et serveur pour la mise en oeuvre du procede
WO2010133783A1 (fr) Procédé de protection contre les messages indésirables dans un réseau de télécommunications
FR3116978A1 (fr) Contrôle d’accès à un réseau de communication local, et passerelle d’accès mettant en œuvre un tel contrôle
Suárez Touceda Security in peer-to-peer communication systems
Touceda et al. Security in peer-to-peer communication systems.
FR3022375A1 (fr) Procede et dispositif de securisation d'un systeme protege par mot de passe
WO2011023881A1 (fr) Technique pour evaluer une collaboration entre des noeuds d'un reseau de communication
FR2900776A1 (fr) Procede de securisation de donnees

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20121120

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

INTG Intention to grant announced

Effective date: 20141212

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20150423