Method of securing exchanges between an applicant node and a destination node
Abstract
The invention relates to a method for securing exchanges between an applicant node (N4) and a destination node (Nl), said nodes belonging to a communication network (2). The method comprises the following steps implemented by a security server (Serv): - a step of reception of a request sent by the applicant node with a view to access to the destination node; - a step of dispatching a response to the request, said response comprising a proof of authentication intended for the destination node and a session key, intended to be used for the exchanges between the applicant node and destination node, characterized in that, at least one secret, to be shared with at least one applicant node, distinct from the session key, being associated with the destination node, the response furthermore comprises said secret. The secret is then used by the applicant node to authenticate intermediate nodes (N3) enabling it to reach the destination node.

Term
2.7 yearsleft in the term
Expires 5 June 2029.
- Priority and filed
- Granted
- Today
- Expires
12 claims: 5 independent, 7 dependent
- 1Procédé pour sécuriser des échanges entre un noeud demandeur (N4) et un noeud destinataire (N1), lesdits noeuds appartenant à un réseau de communication (2), ledit procédé comprenant les étapes suivantes mises en oeuvre par un serveur de sécurisation (Serv) :- une étape de réception (F1) d'une requête (M1, M3) envoyée par le noeud demandeur en vue d'un accès au noeud destinataire ;- une étape d'envoi (F7) d'une réponse (M4) à la requête, ladite réponse comprenant une preuve d'authentification destinée au noeud destinataire et une clé de session, destinée à être utilisée pour les échanges entre les noeuds demandeur et destinataire, caractérisé en ce que , au moins un secret, à partager avec au moins un autre noeud demandeur, distinct de la clé de session, étant associé au noeud destinataire, la réponse envoyée au noeud demandeur contient en outre ledit secret.
- 2Procédé selon la revendication 1, dans lequel la réponse contient en outre un intervalle de temps de validité associé audit secret.
- 3Procédé pour communiquer entre un noeud demandeur (N4) et un noeud destinataire (N1), lesdits noeuds appartenant à un réseau de communication (2), ledit procédé comprenant les étapes suivantes mises en oeuvre par le noeud demandeur :- une étape d'envoi (E1) d'une requête (M1) à un serveur de sécurisation en vue d'un accès au noeud destinataire ;- une étape de réception (E4) d'une réponse (M4) à la requête comprenant une preuve d'authentification destinée au noeud destinataire et une clé de session, destinée à être utilisée pour les échanges entre les noeuds demandeur et destinataire, caractérisé en ce que la réponse comprend en outre au moins un secret et en ce que ledit procédé comprend en outre une étape d'authentification d'au moins un autre noeud au moyen dudit au moins un secret, ledit autre noeud étant apte à joindre le noeud destinataire.
- 4Procédé selon la revendication 3, dans lequel la réponse comprenant en outre un intervalle de temps de validité associé audit secret, le noeud demandeur sélectionne un secret valide en fonction d'un instant courant.
- 5Procédé selon la revendication 3, dans lequel l'étape d'envoi d'une demande d'accès à un noeud destinataire est effectuée suite à une détection d'absence de secret valide.
- 6Procédé selon la revendication 3, dans lequel le noeud demandeur et le noeud destinataire communiquent par un chemin constitué de noeuds authentifiés au moyen du secret.
- 7Serveur (300) pour sécuriser des échanges entre un noeud demandeur et un noeud destinataire dans un réseau de communication, comprenant :- des moyens de réception (302) d'une requête envoyée par un noeud demandeur en vue d'un accès à un noeud destinataire ;- des moyens d'envoi (304) d'une réponse à la requête, ladite réponse comprenant une preuve d'authentification destinée au noeud destinataire et une clé de session, destinée à être utilisée pour les échanges entre les noeuds demandeur et destinataire, caractérisé en ce que les moyens d'envoi sont en outre agencés pour inclure dans la réponse un secret, ledit secret, à partager avec au moins un autre noeud demandeur, distinct de la clé de session, étant associé au noeud destinataire.
- 8Noeud (400) d'un réseau de communication, comprenant :- des moyens d'envoi (402) d'une requête à un serveur en vue d'un accès à un noeud destinataire ;- des moyens de réception (404) d'une réponse à la requête, la réponse comprenant une preuve d'authentification destinée au noeud destinataire et une clé de session, destinée à être utilisée pour les échanges entre le noeud et le noeud destinataire, caractérisé en ce que les moyens de réception sont en outre agencés pour recevoir une réponse comprenant au moins un secret et en ce que ledit noeud comprend en outre des moyens d'authentification (406) d'au moins un autre noeud au moyen dudit au moins un secret, ledit autre noeud étant apte à joindre le noeud destinataire.
- 9Système de communication dans un réseau de communication, comprenant un serveur selon la revendication 7 et une pluralité de noeuds selon la revendication 8.
- 10Programme d'ordinateur comportant des instructions pour la mise en oeuvre du procédé pour sécuriser des échanges selon la revendication 1 par un serveur d'un réseau de communication, lorsque ce programme est exécuté par un processeur.
- 11Programme d'ordinateur comportant des instructions pour la mise en oeuvre du procédé pour communiquer avec un noeud destinataire selon la revendication 3 par un noeud demandeur d'un réseau de communication, lorsque ce programme est exécuté par un processeur.
- 12Signal supportant une réponse à une demande d'accès à un noeud destinataire émise par un noeud demandeur, ladite réponse étant émise par un serveur au noeud demandeur et comprenant une preuve d'authentification destinée au noeud destinataire et une clé de session, destinée à être utilisée pour des échanges entre les noeuds demandeur et destinataire, caractérisé en ce que ladite réponse comprend en outre au moins un secret ledit secret, à partager avec au moins un autre noeud demandeur, distinct de la clé de session, étant associé au noeud destinataire.
Independent claims12
86 paragraphs, as filed
p0001The invention relates to an authentication technique in a communication network.
p0002We work in the context of a communication network ad-hoc kind. An ad-hoc network is a network composed of a set of nodes having the ability to communicate without deploying fixed infrastructure. Nevertheless, it is possible that the ad-hoc network is connected to an infrastructure, for example for access to an Internet type communication network. The nodes which constitute such a network may be mobile or stationary. These nodes interact and cooperate with each other, based on a possibly multi-hop communication. Thus, trade between the requesting node and a destination node can optionally pass through at least one intermediate node.
p0003The document "<nplcit id="ncit0001" npl-type="s"><text>Kerberos Authentication Assisted in Mobile Ad-hoc Networks "by A. and C. McDonald Pirzada, published in the proceedings of the conference" 27th Australasian Computer Science Conference 2004 "</text></nplcit>Describes a type of Kerberos authentication mechanism in an ad-hoc network. A node N1 applicant contacts a server for access from another node N2. Following a successful authentication, the server transmits data, called ticket or proof of authentication, protected by means of a secret key KN2 the other node N2, and a session key KN1N2 protected by means of a secret key KN1 the requesting node N1. The ticket includes KN1N2 session key. The requesting node N1 and obtains the session key KN1N2 by decryption using the key KN1. Then, it transmits an access request to another node N2, the request including the ticket and given a KN1N2 signed with the session key. The other node N2 decrypts the ticket using its KN2 key and gets KN1N2 session key. Using the latter, it decrypts the data signed and thus authenticates the requesting node N1. This mechanism ensures an identity theft detection requesting node, a detection of replay attacks, establishment of secure channels and authentication of the requesting node to the other node. Only the requesting node is authenticated to the other node by providing the authentication and proof of data signed by the KN1N2 session key. If the other node does not subsequently used KN1N2 session key obtained by decryption using its own secret key KN2 proof of authentication, the requesting node has no guarantee that the other node is a node of confidence. In addition, in the case of a multi-hop communication passing through at least one intermediate node, the intermediate node is not necessarily a trusted node.
p0004The document "<nplcit id="ncit0002" npl-type="s"><text>Providing Authentication and Access Control in Vehicular Network Environment "Hasnaa Moustafa et al. Published in the proceedings of the conference" IFIP TC-11 21ST INTERNATIONAL INFORMATION SECURITY CONFERENCE, SEC 2006 ", pages 62-73</text></nplcit>Discloses another authentication mechanism for establishing secure communications between vehicles.
p0005An object of the invention is to remedy the drawbacks of the prior art.
p0006The invention provides for this purpose a method for securing exchanges between a requesting node and a destination node, said nodes belonging to a communication network, said method comprising the following steps implemented by a security server:<ul><li>a step of receiving a request sent by the requesting node for access to the destination node;</li><li>a step of sending a response to the request, said response comprising an authentication evidence for the destination node and a session key to be used for exchanges between the applicant and recipient nodes,</li></ul>wherein at least one secret to share with at least one other node applicant separate from the session key, being associated with the destination node, the response to the requesting node also contains said secret ..
p0007Note that the invention originates from potential malice in an ad hoc type of communication network. However, the invention is applicable to any communication network in which it is necessary to follow a secure way.
p0008In response to the request, the server transmits not only information related to the exchange between the requesting node and the destination node, such as proof of authentication to provide the recipient node and a session key for trade between the applicant and the destination node node, but also a secret to share with at least one requesting node and associated with the destination node. Thus, depending on the destination node, there is a group of nodes comprising at least the requesting node and the destination node. This group of nodes sharing a secret, to improve the security of exchanges in the group. One case was performed, thus providing both an authorization to access a service provided by the destination node and the shared secret in the group. The server, acting as a trusted third party, allows the implementation of an indirect authentication of the requesting node on behalf of the destination node and the requesting node provides the shared secret allowing him to establish contact with the knot addressee by a secure connection. The uniqueness of the query, respectively of its response, enables a simple setup and particularly effective work. It is possible to simply distribute the shared secret in exchange for access to the destination node without requiring re-authentication with another trusted third party. The fact that a group of node holds the shared secret and be able to prove it is possible to deduce that it is implicitly authenticated to the server. The use of a shared secret allows more to implement quick and easy authentication techniques based on symmetric cryptography, adapted for implementation on nodes that may have resources, such as its battery, its memory capacity, limited.
p0009For an application of an ad-hoc network, the destination node provides such a service in a particular geographical area. The nodes, having obtained the shared secret and thus implicitly authenticated to the server, thus form a trusted group safe trade to the destination node in a potentially multi-hop link. The destination node can get him on the secret by a special relationship with the server.
p0010Thus, it is possible to improve the security of exchanges between an applicant node and a destination node in a communication network of ad-hoc kind.
p0011In one embodiment, the response also contains a validity time interval associated secret audit.
p0012Thus, it is possible to distribute a plurality of shared secrets which are associated with respective validity intervals. The requesting node then determines in accordance with a common clock the secret to be used. This limits the requests to the server to obtain valid secret and avoid simultaneous requests when the secrets are no longer valid. The shared secret is frequently renewed, this avoids the theft of the shared secret.
p0013The invention further relates to a method for communicating between a requesting node and a destination node, said nodes belonging to a communication network, said method comprising the following steps implemented by the requesting node:<ul><li>a step of sending a request to a secure server for access to the destination node;</li><li>a step of receiving a response to the request to include an authentication evidence for the destination node and a session key to be used for exchanges between the applicant and recipient nodes,</li></ul>characterized in that the response further comprises at least one secret and in that said method further comprises a step of authenticating at least one further node by means of said at least one secret, said other node being adapted to join the recipient node.
p0014The requesting node and gets a secret associated with a destination node, shared in a group of nodes, said group trust. He can authenticate nodes with which it has a direct relationship, that is to say, its immediate neighbors, with the shared secret and privilege neighboring nodes authenticated during the exchanges with the destination node. He obtained a guarantee that a malicious node does not respond, instead of the destination node and also no malicious node is inserted into the node chain connecting the requesting node and the destination node.
p0015In one embodiment, the response further including a validity time interval associated secret audit, the requesting node selects a secret valid based on a current time.
p0016Thus, the group of nodes share a secret in common regardless of the time at which they submitted a request to the server.
p0017In another embodiment, the step of sending a request for access to a destination node is made following a secret no valid detection.
p0018Whenever the requesting node has no valid secrets, it contacts the server again, in order to maintain the constitution of the trust group.
p0019In addition, the requesting node and the destination node then communicate via a path consisting of nodes authenticated using the secret.
p0020The invention also relates to a server for secure interchanges between a requesting node and a destination node in a communication network, comprising:<ul><li>means for receiving a request sent by a requesting node for access to a destination node;</li><li>means for sending a response to the request, said response comprising an authentication evidence for the destination node and a session key to be used for exchanges between the applicant and recipient nodes,</li></ul>wherein the sending means are also arranged to include in the response a secret, said secret to share with at least one other node applicant separate from the session key, being associated with the destination node
p0021The invention further relates to a node of a communication network, comprising:<ul><li>means for sending a request to a server for access to a destination node;</li><li>means for receiving a response to the request, the response including an authentication evidence for the destination node and a session key to be used for exchanges between the node and the destination node,</li></ul>characterized in that the receiving means are further arranged for receiving a response including at least one secret and in that said node further comprises means for authenticating at least one further node by means of said at least one secret, said another node being adapted to join the destination node.
p0022The invention also relates to a communication system in a communication network comprising a server as described above and a plurality of nodes as described above.
p0023The invention further relates to a computer program comprising instructions for carrying out the method for secure exchange as previously described by a server of a communication network, when this program is executed by a processor.
p0024The invention also relates to a computer program comprising instructions for carrying out the method for communicating with a destination node as described above by a node requesting a communication network, when this program is executed by a processor.
p0025The invention further relates to a signal carrying a response to an access request to a receiving node sent by a requesting node, said response being sent by a server to the requesting node and comprising an authentication evidence for the destination node and session key, to be used for exchanges between the applicant and recipient nodes, characterized in that said response further comprises at least one said secret secret to share with at least one other node applicant separate from the session key , being associated with the destination node.
p0026The invention will be better understood using the following description of a particular embodiment of the methods of the invention, with reference to the accompanying drawings in which:<ul><li>the <figref idrefs="f0001">figure 1</figref> represents a communication network;</li><li>the <figref idrefs="f0002">2</figref> shows a part of steps of the methods according to a particular embodiment of the invention;</li><li>the <figref idrefs="f0002">3</figref> represents another part of the method for communicating according to the particular embodiment of the invention; </li><li>the <figref idrefs="f0001">4</figref> represents a request for access according to the embodiment of the invention;</li><li>the <figref idrefs="f0001">5</figref> represents a response to the request for access depending on the particular embodiment of the invention;</li><li>the <figref idrefs="f0001">6</figref> shows in more detail a field of the response depending on the particular embodiment of the invention;</li><li>the <figref idrefs="f0003">7</figref> shows a device for securing exchanges according to the particular embodiment of the invention;</li><li>the <figref idrefs="f0003">8</figref> represents a node of the communication network according to the particular embodiment of the invention.</li></ul>
p0027On the <figref idrefs="f0001">figure 1</figref>Is shown an ad-hoc network 2. It comprises a plurality of nodes, denoted N1 to N8. These nodes are able to communicate with each other via wireless links. Communication between two nodes of the ad-hoc network 2 can pass through other nodes; it is in this case of multi-hop communication. For example, communication between the nodes N1 and N4 passes through the node N3 and is marked on the<figref idrefs="f0001">figure 1</figref> by a dotted line. Similarly, communication between nodes N2 and N8 passes through nodes N5 and N7 and communication between nodes N2 and N6 passes through the node N5. These nodes can be mobile or fixed.
p0028Each node N1-N8 ad-hoc network 2 has a secret key KN1-KN8.
p0029Subsequently, the nodes N1 and N2 have a special role node application provider. It is a node of the ad-hoc network 2, which remains fixed by example with which other nodes of the ad-hoc network can communicate in order to have access to a given or a given application service. By way of nonlimiting examples, it comes to downloading of audiovisual content, video content or application "video streaming", printing, ...
p0030Serv securing a server located in a core network 1 of a communication operator. This Serv secure server is configured to authenticate the nodes of the ad-hoc network and provide proof of authentication so that they can access applications offered by the nodes N1 and N2 Application providers. The Serv secure server is arranged to store the identifiers of nodes allowed to access the ad hoc network. At each node identifier is associated with the secret key thereof. Thereafter, the Serv secure server uses the Kerberos protocol as specified in the document of the Internet Engineering Task Force RFC 4120 entitled "The Kerberos Network Authentication Service". He plays the role of a trusted third party. It includes two entities: a first entity playing the role of an authentication entity, denoted AS for "Authentication Server", and a second entity playing the role of a ticket issuing service, denoted TGS for "Ticket Grant Service".
p0031AP Access Point allows nodes of ad hoc network 2 to access the core network 1, and so contact the Serv secure server. Subsequently, the access point AP is arranged to act as a proxy Kerberos, as specified in the IETF document "draft-ietf-krb-wg-iakerb-00."
p0032The method for securing exchanges, as implemented by the security server, will now be described in connection with the <figref idrefs="f0002">2</figref>.
p0033The method for communicating, as implemented by a requesting node, will be described as to have dealings with the <figref idrefs="f0002">Figures 2 and 3</figref>.
p0034In the example described, the user of the requesting node N4 wants to communicate with the node N1 application provider.
p0035The requesting node N4 detected in a first step E1, denoted "S_RAS (NC)" on the <figref idrefs="f0002">2</figref>That he does not have a valid secret to communicate in the ad-hoc network 2 or does not have a valid authentication evidence for the N1 application provider node. The secret is associated with the N1 application provider node and to be shared by the nodes of the group ad-hoc network communication with the latter. The authentication proof is to be supplied to the node N1 application provider and provides thereto a proof that the requesting node N4 has been authenticated to the security server Serv.
p0036Still in this step E1, the requesting node N4 transmits a request M1 to Serv security server for access to the application provider node N1. It is in the Kerberos AS-REQ message.
p0037The trade is through the AP access point that uses a delegation mechanism (or function "Proxy Kerberos" in English). However, to simplify the description and<figref idrefs="f0002">2</figref>, The exchanges were not decomposed.
p0038M1 This request is received by the security server Serv, specifically by the AS entity in an F1 receiving step, denoted "R_RAS (NC)" on <figref idrefs="f0002">2</figref>.
p0039After checking the identifier of the requesting node N4, the Serv security server AS entity sends in a step F2, denoted "S_RepAS" on the <figref idrefs="f0002">2</figref>A response to the request of M2 message for access to the N1 application provider node comprising, according to the Kerberos protocol:<ul><li>a first ticket T<sub>TGS.</sub> and,</li><li>Ksession a first encrypted session key using the secret key KN4 the requesting node N4.</li></ul>
p0040In the Kerberos protocol, there is an AS-REP message.
p0041This first ticket T<sub>TGS</sub> Serv is encrypted by the security server AS entity by means of a key Ktgs. It contains such information on the requesting node N4 but also the first key Ksession session to be used by the latter to obtain an authentication evidence.
p0042The query response message M2 for access to the N1 application provider node is received by the requesting node N4 in a step E2, denoted "R_RepAS" on <figref idrefs="f0002">2</figref>.
p0043After these messages M1 and M2 trade, the requesting node N4 has the first ticket T<sub>TGS</sub>, He can not decipher, and the first Ksession session key. If the requesting node N4 is not that he says is, it is not possible to decrypt the first key Ksession session because only the real requesting node N4 has the secret key to decrypt KN4 the first key Ksession session.
p0044In a step E3, denoted "S_RTGS" on <figref idrefs="f0002">2</figref>The requesting node N4 transmits to the TGS entity of securing a server M3 request for proof of authentication. In the Kerberos protocol, it is a message TGS-REQ. M3 This request includes the first ticket T<sub>TGS</sub> transmitted by the server Serv AS entity in the response message M2 to the request for access to the N1 application provider node and protected information using the first session key Ksession.
p0045M3 request for proof of authentication is shown in <figref idrefs="f0001">4</figref>.
p0046Such a request 100 includes, according to RFC 4120:<ul><li>a field 102, the version of Kerberos;</li><li>a field 104 indicating the type of message;</li><li>a field 106 comprising a given for pre-authenticating;</li><li>a field 108 including the message body.</li></ul>
p0047The field 108 includes, among others, an identifier of the requesting node N4 and flags 110 for signaling support or not protocol options. In the particular embodiment of the invention, a flag allows the requesting node N4 to report his complaint also seeks a secret associated with the N1 application provider node. This ensures compatibility with a server implementing the standard Kerberos protocol and also to distinguish between nodes that support this option nodes that do not support it.
p0048This M3 request authentication evidence is received by the TGS entity Serv security server in a step F3, denoted "R_RTGS" on the <figref idrefs="f0002">2</figref>.
p0049In a step F4, denoted "Auth" on <figref idrefs="f0002">2</figref>The TGS entity security server decrypts the first ticket T<sub>TGS</sub> with its own secret key Ktgs. She gets the first Ksession session key and can decrypt the information sent by the requesting node N4. This allows it to implicitly authenticate the requesting node N4 since it brings him proof that he has the good KN4 key. The TGS entity then determines a second key KN1N4 session for use, if necessary, for subsequent exchanges between the N1 application provider node and the requesting node N4. The TGS entity also determines a proof of authentication, allowing access to the application provider node N1. This authentication evidence includes the second session key KN1N4 and is protected by means of the secret key KN1 of N1 application provider node.
p0050In a test step F5, denoted "Test_F" on <figref idrefs="f0002">2</figref>The TGS entity checks if the request includes the M3 field 110 a flag indicating that the application also seeks a shared secret.
p0051If such a flag is present, in a step F6, denoted "Det_Kad" on the <figref idrefs="f0002">2</figref>The TGS Kad entity determines a secret associated with the N1 application provider node to which the node N4 applicant wishes to access, and meant to be shared by a group of nodes in the ad-hoc network 2.
p0052In a step F7, denoted "S_RepTGS" on <figref idrefs="f0002">2</figref>The TGS entity sends the applicant a node N4 M4 response to the request including:<ul><li>the authentication evidence to provide the N1 application provider node determined in step F4, protected by means of the secret key of the application provider KN1 node N 1;</li><li>the second session key, KN1N4, to be used for exchanges between the requesting node N4 and N1 application provider node and determined in step F4, protected by the first Ksession session key;</li><li>if the flag indicating that the application also seeks a secret was present in the request M3, the shared secret Kad determined in step F6, protected by the first Ksession session key.</li></ul>
p0053Such M4 response to the request of proof of authentication is shown <figref idrefs="f0001">5</figref>. In the Kerberos protocol, it is a TGS-REP message.
p0054Such a response 200 includes, according to RFC 4120:<ul><li>a field 202, the version of Kerberos;</li><li>a field 204 indicating the type of message;</li><li>a field 206 comprising a given for pre-authenticating; </li><li>a field 208 including a field requesting node;</li><li>a field 210 including a name of the requesting node;</li><li>a field 212 including the authentication evidence to provide the N1 application provider node;</li><li>a field 214 comprising data protected by encryption using the first key in a known session Ksession by both the TGS entity and the requesting node N4.</li></ul>
p0055The figures included in the field 214 are shown in <figref idrefs="f0001">6</figref>. They include:<ul><li>the second session key 216 KN1N4;</li><li>a field 218 including flags for signaling support or not protocol options; in the particular embodiment of the invention, a flag allows Serv secure server to report that a secret is in following the data 214;</li><li>a field 222 including Kad secret depending on the value of the flag on the shared secret, quoted above.</li></ul>
p0056In an alternative embodiment, a Kad secret is assigned a secret validity time interval, transmitted in a field 220.
p0057M4 response is received by the requesting node N4 in a step E4, denoted "R_RepTGS" on the <figref idrefs="f0002">2</figref>.
p0058Following the exchange of messages M3 and M4, the requesting node N4 has an authentication to provide the proof of N1 node application provider, it can not decrypt the second key KN1N4 session and shared secret Kad nodes in the group ad-hoc network 2.
p0059Note also that in the case of a multi-hop communication, where the requesting node N4 transmits the authentication proof of the N1 application provider node, no intermediate nodes, contributing to the delivery of the proof authentication, can decrypt it and therefore can not obtain the second key KN1N4 session. Indeed, the authentication evidence is protected by encryption using the secret key of KN1 N1 application provider node and can not be decrypted by any node.
p0060The requesting node N4 with the shared secret Kad, then it is possible to implement an authentication step for each node with which it is directly connected, that is to say, the neighboring nodes. Means neighbor node, a node located in a radio coverage area of the requesting node N4. The requesting node N4 has the shared secret Kad to a neighboring node as proof of authenticity and the neighboring node also proves its authenticity by presenting the same key. This is such a mutual authentication EAP-PSK using the shared secret Kad. This type of authentication has the advantage of requiring limited treatment resources.
p0061This authentication mechanism is described in RFC 4764 of the IETF. Described briefly in connection with the<figref idrefs="f0002">3</figref>.
p0062The requesting node N4 transmits a message L1 Identity Request neighbor node N3, for example "EAP-Request Identity". The neighbor node N3 transmits its identity Idv to requesting node N4 in a L2 message, for example "EAP Response Identity". In an L3 message, for example "EAP-Request / PSK", the requesting node N4 transmits its own identity and an Idd Rd random variable that has generated the neighboring node N3. The neighbor node N3 determines a random variable Rv, calculates a first MAC authentication code on the data set (Idv, Rv, Idd, Rd) signed by the shared secret Kad and transmits to the requesting node N4 Idv his ID, Rv random variable and the first MAC authentication code L4 in a message, such as "EAP-response / PSK". The node N4 applicant checks the first MAC authentication code using the shared secret to authenticate the Kad neighboring node N3. Then, the requesting node N4 transmits L5 in a message, such as "EAP-Request / PSK", the neighboring node N3 Rd random variable and a second MAC authentication code calculated over all constituted his identity Idd and the random variable Rv, signed with the shared secret Kad. The neighbor node N3 verifies the second MAC authentication code using the shared secret and Kad forward to requesting node N4 L6 a message, such as "EAP-Response / PSK" which includes the random variable Rd. L7 A Message eg "EAP-success" on success, transmitted from the requesting node to the neighboring node N4 N3, completes the authentication step.
p0063It is then possible to focus, for routing messages between the requesting node N4 and N1 application provider node, the nodes of the ad-hoc network 2 in the group sharing the secret Kad. It is possible to build roads used by a routing protocol using a metric of security. Such a mechanism is described for example in the article entitled "<nplcit id="ncit0003" npl-type="s"><text>Secure Routing for Mobile Ad-hoc Networks "Argyroudis P. and D. O'Mahony, published in IEEE Communications Survey, 3rd quarter 2005</text></nplcit>. This article describes a SAR mechanism for "Secure Ad hoc Routing", applicable to reactive routing protocols such as AODV protocol for "Ad-hoc On-Demand Distance Vector" or the DSR protocol for "Dynamic Source Routing" which incorporates a metric of safety messages Route Request to build roads between the nodes with a defined level of security.
p0064The requesting node N4 thus transmits its access request to the application provider node by presenting its evidence authentication, which, for the record, is protected by the secret key KN1 of N1 node application provider. The access request is then transferred by the routing protocol at the layer 3 OSI. An intermediate node N3 receiving the access request can not decrypt the authentication proof and relays this request by choosing to turn a neighboring node based on the condition of authenticity of its neighbors. This is repeated until N1 application provider node, which, by decrypting the authentication proof by means of its own secret key KN1, obtains the second key KN1N4 session. The authentication evidence proves that the requesting node N4 is authenticated to the security server Serv. The authentication and proof is sent to the application provider node N1 by a path consisting of nodes authenticated using the shared secret. N1 application provider node may then provide the service requested by protecting the traffic using the second key KN1N4 session. Subsequent exchanges between the requesting node N4 and N1 application provider node also use this road or other way consists of nodes authenticated using the shared secret.
p0065In another embodiment of the invention, upon receipt of a request sent by the requesting node N4 at step F1, the TGS entity determines in step F6 a plurality of shared secrets and associates each shared secret a time interval of validity of secrecy. Each shared secret Kad has a limited life span D. The server transmits to step F7 in response a set of shared secrets valid for the following periods.
p0066The response is received at step E4 by the requesting node N4.
p0067Then when it must authenticate one of his neighbors, the requesting node N4 selects a valid shared secret based on a current time.
p0068Thus, the Serv secure server distributing a plurality of keys in a request for access to the destination node, the nodes require less frequently the server and more, these solicitations are made of unsynchronized way.
p0069a server will now be described for securing exchanges between a requesting node and a destination node in a communication network in connection with the <figref idrefs="f0003">7</figref>.
p0070Such a server 300 includes:<ul><li>storage means 308, denoted "KN" on the <figref idrefs="f0003">7</figref>Arranged for storing secret keys respectively associated with the nodes of the communication network;</li><li>a reception module 302 a query, noted "Rec_S" on <figref idrefs="f0003">7</figref>, The request being sent by a requesting node for access to a destination node;</li><li>a determination module 310 for data access to a destination node, noted "Det_PK" on <figref idrefs="f0003">7</figref>, Arranged to determine an authentication evidence for the requesting node and a session key for use during the exchanges between the applicant and the destination node node; </li><li>a module 306 to obtain at least a shared secret, denoted "Det_Kad" on <figref idrefs="f0003">7</figref>The secret is associated with a destination node and to share in a group of nodes including at least one requesting node, separate from the session key;</li><li>an encryption / decryption module 312, denoted "C / D_S" on the <figref idrefs="f0003">7</figref>Arranged to encrypt data for a node according to its respective secret key extracted from the storage means 308 or in accordance with a session key shared between a node and the server, and for decrypting received data protected by the session key;</li><li>a sending module 304 a response to the request, noted "S_S" on <figref idrefs="f0003">7</figref>Said response including the authentication evidence for the destination node, the session key, to be used for exchanges between the applicant and recipient nodes, and at least one obtained secret.</li></ul>
p0071In a particular embodiment of the invention, the determination module 310 for data access to a destination node implements the steps of the Kerberos protocol.
p0072In a variant to the embodiment described, the obtaining module 306 of a shared secret further obtains an associated validity time interval. In this case, the sending module 304 also transmits the response in the associated validity time interval.
p0073We will now describe a node of a communication network in connection with the <figref idrefs="f0003">8</figref>.
p0074Such a node 400 comprises:<ul><li>a sending module 402, denoted "S_n" on <figref idrefs="f0003">8</figref>, A request to a server for access to a destination node;</li><li>a reception module 404 a response to the request, noted "Rec_N" on <figref idrefs="f0003">8</figref>The response comprising an authentication evidence for the destination node, a session key to be used for exchanges between the node and the destination node, and at least a shared secret;</li><li>an encryption / decryption module 410, denoted "C / D_N" on the <figref idrefs="f0003">8</figref>Arranged to decrypt data according to its respective secret key or using a session key shared between the node and a server and to encrypt data using the session key;</li></ul><ul><li>an authentication module 406, noted "Auth" on <figref idrefs="f0003">8</figref>Of at least one further node by means of said at least one secret, said other node being adapted to reach the recipient node;</li><li>a module 408 for determining paths in a communications network, denoted "Det_R" on the <figref idrefs="f0003">8</figref>, Arranged to determine a path to the destination node favoring authenticated nodes.</li></ul>
p0075In the alternative to the described embodiment, the receiving module 404 is arranged to receive a validity time interval associated with a shared secret and the authentication module 406 is arranged to determine based on a current time a shared secret valid.
p0076The modules 302, 304, 306 of the security server are arranged to implement the method for securing exchanges described above. This is preferably software modules comprising software instructions for executing the steps of the protection method described above, implemented by a server of the communication network. The invention therefore also relates to:<ul><li>a program server for a communication network, comprising program instructions for controlling the execution of the process steps to secure the exchange described above, when said program is executed by a processor;</li><li>a recording medium readable by a server of a communication network on which is recorded the program server for a communication network.</li></ul>
p0077The modules 402, 404, 406 of the node of the communication network are arranged to implement the method for communicating with another node previously described. This is preferably software modules comprising software instructions for executing the steps of the method for communicating previously described, implemented by a node of the communication network. The invention therefore also relates to:<ul><li>a program node of a communications network, comprising program instructions for controlling the execution of the process steps to communicate previously described, when the program is executed by a processor;</li><li>a recording medium readable by a node of a communication network on which is recorded the program to node of a communications network.</li></ul>
p0078The software modules may be stored in or transmitted by a data carrier. This can be a hardware storage medium, such as a CD-ROM, magnetic disk or hard drive, or a transmission medium such as an electrical signal, optical or radio, or a telecommunications network.
p0079The invention also relates to a communication system in a communication network comprising a server for secure exchange and a plurality of nodes as described above.
p0080The description was made with a shared secret associated with an application provider node N1. In another variant, it is also possible to share such a secret for the entire ad-hoc network 2 and associate it to all application providers knots.
p0081The description has been made in the particular case of a security server comprising both entities AS and TGS. It is also possible to provide a server entity.
p0082The description has also been made in the particular case of an application provider node. It is understood that the methods of the invention apply to any recipient node with which the requesting node wishes to communicate.
p0083The invention can also be implemented using other types of mechanisms, wherein a security server transmits an authentication proof to be provided by a requesting node to an application provider node.
p0084Message exchanges were sequentially described. It is also possible to separate in time the exchange of messages M1 (request for access to the N1 application provider node) and M2 (M1 response to the request) of those messages M3 (M3 request for evidence authentication) and M4 (M4 response to the query).
p0085In yet another embodiment, it is also possible, if the first session key Ksession a valid associated, directly send the M3 request for proof of authentication.
p0086The description was also made as part of an ad-hoc network. The application of the invention should not be restricted to this type of network. It is also applicable to any type of communication network, wherein a node wishes to establish a path established through trusted nodes.
3 sheets
Sheet 1 Sheet 2 Sheet 3
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| US10833860B2 | Cited by | United States of America | Applicant |
| US10764291B2 | Cited by | United States of America | Applicant |
| US11038698B2 | Cited by | United States of America | Applicant |
| US11991273B2 | Cited by | United States of America | Applicant |
| US11088829B2 | Cited by | United States of America | Applicant |
| US11522681B2 | Cited by | United States of America | Applicant |
| US10833856B2 | Cited by | United States of America | Applicant |
| US11025413B2 | Cited by | United States of America | Applicant |
| US11038671B2 | Cited by | United States of America | Applicant |
| EP1906619A | Cites | European Patent Office (EPO) | – |
| MOUSTAFA ET AL: "Providing Authentication and Access Control in Vehicular Network Environment" PROCEEDINGS OF THE IFIP TC-11 21ST INTERNATIONAL INFORMATION SECURITY CONFERENCE, SEC 2006, MAY 206, KARLSTAD, SWEDEN, vol. 201, 25 juillet 2006 (2006-07-25), pages 62-73, XP002514568 Springer Boston ISBN: 978-0-387-33405-9 | Non-patent | – | – |
8 members in 6 offices
Members8
| Document | Office | Kind | |
|---|---|---|---|
| FR2932936A1 | France | A1 | |
| WO2010007267A1 | World Intellectual Property Organization (WIPO) | A1 | |
| EP2294850A1 | European Patent Office (EPO) | A1 | |
| EP2294850B1This record | European Patent Office (EPO) | B1 | |
| AT536059T | Austria | T | |
| ATE536059T1 | Austria | T1 | |
| ES2377109T3 | Spain | T3 | |
| PL2294850T3 | Poland | T3 |
66 legal events, as 10 offices reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | Office | |
|---|---|---|---|
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Fee paymentPLFP | PLFP | FR | |
| Fee paymentPLFP | PLFP | FR | |
| Fee paymentPLFP | PLFP | FR | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Gb: european patent ceased through non-payment of renewal feeCeasedGBPC | GBPC | EP | |
| Patent ceasedCeasedPL | PL | CH | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal feeWithdrawnR119 | R119 | DE | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Be: lapsedLapsedBERE | BERE | EP | |
| No opposition filed against granted patent, or epo opposition proceedings concluded without decisionGrantedR097 | R097 | DE | |
| No opposition filedOpposition26N | 26N | EP | |
| No opposition filed within time limitOppositionORIGINAL CODE: 0009261PLBE | PLBE | EP | |
| Information on the status of an ep patent application or granted ep patentGrantedSTATUS: NO OPPOSITION FILED WITHIN TIME LIMITSTAA | STAA | EP | |
| Deletion acc. to par. 5 (withdrawal of the translation of the ep patent)MK05 | MK05 | AT | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| European patents designating ireland treated as always having been voidFD4D | FD4D | IE | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Translation of ep patentT3 | T3 | PL | |
| Lt: invalidation of european patent or patent extensionLTIE | LTIE | EP | |
| Definitive protectionFG2A | FG2A | ES | |
| Discontinued in the netherlands as no translation has been filedVDEP | VDEP | NL | |
| Dpma publication of mentioned ep patent grantGrantedR096 | R096 | DE | |
| European patents granted designating irelandGrantedLANGUAGE OF EP DOCUMENT: FRENCHFG4D | FG4D | IE | |
| Designated contracting statesAK | AK | EP | |
| European patent takes effect as a national patent in ch/liEP | EP | CH | |
| European patent grantedGrantedNOT ENGLISHFG4D | FG4D | GB | |
| (expected) grantORIGINAL CODE: 0009210GRAA | GRAA | EP | |
| Grant fee paidORIGINAL CODE: EPIDOSNIGR3GRAS | GRAS | EP | |
| Request for extension of the european patent (deleted)DAX | DAX | EP | |
| Despatch of communication of intention to grant a patentORIGINAL CODE: EPIDOSNIGR1GRAP | GRAP | EP | |
| Request for examination filed17P | 17P | EP | |
| Designated contracting statesAK | AK | EP | |
| Request for extension of the european patentAX | AX | EP | |
| Public reference made under article 153(3) epc to a published international application that has entered the european phaseORIGINAL CODE: 0009012PUAI | PUAI | EP |
Numbers
- Publication
- 2294850
- Application
- 97843973
Titles3
- German
- VERFAHREN ZUR SICHERUNG VON AUSTAUSCHPROZESSEN ZWISCHEN EINEM SENDEKNOTEN UND EMPFANGSKNOTEN
- English
- METHOD OF SECURING EXCHANGES BETWEEN AN APPLICANT NODE AND A DESTINATION NODE
- French
- PROCEDE POUR SECURISER DES ECHANGES ENTRE UN NOEUD DEMANDEUR ET UN NOEUD DESTINATAIRE
Classification
- CPC, 10
- H04L9/0838
- H04L63/062
- H04L63/065
- H04L63/0807
- H04W84/18
- H04L9/321
- H04L9/3236
- H04L2209/80
- H04W12/04
- H04W12/062
- IPC, 3
- H04W12 04
- H04W12 06
- H04W84 18
Designated states35
- Contracting states, 35
- Austria
- Belgium
- Bulgaria
- Switzerland
- Cyprus
- Czechia
- Germany
- Denmark
- Estonia
- Spain
- Finland
- France
- United Kingdom
- Greece
- Croatia
- Hungary
- Ireland
- Iceland
- Italy
- Liechtenstein
- Lithuania
- Luxembourg
- Latvia
- Monaco
and 11 moreShow fewer
- North Macedonia
- Malta
- Netherlands (Kingdom of the)
- Norway
- Poland
- Portugal
- Romania
- Sweden
- Slovenia
- Slovakia
- Türkiye