WO2010133783A1

WO2010133783A1 - Method for protecting against unwanted messages in a telecommunication network

Info

Publication number: WO2010133783A1
Application number: PCT/FR2010/050828
Authority: WO
Inventors: Patrick Battistello
Original assignee: France Telecom
Priority date: 2009-05-20
Filing date: 2010-04-30
Publication date: 2010-11-25

Abstract

When a sender client affiliated with a sender domain and connected to a transmitting server sends an original message (MES) to at least one destination client affiliated with a destination domain and connected to a receiving server: a) a sender server belonging to the sender domain acknowledges that a transaction associated with the sender client and the destination client has been initiated; b) if the sender server decides to authorize said transaction, it sends or makes the transmitter server send a notification request to a destination server belonging to the destination domain, the notification request including elements containing an identifier of the destination client; c) if the destination sever decides to authorize the transaction, it randomly generates a mark (K_REC) and sends a transaction decision containing said mark (K_REC) to the sender server; d) the sender server and the destination server separately calculate a same token (KD) resulting from the application of a predetermined encrypting algorithm to a data set contingent upon at least the mark (K_REC) using an encryption key shared by the sender server and the destination server; e) the sender server sends or makes the transmitting server send an authenticated message (AM) including the original message (MES) and the token (KD) or a value derived from the token (KD) to the destination server (2) or to the receiving server (4); and f) if the destination server or the receiving server decides to authorize the transaction on the basis of at least the value of the token (KD) or a value derived from the token (KD) received in the authenticated message (AM), the destination client accepts the original message (MES).

Description

METHOD FOR PROTECTION AGAINST UNDESIRABLE MESSAGES IN A TELECOMMUNICATIONS NETWORK

The present invention relates to the protection against the reception of undesirable messages in a telecommunications network. Telecommunication networks, such as the Internet, transmit data via a common infrastructure between different service entities, such as a web server or an e-mail server. These networks are attacked by professional, administrative or individual targets. A common attack nowadays is to send as many recipients as possible unwanted messages that they have not solicited, such as "Spam" for e-mails or "Spits" for Internet phone calls. . The term "undesirable" is taken in a broad sense and applies both to the identity of the sender of the message, which may be authentic or falsified, and to the content of the message.

For example, the possibility of spam attacks is based on the following factors:

the weakness of the protocols used on the Internet, such as the SMTP protocol ("Simple Mail Transfer Protocol" in English), the most used for the transfer of electronic mail and which does not include any authentication functions of the issuer mail ;

- the increase in the power of computers that can send unwanted messages in bulk automatically over a very short period; and

- the increase in the number of networks having access to the Internet and the connectivity between these networks, which presents a very large number of targets to attackers who can shelter behind networks relatively permissive or out of legal or administrative scope of the target networks.

Moreover, a sender domain can relay to a destination domain a message sent by a sender client which is connected to the sender domain but which is not attached to the sender domain (in the context of the present invention, it will be said that a client is "attached" to a network domain when this customer has a service link and / or logical and / or administrative with this domain, in the case of email, the logical address corresponds to the address "email"). For example, a roaming sender client connected to a "sender.fr" sender domain sends an e-mail whose original address is user@expéditeur.fr and whose destination address is user2@destinataire.fr.

However, it is not easy for the sender domain to determine whether the sending client's address is valid, ie if the address of this client is actually assigned in the "sender.fr" domain. "and if the sending client has the rights to send a message from this address: indeed, the sender domain does not manage the identities, that is to say the logical addresses of the type" sender.fr ". This control difficulty is often used by attackers to send messages under a false identity from a domain to which attackers have access or via a corrupted machine in a legitimate domain.

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 (Voice Over Internet Protocol) VoIP (Voice Over Internet Protocol) that allows a roaming terminal to use a third party relay such as a sender domain to make a phone call. This poses the problem of finding ways for a recipient domain to ensure that sufficient controls are performed at the domain sending the message.

It is obviously possible, in principle, to authenticate messages by means of a public key infrastructure (PKI). But as it is well known, PKI infrastructures are very cumbersome to set up and use.

The international application FR2007 / 052057 discloses a method for protecting a given recipient domain, and the clients attached thereto, against unwanted messages. This method makes it possible to control the sending of an "original message" to this destination domain by a sender client attached to a sender domain and connected to a sender domain (the sender domain may or may not be separate from the sender domain). By "original message" is meant here any set of information, for example an e-mail or a request for VoIP call initiation or an "instant message".

A "transaction" is defined as the set of protocol exchanges for sending an original message in a secure manner. Each new original message sent from a sender domain to a destination domain is a new transaction. Conversely, the repetition of a protocol step, for example due to a network problem, is not considered as a new transaction.

According to the international application FR2007 / 052057, each transaction schematically comprises the following steps: if the sender domain, after authentication of the sending client, accepts the transaction, the sender domain sends to the destination domain a request containing in particular the logical address of the sending client; if the receiving client agrees to receive the original message, then the recipient domain generates a cookie, which it sends to the domain issuer; the sender domain sends to the destination domain an authenticated message containing the original message and, for verification, said witness; if the verification is positive, the original message is finally sent to the receiving customer. This method thus imposes an accountability, on the one hand, of the sender domain which must authenticate the sender of the message, and on the other hand of the sender domain which intervenes in the control of the messages that it emits, so as to make a message part of the load of the controls to the sending domain and the issuing domain rather than leaving it entirely to the destination domain.

This method, which does not require in particular any heavy cryptographic procedure, is advantageously simple to implement. Moreover, it is independent of the architecture of the communications network concerned. In particular, it is compatible with common message sending protocols, such as the "SMTP" protocol for e-mail applications. In addition, the verification of the origin of the message can be advantageously done by the destination domain irrespective of the number of relay servers that retransmitted the message to the destination domain. However, the method according to FR2007 / 052057 is vulnerable to the following attack. An "attacker" could listen to the transaction authorization sent by the destination domain to the sender domain, read the value of said witness, and, by usurping a network address in the sender domain, send to the destination domain a malicious original message accompanied by the witness thus fraudulently acquired. The destination domain is deceived because the value of the witness is correct; it will then transmit this original illegal message to the recipient customer.

The present invention thus relates to a method of protection against undesirable messages in a telecommunications network, comprising, when a sending client attached to a domain says sender domain and connected to a device, said sending server, sends a message, said original message MES, to at least one recipient client attached to a domain said destination domain and connected to a device, said receiving server, the following steps : a) a device, said sending server, belonging to said sending domain acknowledges that a transaction associated with said sending client and said destination customer has been initiated, b) if said sending server decides to authorize said transaction, sending, or sending sending by said sending server, a notification request to a device, said recipient server, belonging to said destination domain, said notification request comprising elements including an identifier of the recipient client, and c) if said recipient server decides to authorize the transaction , it randomly generates a witness K_REC, and sends to the sender server a decision transaction including said witness

K_REC.

Said method is remarkable in that it further comprises the following steps: d) the sending server and the destination server independently calculate the same KD token, which results from the application of a predetermined encryption algorithm to a set of data at least dependent on said witness K_REC, using a encryption key TID _N shared between the sending server and the destination server, e) the sending server sends or has sent by said sending server to the destination server or to said receiving server an authenticated message AM comprising said original message MES, and token KD or a value derived from token KD, and f) whether recipient or receiver server decides, at least on the basis of value of token KD or value derived from token KD received in said authenticated message AM, to authorize the transaction, the recipient client accepts the original message MES.

It will be noted that, in the context of the present invention, the word "server" in the terms "sending server", "recipient server", "sending server" and "receiving server" is, for the sake of simplicity, used to designate uniformly any type of computing device, and not only the computing devices conventionally referred to as "servers".

Thanks to the invention, one can benefit from the advantages of the method according to the application FR2007 / 052057, while protecting against the type of attacks mentioned above. Indeed, when implementing the present invention, if an attacker "listened" to the transaction decision sent by the recipient server to the sender server, it could possibly, similarly to the case of the method according to the application FR2007 / 052057 , there read the value of the witness K_REC. But the hacker can not calculate the KD token corresponding to this witness

K_REC, because the hacker does not know the encryption key TID _N. The hacker is thus unable to deceive the receiving server by sending him a malicious MES 'message along with the KD token (or a value derived from the KD token).

Preferably, the decision of the sending server, between steps a) and b) mentioned above, to authorize or not the transaction is at least based on an assessment of the authenticity of the sending client; the sending domain may, for this purpose, implement any known authentication method.

This imposes an accountability of the sender domain to reduce the risk of receiving an unwanted message by the recipient client.

Preferably also: said elements of the notification request furthermore include an identifier of the sending client, and

- said decision by said recipient server, between steps b) and c) above, to allow or not the transaction is at least based on an evaluation of the desire on the part of the recipient client to receive said original message MES ; the recipient client may, for this purpose, mean either explicitly or implicitly (use of "white" and / or "black" lists), whether or not he wishes to receive a message from this sender client. This further reduces the risk of reception of unwanted messages by the recipient customer.

According to particular features, said notification request is protected in integrity.

Note that this protection can be achieved by any known means, for example by means of a "message authentication code". It is recalled in this regard that, conventionally, a message authentication code (in English "Message Authentication Code" or "MAC") is an encrypted data contained in a message, the encryption being effected by means of a secret key shared between the sender and the receiver of the message. By sending a message accompanied by its authentication code, the transmitter allows the receiver to verify that this data has not been altered between transmission and reception.

Thanks to these provisions, it is possible, in the first place, to authenticate the sender server to the recipient server in order to allow the recipient server to reject communications from an unauthorized source; in particular, thus protects the recipient server against a flood attack. In the second place, the elements of the request for notification are thus protected against any alteration; however, such tampering would cause the transaction to fail in most cases. According to other particular features, said elements of the notification request further include a value h (MES) obtained by applying a one-way function "h" to all or part of said original message MES. Thanks to these provisions, the receiving server can, after receiving communication of this value h (MES), check, between steps e) and f) mentioned above, that this value is equal to the value it obtains. applying the "h" function to the original message MES contained in the authenticated message AM. One can thus prevent an attacker who would not only have the means to listen to the communications according to the invention, but also the means to intercept some of these communications to replace the content with illegal content (attacks of the "MITM" type). ", initials of the English words" Man In the Middle "meaning" inserted individual "). Indeed, such a hacker could, in the absence of such provisions, deceive the receiving server by intercepting a legitimate authenticated message, substituting the original message MES by a "message original" illicit MES 'without changing the token KD (or the value derived from the token KD), and by sending to the receiving server the illicit "authenticated message" thus constituted. According to still other particular characteristics, the sending server and the sender server are distinct, and

the sending server sends to the sender server, before step a) mentioned above, an authentication request comprising at least one identifier of the recipient client (s), and the sending server sends to the server transmitter, between steps d) and e) mentioned above, a notification of elements comprising said token KD.

Thanks to these provisions, the invention can advantageously be applied to a sending client in a situation of mobility with respect to its field of attachment. Preferably, said authentication request it further comprises an identifier of the sending client, in order to subsequently enable the recipient client to signify whether or not it wishes to receive a message from this sending client.

According to even more particular characteristics, said authentication request further comprises said value h (MES).

Thanks to these provisions, one can complete, in the case concerned, the provisions, outlined above, to include the value h (MES) in said request for notification.

According to other characteristics even more particular, the communications between the sender server and the sender server, assumed to be distinct, are protected in integrity.

Thanks to these provisions, it is possible to protect against a denial of service attack in which an attacker would change the value of the token KD in said item notification, so that the receiving server, receiving from the sending server a value of token KD (or the value derived from the token KD) that does not match the value of the token KD calculated by the recipient server in step d) mentioned above, would refuse the transaction.

Moreover, in the case where, as succinctly explained above, the value h (MES) is included in the notification request, these provisions make it possible to block an attack of the MITM type in which a pirate:

• intercept an authentication request sent by the sender server to the sender server, substitute h (MES) with h (MES '), where MES' designates a malicious message, and then send a malicious authentication request to the sender server, then

• intercept the authenticated message AM including the original message MES before it reaches the receiving server, replace MES by MES 'without changing the token KD (or value derived from the token KD), and send to the receiving server the illicit "authenticated message" thus constituted.

According to still other particular characteristics, said transaction decision is protected in integrity. Thanks to these provisions, it is possible, in the first place, to authenticate the recipient server with the sender server. In the second place, the data contained in the transaction decision is thus protected against any alteration; it is clear, in particular, that the alteration of the value of the witness K_REC would result in the calculation of a false value for the KD token by the sender server, and thus the failure of the transaction.

According to still other particular characteristics, the recipient server and the receiver server are distinct, and:

the destination server sends to the receiving server, between the steps b) and c) mentioned above, a transaction notification comprising elements extracted from said notification request, and

- The destination server sends to the receiving server, between steps d) and e) mentioned above, a parameter notification comprising said token KD.

Thanks to these provisions, the invention can advantageously be applied to a recipient client in a mobility situation with respect to its field of attachment. Said transaction notification in particular allows, in the case considered here, to verify that the recipient client is in agreement to receive the message.

According to even more particular provisions, said parameter notification further comprises said value h (MES).

Thanks to these provisions, one can complete, in the case concerned, the provisions, outlined above, to include the value h (MES) in said request for notification. According to still other particular characteristics, the recipient server and the receiving server are distinct, and the communications between these two servers are protected in integrity.

Thanks to these provisions, it is possible to block an attack of the MITM type in which a hacker would send to the receiving server a notification of parameters containing a malicious KD 'token. Indeed, the hacker could then deceive the receiving server by then sending him an authenticated pseudo-message containing a message MES 'illicit with this same token KD'. In summary, it can be seen that the invention makes it possible, by means of precautions that are simple enough to implement, but judiciously chosen, not only to protect the users of a network against the reception of unwanted messages, but also to protect the transmissions Desirable messages against various attacks by malicious third parties.

Correlatively, the invention relates to various devices. It thus concerns, firstly, a device, said sender server, protection against unwanted messages in a telecommunications network. Said device is remarkable in that it comprises means for, when a sender client attached to a domain said sender domain to which said sender server belongs and connected to a device, said sender server, sends a message, said original message MES, to at least one recipient client attached to a domain called destination domain and connected to a device, said receiving server:

- take note that a transaction associated with said sending client and said receiving customer has been initiated,

in the case where he decides to authorize said transaction, to send, or cause said sending server to send, a notification request to a device, said recipient server, belonging to said destination domain, said notification request comprising elements including an identifier of the recipient client,

receiving from said destination server a transaction decision comprising a witness K_REC, calculating a KD token, which results from the application of a predetermined encryption algorithm to a set of data depending at least on said K_REC control, using a shared encryption key TID _N with the recipient server, and

sending, or sending by said sending server, to the destination server or to said receiving server an authenticated message AM comprising said original message MES, and the token KD or a value derived from the token KD.

It also relates, secondly, a device, said destination server, protection against unwanted messages in a telecommunications network. Said device is remarkable in that it comprises means for, when a sender client attached to a domain said sender domain and connected to a device, said sender server, sends a message, said original message MES, to least a recipient client attached to a domain said destination domain to which said recipient server belongs and connected to a device, said receiving server:

receiving from said sender server or from a device, said sender server, belonging to said sender domain a notification request comprising elements including an identifier of said recipient client,

in the event that he decides to authorize the transaction, randomly generate a witness K_REC, and send to said sender server a transaction decision comprising said witness K_REC, and

calculate a KD token, which results from the application of a predetermined encryption algorithm to a set of data dependent at least of said witness K_REC, using a shared encryption key TID _N between the sending server and the destination server.

According to particular provisions, this device for protection against undesirable messages furthermore comprises means for: receiving from said sending server or from said sending server an authenticated message AM comprising said original message MES, and the token KD or a derived value the KD token, and

- decide to authorize the transaction, at least on the basis of the value of the token KD or the value derived from the token KD received in said authenticated message AM.

According to other particular provisions, this protection device against unwanted messages further comprises means for sending to said receiving server:

a transaction notification comprising elements including an identifier of said recipient client, and

a parameter notification comprising said token KD, and the address of the sending server intended to send to the server receiving an authenticated message AM comprising said original message MES, and the token KD or a value derived from the token KD. The advantages offered by these devices are essentially the same as those offered by the correlative methods succinctly set forth above.

Note that it is possible to implement the method of protection against undesirable messages according to the invention by means of software instructions and / or by means of electronic circuits.

The invention therefore also relates to a computer program downloadable from a communication network and / or stored on a computer readable medium and / or executable by a microprocessor. This computer program is remarkable in that it includes instructions for the implementation of said means included in one any of the undesirable message protection devices described briefly above.

The advantages offered by this computer program are essentially the same as those offered by said devices. Other aspects and advantages of the invention will appear on reading the detailed description below of particular embodiments, given by way of non-limiting examples. The description refers to the figures that accompany it, in which:

FIG. 1 schematically represents a telecommunications network and the main entities to which the invention applies, and

FIG. 2 schematically represents the steps of one embodiment of the method according to the invention.

The system illustrated in FIG. 1 comprises a main telecommunications network 300, for example the Internet, to which the following four telecommunications domains or networks are connected:

a domain called transmitter domain 101,

a domain called sending domain 102,

a domain called receiver domain 201, and a domain referred to as destination domain 202.

These domains are able to transmit, in a conventional manner, messages of any kind such as, for example, e-mails or telephone calls on fixed or mobile channels. The present embodiment comprises a step prior to the sending of any message, called the connection phase, in which the sender domain 102 has requested to be put in contact with the destination domain 202, and the destination domain 202 has accepted imposing conditions on the future association. When the matching phase succeeds, an association is created between the domain sender and the destination domain, and this association is registered and maintained synchronously by the sender domain and the destination domain. The association includes constant parameters, set during the linking phase, and variable parameters that change according to the transactions taking place between the two domains. The linking phase includes:

the designation of at least one device, said sender server 1, in said sender domain, and at least one device, said recipient server 2, in said destination domain, and the information sharing, called synchronization information (Which will be described below) between the sender server 1 and the destination server 2, in particular depending, generally, on requirements from the destination domain 202.

It should be noted that it is entirely possible, in the context of the invention, to provide, subject to the agreement of the destination domain 202, a plurality of sending servers. Similarly, during the linking, the destination domain 202 may indicate to the sender domain 102 a plurality of addressable recipient servers for future transactions. The designation of S _E servers in the sender domain and

S _D servers in the destination domain, with S _E > 1 and S _D > 1, provide redundancy or load sharing properties. Each server, in the sending domain and in the destination domain is characterized at least by an index and by a network or transport address, to which this server is addressable.

In addition, a matrix called "connectivity", of size S _E ^• _S and denoted ASIM may be determined by the recipient field, as part of the linking phase, and be one of the parameters the association. By definition ASIM [Z, j] is a Boolean element indicating if the index server i in the sender domain is allowed to participate in transactions involving the index server j in the destination domain, and conversely if the index server j in the destination domain is allowed to participate in transactions involving the index server / in the sender domain. In a simplified application mode, the ASIM matrix is unspecified, which means that any sending server can participate in transactions with any recipient server.

The servers are supposed to be "stable" at the network level, that is, they exchange the protocol messages with addresses previously registered by the sending domain and the destination domain. Any modification of any of these servers must be exceptional and endorsed by the recipient domain. In the context of an established association, frequent requests from the sending domain to modify the routing addresses of its servers probably denote an attacking domain.

Some parameters registered in the association, such as the ASIM connectivity matrix, may change over time, depending on the destination domain's decision or on request from the sending domain, endorsed by the destination domain. This unilateral mode of decision aims to protect the recipient domain against any drift or attempt of abuse on the part of the sending domain.

Once this preliminary step of connection has been completed, the method according to the invention can be applied to any message, said "original message" MES, sent by a sending client 100 attached to the sending domain 102 (that is to say registered with this sender domain), destined for at least one recipient client 200 attached to the destination domain 202.

In order to take into account a possible mobility of the sending client 100, it will generally be said that this client is connected to a domain said issuer domain 101; it will also generally be said that this transmitting domain 101 comprises at least one relay server, said sending server 3, which participates in the management of the transactions, in connection with a sender server 1, without knowing the synchronization information which constitutes the shared secret established between the sender server 1 and the destination server 2 during the connection phase. But it is clear that the domains issuer 101 and sender 102 are not necessarily distinct; when the sender and sender domains are combined, the sender server 3 may possibly be physically confused with the sender server 1, and / or the sender client may possibly be physically confused with the sender server.

Similarly, in order to take into account a possible mobility of the destination client 200, it will generally be said that this client is connected to a domain said receiver domain 201; it will also generally be said that this receiver domain 201 comprises at least one relay server, said receiver server 4, which participates in the management of the transactions, in connection with a destination server 2, without knowing the synchronization information which constitutes the shared secret established between the destination server 2 and the sender server 1 during the connection phase. But it is clear that the receiver 201 and destination 202 domains are not necessarily distinct; when the receiver and recipient domains are combined, the receiver server 4 may possibly be physically confused with the destination server 2, and / or the recipient client may possibly be physically confused with the receiving server.

The transactions taking place between the same sender domain and the same destination domain are ordered according to a serial number, also called "transaction index" N. At a given moment, several transactions can be simultaneously active between the same sending domain and the same destination domain, within the limit of a maximum number MNSAT defined within the framework of the association between these two domains. The MNSAT value is set by the destination domain, when establishing the association between the two domains, to protect the recipient domain against any flood risk from the sending domain. In a simplified application mode, the MNSAT value is unspecified, which means that the destination domain accepts any number of active transactions at a given time. In addition, in the context of a given association, the sender and recipient domains can independently calculate, for any transaction of index N, a secret encryption key TID _N associated with this transaction.

Preferably, it will be ensured that this encryption key TIDN varies (in a concerted manner) from one transaction to another, in order to avoid replay attacks and attacks resulting from the fraudulent discovery by an attacker of certain information from synchronization. To avoid transmitting the key TID _N via the network, this key is calculated simultaneously by the sending domain and the destination domain from the transaction index N; for example, the encryption key TID _N can be derived from the transaction index N and a secret key chosen by the sender and recipient domains during the linking phase. In a simplified application mode, the encryption key TID _N may be independent of the transaction index, and be constant, that is to say fixed at the establishment of the association.

To fix ideas, we will place here in the case where both the sending client 100 and the receiving client 200 are in a situation of mobility. It will be assumed moreover (always to fix the ideas), on the one hand, that the sender client 100 and the sender server 3 are distinct, and on the other hand that the recipient client 200 and the receiver server 4 are distinct. Those skilled in the art will readily adapt the description below to other possible arrangements.

As explained above, the exchanges between the sending server 3 and the sending server 1 are preferably protected in integrity; this protection can for example be implemented, in a conventional manner, by associating the contents of the exchanges between the sending server and the sending server with an authentication code of this content, said code being obtained by means of a secret key SK _A shared by the sender server 3 and the sender server 1. Optionally, another secret key SK _C shared between these servers, or that can be derived from SK _A , is used to encrypt the exchanges between the sender server 3 and the sender server 1.

The main steps of this embodiment of the invention will now be described.

In a first step E1, a new transaction is authenticated, and authorized, by the sending server 1. More specifically, during a substep E11, the sending client 100 initiates a transaction by sending an original message MES to the server transmitter 3.

During a sub-step E12, said sender server 3 sends an authentication request AUT to the sender server 1. This authentication request AUT contains in particular the identifier of the sending client, the identifier of the recipient client and a value h (MES) obtained by applying a one-way function "h" (for example a "hash" function) to all or part of the original message MES.

During a substep E13, the sender server 1 decides, on the basis of said synchronization information and an evaluation of the authenticity of the sending client 100, to authorize or prohibit the continuation of the transaction. In particular, if a MNSAT parameter as defined above has been chosen for the association considered between the sender domain 102 and the destination domain 202, the sender server 1 verifies that the number of transactions already initiated between these two domains is strictly less than this MNSAT parameter, before possibly allowing a new transaction.

The evaluation of the authenticity of the sender client 100 implies, in the case considered here, where the sender client 100 is in a mobility situation with respect to its home domain, an exchange of messages AUT_C_REQ and AUT_C_REP between the sender server 1 and the sending server 3; for example, the message AUT_C_REQ contains a challenge to the sending client 100, and the message AUT_C_REP contains the response of the sending client 100 to this challenge. In the case where the sending client 100 is not in a mobility situation, such exchange of authentication messages may possibly be superfluous.

If he decides to authorize the transaction, the sending server 1, in step E2, notifies the transaction to the destination server 2. In the case where several servers have been declared by the destination domain: - if, during the phase of connection, an ASIM connectivity matrix as defined above was chosen, then the destination server is chosen from the servers authorized by the ASIM matrix, and - otherwise, it is chosen from all the servers of the domain recipient. More specifically, the sender server 1 sends or has sent by the sending server 3 a notification request NOT to the destination server 2. This notification request NOT contains, on the one hand, elements comprising at least one identifier of the sending client. 100, an identifier of the recipient (s) recipient (s) 200, and the value h (MES); these three elements include the values extracted from the AUT authentication request received by the sender server 1.

Moreover, in the case of a plurality of sending and authorized destination servers, the NOT notification request contains the index i of the particular sender server 1 which authorized the transaction in question, and the index j of the destination server 2 to which the destination is intended. NOT notification request. When the NOT notification request must be sent by the sender server 3, the sender server 1 additionally adds the network address of the destination server 2 which is, a priori, not known to the sender server 3.

Advantageously, the sender server 1 inserts a time stamp into the NOT notification request, in order to avoid replay attacks.

In addition, the NOT notification request contains the network address of the sender server 3 which generated the authentication request AUT and which, in this embodiment, will subsequently send the authenticated message AM.

On the other hand, the NOT notification request contains the transaction index N, which notably allows the sender server 1 and the destination server 2 to select or generate the same encryption key TIDN for the transaction in question when this encryption key depends. from N.

Finally, the notification request NOT is preferably protected by an authentication code obtained by means of an SSK key _M) , shared between the sender server 1 and the destination server 2. Indeed, as explained above, this authentication code makes it possible to reject communications from an unauthorized source, and to protect in integrity the elements of the NOT notification request.

In step E3, this new transaction is verified by the destination server 2. More specifically, during a substep E31, after receiving a notification request NOT, the destination server 2 evaluates its validity on the basis of said synchronization information. The destination server 2 checks in particular that the sender server 1 is authentic, and that the notification request NOT has been altered. Advantageously, the destination server 2 verifies that the sender server 1 index / is actually allowed, according to the ASIM connectivity matrix, to send him a notification request NOT, that the time marker is included in an authorized time window, and that the value of the transaction index N is included in a window of authorized transactions.

Indeed, the maintenance, for a given association, of a window of authorized transactions makes it possible to protect itself from the case where an attacker, having had fraudulently access to the key SSK ,,,,, could generate transactions in big quantity involving the destination server 2. The allowed transaction window is defined by the index of the first active transaction, and by the width of the window that is equal to the MNSAT parameter.

During a substep E32, if the result of said evaluation is positive, the destination server 2 sends the receiving server 4 a transaction notification TERM_NOT containing elements extracted from the notification request NOT, including, in particular, an identifier of the client sender 100, an identifier of the customer (s) recipient (s) 200 and the value h (MES). In a substep E33, after receiving a transaction notification TERM_NOT, the receiving server 4 determines whether the destination client 200 wishes to receive the original message MES (or, in the case of a plurality of recipient clients, which of the they wish to receive the original message MES). To do this, various options are possible, alone or in combination, for each of the recipients connected to this receiver server 4.

Specifically, the receiving server 4 consults sender address lists to try to determine whether the sender-client address 100 is allowed, for at least one recipient client 200, to accept receipt of the original message MES in from this address. For this purpose, the receiving server 4 can consult an LBDD white list of authorized addresses within the entire destination domain 202, and an LBU whitelist of addresses authorized by a particular destination client 200. The receiver server 4 can also consult black lists of prohibited addresses LNDD and LNU respectively. From the recipient (s) indicated in the TERM_NOT transaction notification, the receiving server 4 then generates, according to the lists consulted, a list of RDR refusals, a final agreement list RDA and a provisional agreement list. RPPs defined as follows:

- the list of RDR refusals includes the identifiers of the recipients for which reception of the MES message is refused, either because these recipients do not exist in the recipient domain, or because the address of the sender appears at least in one of the LNDD or LNU lists relating to these recipients;

- the definitive agreement list RDA includes the identifiers of the recipients for which the reception of the message MES is definitively granted; the condition for a recipient to be added to this list is that the address of the sender does not appear in any of the LNDD or LNU lists for that recipient, and that the sender's address in reverse appears in the LBDD or LBU lists for that recipient; and

- the RPA provisional agreement list includes the identifiers of the recipients for which the reception of the MES message is provisionally granted, that is to say is, a priori, neither refused nor accepted. As a variant, the receiving server 4 generates the list of refusals RDR, respectively definitive agreement RDA, without resorting to the blacklists LNDD or LNU, respectively white lists LBDD or LBU, for example by collecting refusals, respectively agreements, explicit of the share of the recipients indicated in the TERM_NOT transaction notification. To do this, the receiving server 4 can send to each client 200 an explicit agreement request EP_NOT containing the relevant data of the transaction notification TERM_NOT, and each destination client 200 sends back a response EP_NOT_R to the request for agreement explicit EP_NOT, said answer EP_NOT_R containing its agreement or refusal.

In all cases, the RPA list contains recipients' IDs that are not in the RDR list or the RDA list.

At least in the case where the result of said determination is positive (that is to say if the RDA list is non-empty), the receiving server 4 sends to the destination server 2, during a substep E34, a notification response TERM_NOT_R containing this result. Optionally, the notification response TERM_NOT_R may also comprise a copy of the lists LR, LAP and LAD, which will, in fine, be retransmitted, for information, to the sending client 100.

In a substep E35, if it receives a notification response TERM_NOT_R containing a positive result, the destination server 2 randomly generates a witness K_REC for said transaction.

In step E4, a KD token is calculated and communicated to whom by right. More specifically, during a substep E41, the destination server 2 calculates a KD token by applying a predetermined encryption algorithm to a set of data dependent (at least) of said K_REC witness, using the encryption key TID _N , presented above. Optionally, we can make depend on the token KD of the value h (MES), in order to increase the variability of the values taken by the token KD from one transaction to another.

In a substep E42, the destination server 2 sends to the server 4 receiving a notification of parameters NOT_R_KD comprising said token KD, the value h (MES) and the address of the sending server 3 which, in this embodiment, will later send the authenticated message AM.

At least if it decides to authorize the transaction, the destination server 2 sends to the sender server 1, during a substep E43, a transaction decision NOT_R_REC expressing its authorization or refusal. Optionally, the authorization from the destination server 2 can be submitted to the reception, within a predetermined time after the sending of said parameter notification.

NOT_R_KD, an acknowledgment NOT_R_KD_ACK from the receiving server 4. In case of authorization, the destination server 2 includes, in said transaction decision NOT_R_REC, the witness K_REC and the network address of the receiving server 4 to which will have to be sent the message authenticated AM.

In all cases, the transaction decision NOT_R_REC comprises said lists RPA, RDA and RDR, a time marker to avoid replay attacks, and the index of the first active transaction for the association considered, given the sender domain.

Preferably, the transaction decision NOT_R_REC is protected by an authentication code obtained by means of a key RSKy, where i is the identifier of the sender server 1 and j is the identifier of the destination server 2 which generates the decision of transaction NOT__R_REC. Indeed, this authentication code makes it possible to authenticate the destination server 2 with the sender server 1, and to protect against a denial of service attack as explained below with reference to the substep E45. During a substep E44, after receiving a transaction decision NOT_R_REC, the sender server 1 verifies its authenticity, including the authenticity of the destination server 2 that sent this transaction decision NOT_R_REC. Advantageously, the sender server 1 verifies that the time marker is included in an authorized time window.

In a substep E45, if the result of said verification is positive, and the RDA list extracted from the transaction decision NOT_R_REC is nonempty, the sender server 1 calculates the token KD as described above with reference in substep E41. Moreover, the use, in the substep E43 above, of an authentication code protecting in particular the value of the K_REC witness ensures that the sender server 1 calculates the good value of the KD token.

In a substep E46, the sender server 1 sends to the sender server 3, in an item notification NOT_R_SEND, elements comprising at least the token KD and the list RDA of the recipient clients having accepted the transaction. Optionally, the sender server 3 may, after receiving the notification of elements

NOT_R_SEND, send an acknowledgment NOT_R_SEND_ACK to the sender server 1.

In step E5, after receiving a notification of elements NOT_R_SEND, the sending server 3 sends to the receiving server 4 an "authenticated message" AM comprising at least the original message MES, and the token KD or, preferably, a value obtained from the token KD by means of a predetermined derivation method (for example, by applying to the token KD a one-way function), so as to avoid issuing the token value KD in the clear.

In step E6, the receiving server 4 strips the authenticated message AM. More specifically, during a substep E61, after receiving an authenticated message AM, the receiving server 4 evaluates its authenticity. The receiver server 4 checks in particular:

the address of the sending server 3 is the address it has received, in the substep E42, in the notification of parameters NOT_R_KD,

the identities of the sending (100) and receiving (200) clients are those indicated in the TERM_NOT transaction notification and the NOT_R_KD parameter notification,

- that by applying the function "h" to the received MES message, it obtains the same value h (MES) as that indicated in the NOT_R_KD parameter notification, and

- that by applying the token derivation process KD received in the NOT_R_KD parameter notification, it obtains the same value as that contained in the authenticated message AM. Then, during a substep E62, if the result of said evaluation is positive, the receiving server 4 transmits the original message MES to the client (s) recipient (s) 200 included in the final agreement list RDA described above.

Finally, during a substep E63, the receiving server 4 sends to the destination server 2 (more precisely, in the case of a plurality of recipient servers, the one that sent it the notification of parameters

NOT_R_KD) an end-of-transaction notification AM_R.

Optionally, this destination server can send to the receiver server 4 an acknowledgment AM_R_ACK. Based on the embodiment of the invention described above, it will be understood that said "synchronization information" must include at least:

- the list of sending and receiving servers authorized within the framework of the association between the two domains, each server being characterized by its index and by at least one network or transport address to which this server is addressable,

the ASIM connectivity matrix setting the transaction authorizations between the sending servers and the destination servers, secret information enabling the sending domain 102 to authenticate the destination server 2, and the destination domain 202 to authenticate the sending server 1, that is, respectively, SSK keys ₁ ,,, and RSK ₁ ,,,,

information enabling the sending domain 102 and the destination domain 202 to obtain the value, for any index transaction N, of the encryption key TID _N used to calculate the token KD,

- the index to be used for the first transaction, and

- the MNSAT width of the transaction window. The implementation of the invention within the nodes of the telecommunications network (in particular, the sender servers 1, recipient 2, transmitter 3 and receiver 4 in the embodiment described above) can be implemented by means of software components. and / or materials.

The software components can be integrated into a typical network node management computer program. Therefore, as indicated above, the present invention also relates to a computer system. This computer system conventionally comprises a central processing unit controlling signals by a memory, as well as an input unit and an output unit. In addition, this computer system can be used to execute a computer program comprising instructions for implementing the method of protection against unwanted messages according to the invention.

Indeed, 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 protection against unwanted messages 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 a computer-readable information medium, comprising instructions of a computer program as mentioned above.

The information carrier may be any entity or device capable of storing the program. For example, the medium may comprise storage means, such as a ROM, for example a CD

ROM or a microelectronic circuit ROM, or a magnetic recording means, for example a diskette ("floppy dise" in English) or a hard disk.

On the other hand, 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.

As a variant, the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted for use in an undesirable message protection device according to the invention.

Claims

A method of protection against undesirable messages in a telecommunications network, comprising, when a sending client (100) attached to a domain said sender domain (102) and connected to a device, said sender server (3), sends a message, said "original message" (MES), to at least one recipient client (200) attached to a domain said destination domain (202) and connected to a device, said receiving server (4), the following steps: a) a device, said sender server (1), belonging to said sender domain (102) acknowledges that a transaction associated with said sender client (100) and said destination client (200) has been initiated, b) if said sender server ( 1) decides to authorize said transaction, it sends, or has sent by said sending server (3), a notification request (NOT) to a device, said destination server (2), belonging to said destination domain (202), said petition notification system (NOT) comprising elements including an identifier of the destination client (200), c) if said destination server (2) decides to authorize the transaction, it randomly generates a witness (K_REC), and sends to the sending server (1 ) a transaction decision (NOT_R_REC) comprising said witness (K_REC), said method being characterized in that it further comprises the following steps: d) the sender server (1) and the destination server (2) independently compute a same token (KD), which results from the application of a predetermined encryption algorithm to a set of data depending at least on said witness (K_REC), by using an encryption key (TID _N ) shared between the sender server (1) and the destination server (2), e) the sending server (1) sends, or has sent by said sending server (3), to the destination server (2) or to said receiving server (4) an "authenticated message" (AM) comprising said original message (MES), and the token (KD) or a token derived value (KD), and f) whether the destination server (2) or the receiving server (4) decides, at least on the basis of the value of the token (KD) or the value derived from the token (KD) received in said authenticated message (AM), to authorize the transaction, the recipient client (200) accepts the original message (MES).

2. Method of protection against unwanted messages according to claim 1, characterized in that said notification request (NOT) is protected in integrity.

A method of protection against unwanted messages according to claim 1 or claim 2, characterized in that said elements of the notification request (NOT) further include a value h (MES) obtained by applying a one-way function " h "to all or part of said original message (MES).

4. Method of protection against unwanted messages according to any one of claims 1 to 3, characterized in that said transmitter server (3) and said sender server (1) are distinct, and in that:

before said step a), the sending server (3) sends to the sender server (1) an authentication request (AUT) comprising at least one identifier of said recipient client (200), and

between said steps d) and e), the sender server (1) sends to the sender server (3) a notification of elements (NOT_R_SEND) comprising said token (KD).

5. Method of protection against unwanted messages according to claim 3 and claim 4, characterized in that said authentication request (AUT) further comprises said value h (MES).

6. A method of protection against unwanted messages according to claim 4 or claim 5, characterized in that the communications between said sender server (3) and said sender server (1) are protected in integrity.

7. Method of protection against unwanted messages according to any one of claims 1 to 6, characterized in that said transaction decision (NOT_R_REC) is protected in integrity.

8. Method of protection against unwanted messages according to any one of claims 1 to 7, characterized in that said recipient server (2) and said receiver server (4) are distinct, and in that: - between said steps b ) and c), the destination server (2) sends to the receiving server (4) a transaction notification (TERM_NOT) comprising elements extracted from said notification request (NOT), and

- Between said steps d) and e), the destination server (2) sends to the receiving server (4) a notification of parameters (NOT_R_KD) comprising said token (KD).

9. A method of protection against unwanted messages according to claim 3 and claim 8, characterized in that said notification of parameters (NOT_R_KD) further comprises said value h (MES).

10. A method of protection against unwanted messages according to any one of claims 1 to 9, characterized in that said destination server (2) and said receiver server (4) are distinct, and in that the communications between these two servers are protected in integrity.

11. Device, said sender server (1) for protection against undesirable messages in a telecommunications network, characterized in that it comprises means for, when a sending client (100) attached to a domain said sender domain ( 102) to which said sender server (1) belongs and connected to a device, said sender server (3), sends a message, said "original message"

(MES), destined for at least one recipient client (200) attached to a domain called destination domain (202) and connected to a device, said receiving server (4):

take note that a transaction associated with said sending client (100) and said receiving customer (200) has been initiated,

in the case where it decides to authorize said transaction, to send or to send by said sending server (3) a notification request (NOT) to a device, said recipient server (2), belonging to said destination domain (202) said notification request (NOT) comprising elements including an identifier of the destination client (200),

receiving from said destination server (2) a transaction decision (NOT_R_REC) comprising a control (K_REC),

calculating a token (KD), which results from the application of a predetermined encryption algorithm to a set of data depending at least on said witness (K_REC), by using an encryption key (TID _N ) shared with the recipient server (2), and - sending, or sending by said sending server (3), to the destination server (2) or to said receiving server (4) an "authenticated message" (AM) comprising said original message (MES), and the token (KD) or a value derived from the token (KD).

12. Device, said destination server (2), for protection against undesirable messages in a telecommunications network, characterized in that it comprises means for, when a sending client (100) attached to a domain said sending domain ( 102) and connected to a device, said sending server (3), sends a message, called "original message" (MES), to at least one recipient client (200) attached to a domain said destination domain (202) to which said recipient server (2) belongs and connected to a device, said receiving server (4): - receiving from said sending server (3) or from a device, said sending server (1), belonging to said sending domain ( 102) a notification request (NOT) comprising elements including an identifier of said recipient client (200),

in the case where he decides to authorize the transaction, generate randomly a witness (K_REC), and send to said sender server (1) a transaction decision (NOT_R_REC) comprising said witness (K_REC), and

calculating a token (KD), which results from the application of a predetermined encryption algorithm to a set of data depending at least on said witness (K_REC), by using an encryption key (TID _N ) shared between the sender server (1) and the destination server (2).

13. Device (2) for protection against unwanted messages in a telecommunications network according to claim 12, characterized in that it further comprises means for: - receiving from said sender server (1) or said server issuer (3) an "authenticated message" (AM) comprising said original message (MES), and the token (KD) or a token-derived value (KD), and

- decide to allow the transaction, at least on the basis of the value of the token (KD) or the value derived from the token (KD) received in said authenticated message (AM).

14. Device (2) for protection against unwanted messages in a telecommunications network according to claim 12, characterized in that it further comprises means for sending to said receiving server (4): - a transaction notification (TERM_NOT) comprising elements including an identifier of said recipient client (200), and

a notification of parameters (NOT_R_KD) comprising said token (KD), and the address of the sending server (3) intended to send to the receiving server (4) an "authenticated message" (AM) comprising said original message (MES), and the token (KD) or a value derived from the token (KD).

15. Non-removable, partially or totally removable data storage means comprising computer program code instructions for implementing said means included in a device for protection against unwanted messages according to any one of claims 1 1 to 14.

16. Computer program downloadable from a communication network and / or stored on a computer readable medium and / or executable by a microprocessor, characterized in that it comprises instructions for the implementation of said means included in a device protection against unwanted messages according to any one of claims 1 1 to 14.