Method and device for checking the reliability of data communication nodes in an overlay network

Abstract

The invention relates to a device for checking the reliability of communication nodes in an overlay network composed of a plurality of groups of communication nodes, each group being operated by a different operator, and a secret group key being associated with each operator. The nodes are configured to transmit and receive data packets to and from the nodes of the plurality of groups. The method consists in performing an implicit remote software assertion, which is combined with the data exchanges between the nodes of the overlay network, allowing an authentication code to be included in each exchanged data packet. Each node that receives a data packet at the same time receives the proof of the legitimate software state of the transmitting node. In the event that the legitimacy of the transmitting node cannot be proven, the packet is ignored.

Description

DESCRIPTION TITLE: Method and device for verifying the reliability of data communication nodes of an overlay network Field of invention

[0001] The present invention relates to the field of security and reliability of digital communications networks, and more particularly the security and reliability of overlay networks. State of the art

[0002] A digital communications network typically consists of communications nodes operated by various operators to provide a set of services to network users. Network nodes can be, for example, IP routers.

[0003] Overlay networks are subsets of digital networks that group together a subset of nodes dedicated to higher-level services. Examples of such overlay networks include SMTP (Simple Mail Transfer Protocol) server networks that provide email-type message sending services, or the TOR (Tor Onion Routing) network, which provides its users with an anonymization service.

[0004] The security of overlay networks is a sensitive issue, as cyberattacks on these networks compromise the services they provide to their users, or even compromise the users themselves. For example, when a TOR overlay network that provides an anonymization service is the target of effective cyberattacks, the anonymity of users is compromised.

[0005] “Sensitive” overlay networks often incorporate countermeasures to thwart or even avoid, as far as possible, any flaws that could allow effective cyberattacks.

[0006] One such countermeasure is remote software attestation mechanisms, which can be used by nodes in the overlay network.

[0007] Remote software attestation of a node allows remote assurance that a network node is not compromised, and that its software and hardware status is known and legitimate.

[0008] Remote software attestation is only possible if the target node has hardware characteristics that make it possible.

[0009] This assertion can sometimes be questioned, as there are approaches that attempt to circumvent this rule, however the effectiveness of such approaches is limited, and they are not considered here.

[0010] For example, a hardware feature to enable remote software attestation is the existence of a TPM (Trusted Platform Module) on the hardware platform associated with the node.

[0011] Different hardware features also make remote software attestation possible. Another example is the SGX solution (acronym for "Software Guard Extensions") offered by Intel® and integrated into Intel® microprocessors.

[0012] TPM modules have been standardized by the TCG (acronym for "Trusted Computing Group") and are, at first glance, comparable to a smart card attached to the platform (unlike, for example, a SIM card).

[0013] A TPM module holds / stores cryptographic secrets that are not known to anyone (if we omit the TPM module manufacturer who is not supposed to archive this secret), not even known to the node administrator.

[0014] The use of a TPM module to perform remote software attestation is presented in various literature documents.

[0015] Remote software attestation involves the intervention of a number of services operated by independent parties and supported by servers. Several of these services can be supported by a single server. This means that verification and evaluation services are included in a software attestation operation.

[0016] A verification service is supported by a server machine that must remotely ensure the non-compromise of target nodes. A verifier obtains from a target machine its "software state" as observed by the TPM module on the target node, attested by the manufacturer of this TPM module. This state is characteristic of a software history on this node which takes the form of a certain number of cryptographic "digests". Without being exhaustive, we can cite among others, a digest calculated on the image of the operating system (OS) that was loaded, and another digest calculated on a set of other digests associated with all the executables launched on the machine, at the time of the software verification request.

[0017] From a set of verification digests, the verification service can call an evaluation service to determine which digests are approved and which are unknown or even explicitly disapproved. Based on this feedback, the verification service can decide whether the target node is approved or potentially compromised. It is understood that the information returned by the evaluation service must be "signed" by the entity in charge of administering the service.

[0018] The verification service may be required to perform regular checks on the status of all nodes in an overlay network, and to make available to clients of the overlay network services a list of trusted and untrusted nodes. This list must obviously be signed by the entity in charge of the evaluation service, it being understood that several verification services administered by separate entities may coexist, so that clients of the different verification services can choose the one they trust, or even choose several of these services to combine the results.

[0019] Customers of services provided by the overlay network may ultimately be required, prior to any use of the overlay network, to obtain an assessment of the status of all nodes in the network, and to decide to limit their use of the network to only those nodes that are approved and considered reliable.

[0020] Furthermore, during the use of an overlay network, clients can renew the list of trusted nodes by re-calling one or verification services, in order to update the status of the nodes used, and to terminate the use of nodes which have lost their status as reliable nodes.

[0021] However, this system has a limitation since at any time a node that was evaluated as reliable may no longer be so.

[0022] And no matter how often the nodes used are re-evaluated, there remains the risk of using one or more unreliable nodes for a certain period of time, however short.

[0023] Also, there is a need for an appropriate solution to overcome such a risk.

[0024] The present invention meets this need. Summary of the invention

[0025] An aim of the present invention is to overcome the aforementioned drawbacks of known approaches, by proposing a method and an associated device, which removes the risk of using a corrupted node in an overlay network.

[0026] Advantageously, the present invention provides a solution to this problem by enabling immediate responsiveness upon detection that a node becomes corrupted, by directly interrupting data exchanges with this corrupted node.

[0027] The general principle of the invention for verifying the reliability of the nodes of an overlay network consists of carrying out an implicit remote software attestation which is combined with the data exchanges between the nodes of the overlay network.

[0028] The present invention makes it possible to include an authentication code in each datagram or data packet exchanged, such that each node which receives a data packet receives at the same time proof of the "legitimate" software state of the node sending the data packet.

[0029] In case the legitimacy of the sending node cannot be proven in a data packet that is received by a receiving node, then the packet is discarded.

[0030] Advantageously, the present invention makes it possible to ensure both the integrity of the datagram and the non-software compromise of the node at the time it produced this datagram.

[0031] In one implementation option, a report can be generated by the receiving node before discarding a compromised received packet, thus providing statistics within the node regarding which nodes are trusted and which are not.

[0032] If the user of an overlay network has an endpoint machine that is capable of evaluating an authentication code, then it can be configured to ignore any received packet that is suspicious.

[0033] In one embodiment where the transmitted packets are intended to propagate from hop to hop in the overlay network, and if one of the intermediate nodes is not legitimate, then the next legitimate node in the route terminates the propagation of the packets.

[0034] The invention will find advantageous applications in many technical fields where overlay networks are used.

[0035] Thus, anonymization overlay networks constitute an interesting application of the present invention. Indeed, in the context of an anonymization network, the "non-reactive" nature of prior art remote software attestation solutions poses the problem that the compromise of a node can be exploited within a few seconds of the compromise, and therefore contribute to breaking the anonymity of a user served by the compromised node. The present invention makes it possible to avoid this risk.

[0036] To obtain the desired results, a device is proposed for verifying the reliability of communication nodes of an overlay network, the overlay network comprising a plurality of groups of communication nodes, each group of nodes being operated by a different operator, a secret group key being associated with each operator, the communication nodes being configured to transmit and receive data packets, to and from nodes of the plurality of groups. The device comprises: - calculation means configured so that a node of a group operated by an operator, calculates an authentication code on the basis of the data of a packet to be transmitted and of the secret group key of said operator, the calculation of the authentication code being carried out in a secure hardware enclave of said node, storing a copy of each secret group key associated with said operators; - insertion means configured to insert into a data packet to be transmitted an authentication code calculated in the hardware enclave of the transmitting node; - comparison means configured to compare an authentication code contained in a received data packet, with an authentication code calculated on the basis of the data of the received packet and the secret group key of the operator of said transmitting node, said calculation of the authentication code being carried out in the secure hardware enclave of the receiving node; and - validation means configured to validate or reject a data packet received by a receiving node, depending on the result of the comparison of the authentication codes.

[0037] The device can be implemented in different embodiments.

[0038] In one embodiment, the computing means are configured to compute an authentication code with a cryptographic hash function based on the binary content of a data packet and the secret group key of the operator of a transmitting node.

[0039] In one embodiment, the device further comprises means configured to receive a copy of each secret group key from said operators.

[0040] In one embodiment, the means for receiving a copy of a secret group key are configured to communicate with a group key manager of each operator, each of said group key managers being configured to perform a remote software attestation of a node, upon receipt of a secret group key request by said node.

[0041] In one embodiment, the secure hardware enclave is a hardware module whose characteristics are standardized according to the specifications of secure TPM platforms defined by the “Trusted Computing Group” consortium.

[0042] In one embodiment, the secure hardware enclave further comprises means configured to implement a sealing mechanism on PCR platform configuration registers.

[0043] In one embodiment, the device further comprises means for calculating a cumulative digest over several data transmission periods and means for sending an authentication code calculated from the cumulative digest.

[0044] The invention also relates to a telecommunications system based on an overlay network, the overlay network comprising a plurality of groups of communication nodes, each group of nodes being operated by a different operator, a secret group key being associated with each operator, the communication nodes being configured to transmit and receive data packets, to and from nodes of the plurality of groups, the telecommunications system being characterized in that all or some of the nodes of the overlay network comprise a device according to the invention.

[0045] In one embodiment, the overlay network-based telecommunications system further comprises verification means configured to perform remote software attestation of the secret group key managers.

[0046] The invention further addresses a method for verifying the reliability of communication nodes of an overlay network, the overlay network comprising a plurality of groups of communication nodes, each group of nodes being operated by a different operator, a secret group key being associated with each operator, the communication nodes being configured to transmit and receive data packets, to and from nodes of the plurality of groups.The method is implemented on a processor, and comprises steps at a data sending node, consisting of: calculating an authentication code, based on the data of a packet to be sent and the secret group key of the operator of said node, the calculation of the authentication code being carried out in a secure hardware enclave of said node, said secure hardware enclave storing a copy of each secret group key of said operators; and inserting into the data packet to be sent, said authentication code. The method comprises at a data receiving node, steps. consisting of comparing an authentication code contained in a received data packet, with an authentication code calculated on the basis of the data of the received packet and the secret group key of the operator of the transmitting node, the calculation of the authentication code being carried out in a secure hardware enclave of said receiving node; and comprises validation means configured to validate or reject a received data packet, depending on the result of the comparison of the authentication codes.

[0047] In one embodiment, the method further comprises steps of distributing the secret group keys of the operators to each node of the overlay network, the step of distributing each key being operated by a key manager of each operator, and comprising at least one step of remote software attestation between the key manager and a node.

[0048] In one embodiment, the step of inserting an authentication code into a data packet to be transmitted is replaced by steps consisting of calculating a cumulative digest over several data transmission periods, and inserting an authentication code calculated from the cumulative digest.

[0049] Another subject of the present invention is a computer program product, said computer program comprising code instructions for carrying out the steps of the method of the invention, when said program is executed on a computer. Description of figures

[0050] Various aspects and advantages of the invention will appear in support of the description of a preferred but non-limiting mode of implementation of the invention, with reference to the figures below:

[0051] Figure 1 schematically presents an architecture of an overlay network for implementing the method of the present invention in one embodiment.

[0052] Figure 2 schematically presents an alternative embodiment of the overlay network architecture of Figure 1.

[0053] Figure 3 schematically shows the structure of a node of an overlay network in one embodiment.

[0054] Figure 4 illustrates a sequence of steps performed by a node of an overlay network to transmit a data packet, according to an embodiment of the method of the invention.

[0055] Figure 5 illustrates a sequence of steps performed by a node of an overlay network upon receipt of a data packet, according to an embodiment of the method of the invention.

[0056] Figure 6 illustrates a sequence of operations performed for the distribution of group keys to nodes in an overlay network.

[0057] Figure 7 is a temporal representation of a communication between a sending node and a receiving node based on the calculation of a cumulative digest to verify the reliability of the sending node. Detailed description of the invention

[0058] In the context of the description of an embodiment, a secure hardware enclave within the meaning of the invention is considered to be a code execution enclave, secured at the silicon level. Although different types of secure enclave may be adapted to implement the invention, for reasons of simplification of the description, a secure hardware enclave of the "TPM" type is considered, i.e. having standardized characteristics according to the specifications of the TPM secure platforms defined by the "Trusted Computing Group" consortium. This type of secure enclave represents the most general approach (because it is not limited to Intel® microprocessors alone, for example, like the SGX enclave).

[0059] Figure 1 schematically presents an architecture of an overlay network 100 making it possible to implement the method of the present invention in one embodiment.

[0060] The nodes of an overlay network are operated by various operators that contribute to the overlay network. Figure 1 illustrates three operators as a non-limiting example: Operator A, Operator B, Operator C. A plurality of nodes operated by operator A are named Node A1 (or A1 ), Node A2 (or A2), ..., Node Ai (or Ai). A plurality of nodes operated by operator B are named Node B1 (or B1 ), Node B2 (or B2), ..., Node Bj (or Bj). A plurality of nodes operated by operator C are named Node C1 (or C1), Node C2 (or C2), Node Ck (or Ck).

[0061] Each operator is in charge of an entity called a "Group Key Manager", which is configured to manage (in terms of generation and distribution) a secret key for the group of nodes for which the operator is in charge.

[0062] Thus in Figure 1, a group key manager A is illustrated, configured to manage a secret key for the group of nodes Ai operated by operator A, i.e. allowing a secret key (GKA) to be generated and distributed "GKA distribution".

[0063] Similarly, a group key manager B is configured to manage a secret key GKB for the group of nodes Bj operated by operator B, and a group key manager C is configured to manage a secret key GKC for the group of nodes Ck operated by operator C.

[0064] According to the principle of the invention, a secret key GKX generated by a key manager for a group of nodes operated by an operator X, is distributed to the plurality of nodes of an overlay network which are configured to participate in the reliability verification method of the invention.

[0065] Thus, as illustrated in Figure 1, the group secret keys GKA, GKB, GKC of operators A, B, C, are for example distributed to nodes A1, A2, B1, B2, C1 and C2 which are configured (illustrated by a rectangle “TPM”) to implement the reliability verification method of the invention.

[0066] Thus, the nodes participating in the reliability verification process each have all the secret keys of the groups operated by the different operators.

[0067] To provide its service, an overlay network implements data communications between certain pairs of nodes in the network, or even between all pairs of nodes in some cases. These data communications are done through data packets, for example, through packets (UDP) acronym for "User Datagram Protocol" in English.

[0068] The communication nodes of the overlay network are configured to transmit "Env" and receive "Rec" data packets, to and from nodes of the plurality of node groups of the overlay network. he

[0069] In terms of packet transmission, only the group key of the transmitting node's operator is required. In terms of packet reception, since a node can receive packets from any operator in the overlay network, a node in receive mode must have all the group keys in order to perform the reliability verification of a transmitting node.

[0070] Figure 1 also shows user terminals (U1, U2, U3) allowing end users to send service requests to operators of the overlay network and receive data. In one embodiment, all or part of the user terminals are configured to implement the reliability verification process of the invention (illustrated by a rectangle "TPM").

[0071] Thus, the components of an overlay network participating in the reliability verification method of the invention each have a secure TPM hardware enclave. The GKX group keys (represented inside a TPM) are known and generated only in the TPMs.

[0072] Advantageously, a GKX group secret key is not known to the host platforms (“Node Application”) in the nodes, nor to those of the user terminals (“User Application”), i.e. the host platform of a TPM never has access to a GKX key.

[0073] Also advantageously, a GKX group secret key is not known to other group key managers in an overlay network, nor to administrators of group key managers.

[0074] Figure 2 schematically presents an alternative embodiment of the overlay network architecture of Figure 1.

[0075] This variant allows a group key manager to perform attestation of a node as a prerequisite to providing a group secret key GKX to that node.

[0076] This variant aims to address the problem in the architecture of Figure 1, where nothing forces a group key manager to perform attestation of a node before providing it with a secret key. To counter this flaw, it is proposed to implement verification services to regularly perform remote attestation of the group key manager software.

[0077] Verification services can in turn call on evaluation services, which can also call on source publication services ("OSS Repository" in Figure 2).

[0078] Thus, taking the example of three group key managers, three verification services (X, Y, Z) are implemented, each of which can carry out remote verifications of the non-compromise of each group key manager of operators A, B, C. Each verification service can call upon an evaluation service (R, S, T) to obtain the status of a group key manager.

[0079] Figure 3 schematically shows the structure of a node of an overlay network in one embodiment. A node 302 of an overlay network according to the invention comprises a receiver module 304, a transmitter module 306, an application module 308, a secure hardware enclave 310, an insertion module 316, a comparison module 318 and a validation module 320.

[0080] The receiver module 304 is configured to interface the node with the network and receive data packets from other nodes in the network and / or user terminals.

[0081] The transmitter module 306 is configured to interface the node with the network and transmit data packets to other nodes of the network and / or to user terminals.

[0082] The application module 308 is configured to implement the service(s) offered by the overlay network.

[0083] Advantageously, the node has a secure hardware enclave 310 which comprises different modules configured to enable the implementation of the invention. Thus, the node comprises at the secure hardware enclave, a storage module 312 for storing group secret keys and a calculation module 314 for calculating authentication codes.

[0084] The node further comprises an insertion module 316 for inserting an authentication code into a data packet to be sent, a comparison module 318 for performing a code comparison authentication, and a validation module 320 for validating or rejecting a received data packet.

[0085] In one embodiment, the insertion module 316 may be supported by the transmitter module 306.

[0086] In one embodiment, the comparison module (318) as well as the validation module (320) may be supported by the receiver module (304).

[0087] The authentication code calculation is thus carried out in the secure enclave of the node, upon request from the node.

[0088] Figure 4 illustrates a sequence of steps carried out at the secure hardware enclave of a node of an overlay network, to transmit a data packet, according to an embodiment of the method of the invention.

[0089] The method 400 is initiated when a node of an overlay network belonging to a group of nodes operated by an operator X must transmit a data packet into the network. The data packet may be derived from a data packet received and processed according to the specific application of the node.

[0090] In a first step 402, the method makes it possible to calculate, by the calculation module 314, an authentication code, from the data of the packet to be sent and the group secret key GKX of the operator X stored in the key storage module 312.

[0091] In one embodiment, the authentication code is calculated as for a so-called message authentication code (MAC) according to the English acronym for “Message Authentication Code”, with a hash function (or “Digest”) according to the following formula: MAC = Digest(packet, GKX), where GKX is the currently valid group key for operator X and the term "packet" is the binary content of the data packet.

[0092] In a following step 404, the method makes it possible to insert, by the insertion module 316, the calculated authentication code into the outgoing packet, then into a following step 406, the method makes it possible to transmit in the network, via the transmitter module 306, the packet which contains the authentication code.

[0093] In one embodiment, the authentication code is inserted into an available field of the data packet header.

[0094] Thus advantageously, the authentication code calculated according to the invention has the properties of a MAC used in other contexts, that is to say that it ensures the integrity of the data of the packet in which it is inserted. Furthermore, the insertion of the calculated authentication code in the secure hardware enclave of a node makes it possible to add a guarantee of legitimacy of the sending node, at the time of creation of the packet.

[0095] A receiver of the data packet will be able to perform a similar authentication code calculation on the received data packet, to verify the legitimacy of the sending node.

[0096] Figure 5 illustrates a sequence of steps carried out in the hardware enclave of a node of an overlay network upon receipt of a data packet, according to an embodiment of the method of the invention.

[0097] The method 500 is initiated when a node of an overlay network belonging for example to a group of nodes operated by an operator X, receives in a first step 502, a data packet in the network. The data packet can come from a node of the overlay network belonging to the same group of nodes as the receiving node and operated by the same operator X or come from a node of the overlay network belonging to a group of nodes operated by another operator Z.

[0098] In a following step 504, the method makes it possible to calculate, by the calculation module 314, an authentication code, from the data of the received packet and the group secret key of the operator of the transmitting node, stored in the storage module 312 of the receiving node, for example the key GKX if the data packet comes from a node operated by the operator X or the key GKZ if the data packet comes from a node operated by the operator Z.

[0099] Advantageously, the key storage module 312 makes it possible to store all the group secret keys distributed by the key managers of the different operators.

[0100] In a following step 506, the method makes it possible to compare the authentication code calculated by the receiving node with the authentication code inserted in the received packet, then in a following step 508, the method makes it possible to validate or reject the received packet depending on whether the authentication codes match or not.

[0101] If the packet is validated, it means that the sending node is not compromised, and the receiving node can continue processing the received packet.

[0102] If the authentication codes do not match, it means the sending node is compromised, and the received packet is discarded.

[0103] In one implementation option, a status report can be generated by the receiving node before discarding a compromised received packet, thus providing statistics in the node regarding trusted and compromised nodes.

[0104] Group secret keys are distributed to nodes in an overlay network by group key managers, upon node initialization and upon renewal of expired keys.

[0105] Figure 6 illustrates a sequence of operations performed for the distribution of group keys to nodes in an overlay network, during node implementation.

[0106] The example presents for reasons of simplification, a distribution sequence of three keys GKA, GKB, GKC to a node, for three operators A, B and C. However, the implementation of the invention can be carried out for any superimposed network without limitation of the number of operators, and associated key managers.

[0107] When a node is powered up at boot, its secure hardware enclave or TPM must obtain a copy of all valid group keys from all operators.

[0108] The node, i.e. the corresponding machine, sends to each key manager a group key request, “Request GKA” for group key manager A, “Request GKB” for group key manager B, “Request GKC” for group key manager C. The request contains the node identifier (id) and a nonce (noncel) which is a random value.

[0109] It is possible that one or all of the group key managers may not have prior knowledge of the node for which they are being requested.

[0110] If the node is not yet known to the group key manager, the latter asks the node to provide it (Request AIK Cert) with a key identity certificate or (AIK) for "Attestation Identity Key" in English.

[0111] Such a certificate was created in the node's hardware enclave for authentication purposes. It contains a public key signed by the hardware enclave manufacturer, and an associated private key (AIKpriv), internal to the hardware enclave and non-exportable.

[0112] Upon receipt of the certificate (AIK Cert + Id), the group key manager verifies that the key is signed by the hardware enclave manufacturer (e.g., the manufacturer of a TPM module). This verification can be done via a public key infrastructure (PKI).

[0113] Then the manager sends the node a remote software attestation request, along with a nonce (nonce2), signing this composite message with its private key (e.g. "Apriv" for group key manager A).

[0114] When the node receives this message, it first verifies the signature. It can trust a PKI to do this.

[0115] Then, it requests its secure module to obtain a certified measurement of the state of the host platform (Measurements). This measurement is typically made up, in the case of a TPM module, of a list of values ​​of "PCR" registers contained in the TPM. The value of nonce2 is added to this list, and the TPM signs the message with its private key (AIKpriv).

[0116] Upon receipt of this message, the group key manager verifies the signature of the received message, taking into account the AIK certificate associated with this node.

[0117] It then checks for the presence of the nonce (nonce2) and verifies that its value is identical to the one it sent, then it collects the list of values ​​associated with the PCR registers.

[0118] To assess the legitimate or potentially compromised state of the host platform, the group key manager can use assessment services. This involves verifying that the firmware is not compromised, that the OS image is not compromised, and that none of the executable files running on the platform are compromised.

[0119] If the result of this remote attestation is positive, then the group key manager can send its valid secret key to the node, for example the GKA key for group key manager A.

[0120] It encrypts this GKA key with the public key associated with the node's AIK certificate, so that only the recipient's secure hardware enclave (and no others) can retrieve the decrypted key.

[0121] In one embodiment, the group key manager provides a validity period for the secret key. The node must note this validity period and obtain a new key before this validity period expires.

[0122] The message containing the group secret key is finally signed by the group key manager with his private key.

[0123] For example, the message sent by group key manager A is of type: [GKA encr / AIKpub + valid_period+nonce1] signed / Apriv.

[0124] Upon receiving this message, the node verifies the signature (signed / Apriv), verifies the nonce (noncel), and provides its secure module with the encrypted GKA key to store it decrypted in the key storage module.

[0125] In an embodiment where the secure enclave is a TPM module, the secret key, for example GKA, must benefit from a sealing mechanism at the TPM level. This mechanism allows the TPM to refuse its host any use of this GKA key outside of a prior verification of the value of the PCR registers of the TPM. The key can only be used (for example for calculating a MAC) if the TPM registers are equal to a fixed configuration. In this case, the sealing mechanism is initiated according to the value of the PCR registers at the moment of receipt of the GKA key. If, for example, the GKA key is received and the sealing mechanism is initiated for this key, and subsequently, a new executable is launched on the host platform, then this event will result in the modification of a PCR register (under Linux, a kernel in which the "Integrity Management architecture" module is enabled is required to guarantee this behavior). Since a register is modified, the host can no longer call the TPM to use the GKA key.

[0126] In the key distribution mechanism, an entity, called the Source Publishing Service, provides reference sources that can be compiled at the key manager and converted into digests. This allows key managers to determine which digests are authorized to assess the state of a platform. The sources are signed by the entity, and the key manager must verify the signature (possibly using a PKI).

[0127] Calculating an authentication code requires the secure module to be used for each packet sent and received. This can lead to a bottleneck phenomenon in the secure module, particularly if the node is required to process high data flows in terms of throughput.

[0128] Additionally, the performance of TPM modules is generally quite limited when it comes to quickly executing cryptographic algorithms.

[0129] Also, to circumvent this risk, an alternative embodiment of the present invention makes it possible not to insert an authentication code in each data packet sent, and to generate a cumulative digest over several periods before calculating an authentication code to be inserted in a data packet to be sent.

[0130] Figure 7 is a temporal representation of a communication between a sending node and a receiving node based on the calculation of a cumulative digest to verify the reliability of the sending node.

[0131] The example is illustrated over a validity period of a GKX key, for a sending node having a GKX secret key and a receiving peer node also having the GKX secret key.

[0132] In the example of this variant embodiment, information is sent from the sending node to the receiving node by the TCP protocol ("Transmission Control Protocol » in English). The information (TCP stream) is divided into segments (packets). It is assumed that the injection of segments into a TCP stream is done according to a protocol allowing these segments to be delimited and identified.

[0133] The principle of this variant is to inject two types of short packets into the flow: a first type of packet called "CTRL1" and a second type of packet called "CTRL2".

[0134] A CTRL1 packet is intended to delimit sub-periods at the sending node (it forms the boundary between two periods), and a CTRL2 packet is intended to include a MAC authentication code (MAC) concerning the period that has just elapsed.

[0135] The authentication code is calculated in a similar way to the method described for Figure 4, except that it is not the binary content of a packet to be sent that is used for the calculation, but a cumulative digest, according to the following formula: MAC = Digest(cumulative_digest_over_last_elapsed_period, GKX), where GKX is the currently valid group key for an operator X.

[0136] Generating a cumulative digest involves dividing the TCP stream into segments of constant byte size (except for the last segment) and reduced. The cumulative digest is calculated "on the fly" on the stream, without using the secure module.

[0137] At the beginning of the period the cumulative digest is initialized to 0, then for each new segment sent, the cumulative digest is updated according to the following formula: digest_cumulatif n = Digest(cumulative_digest n.i, content_segment_n), where the cumulative digest for the last elapsed period 'n' is that obtained with the content of the last segment of this period.

[0138] The person skilled in the art is familiar with the cumulative digest technique, which has the advantage of not having to store a large volume of data to calculate a digest over all the segments for a period.

[0139] Once the cumulative digest over the last period is calculated, it is possible to calculate an authentication code and transmit it to the receiving node, in a CTRL2 type packet.

[0140] Figure 7 does not show the CTRL2 packet because the sending node has a time tolerance, noted "tcrl2max", to transmit it at the beginning of the CTRL1 period.

[0141] As a transmitter, the node is synchronized with its GKX key manager, which renews this key before any new period, which defines the "GKX period" of validity before a renewal. Figure 7 shows a GKX key renewal operation at the end of the period, for both the transmitter and the receiver. This operation can be started in advance of the new validity period, without exceeding a delay noted "Trenew". At the beginning of a new GKX period, the receiver node can still be authorized to use the old GKX group key, but without exceeding a maximum delay noted "Rxtol".

[0142] The sending node subdivides the GKX validity period into sub-periods of equal duration, each including a period reserved for the calculation of an authentication code. The period also called here "CTRL1 period" is reserved by inserting in each sub-period a packet of type CTRL1 , intended to define the authentication code calculation period.

[0143] When the receiving node receives a CTRL2 packet, at the beginning of the CTRL1 period, it recalculates an authentication code value based on the group key of its own secure module. If there is a discrepancy in the code value, the receiving node terminates the connection with the sending node, which then becomes suspected of compromise.

[0144] It should be noted that the mechanisms described do not entail any risk of a node being put on hold due to the request of the secure module and the response time to this request.

[0145] Advantageously, at the start of the CTRL1 period, a transmitting node can continue to process transmitted segments in parallel with the operation of the secure module which is requested to calculate an authentication code.

[0146] Similarly, when a receiving node receives a CTRL2 packet that contains an authentication code, it can request its secure module to calculate an authentication code to compare it with the one received in the CTRL2 packet, without stopping processing the received data stream.

[0147] The variant described here does not completely address the risk of sudden compromise of a node (for example, following the execution of a malicious executable file on the node), which will lead to a very rapid attack to compromise the service provided by the overlay network. For this, it is important that the CTRL1 period is small, so as to limit this risk as much as possible. Indeed, it is necessary to wait for the current CTRL1 period to elapse so that the receiving node receives a CTRL2, notices the possible divergence of the authentication code, and ceases all interaction with the suspect node.

[0148] It is possible for the receiving node to defer the processing of the received stream to the application level for a CTRL1 period, until all data is "validated" by the reception of an associated CTRL2. However, this may cause excessive latency at the application level and this mode of operation cannot be offered systematically. For example, if the CTRL1 period is 1 second, this mode of operation causes a latency of at least 1 second.

Claims

CLAIMS 1. Device for verifying the reliability of communication nodes of an overlay network, the overlay network comprising a plurality of groups of communication nodes, each group of nodes being operated by a different operator, a secret group key being associated with each operator, the communication nodes being configured to transmit and receive data packets, to and from nodes of the plurality of groups, the device comprising: - communication means configured for a group node operated by an operator to issue a secret group key request to a group key manager for each operator, and to receive a copy of a valid secret group key, after validation of the legitimate software state of said node by the group key manager of said operator; - a secure hardware enclave (310) comprising: - storage means (312) for storing a copy of each valid secret group key; - calculation means (314) configured to calculate an authentication code on the basis of data of a packet to be transmitted and the copy of a valid secret group key of the operator of the transmitting node; - insertion means (316) configured to insert into a data packet to be transmitted an authentication code calculated in the secure hardware enclave; - comparison means (318) configured to compare an authentication code contained in a received data packet, with an authentication code calculated in the secure hardware enclave on the basis of the data of the received packet and a stored copy of the secret group key of the operator of said transmitting node; and - validation means (320) configured to validate or reject a received data packet, depending on the result of the comparison of the authentication codes.

2. The device according to claim 1 wherein the calculation means (314) are configured to calculate an authentication code with a cryptographic hash function based on the binary content of a data packet and the copy of the secret group key of the operator of a transmitting node.

3. The device according to claim 1 or 2 wherein the validation of the legitimate software state of a node consists of a group key manager sending the node a remote software attestation request, and of said node requesting the secure hardware enclave to obtain an attested measurement of the state of the host platform.

4. The device according to any one of claims 1 to 3 wherein the group key manager sends a validity period for the copy of the valid secret key.

5. The device according to any one of claims 1 to 4 wherein the secure hardware enclave is a hardware module whose characteristics are standardized according to the specifications of the secure TPM platforms defined by the “Trusted Computing Group” consortium.

6. The device according to claim 5 wherein the secure hardware enclave further comprises means configured to implement a sealing mechanism on PCR platform configuration registers, said mechanism being initiated according to the value of the PCR registers at the time of receipt of a secret group key.

7. The device of any preceding claim wherein the secure hardware enclave comprises means for storing a decrypted copy of a secret group key.

8. The device according to any one of the preceding claims further comprising means for calculating a cumulative digest over several data transmission periods and means for sending an authentication code calculated from the cumulative digest.

9. The device according to the preceding claim in which a data stream transmitted over several periods is made up of a set of segments, and in which a cumulative digest is initialized to a constant value at the start of the period and such that for any new segment transmitted, the current cumulative digest is generated at from the cumulative digest associated with the previous segment and the contents of the data stream of the current segment.

10. A telecommunications system based on an overlay network, the overlay network comprising a plurality of groups of communication nodes, each group of nodes being operated by a different operator, a secret group key being associated with each operator, the communication nodes being configured to transmit and receive data packets, to and from nodes of the plurality of groups, the telecommunications system being characterized in that all or some of the nodes of the overlay network comprise a device according to any one of the preceding claims.

11. Telecommunication system based on an overlay network according to the preceding claim, further comprising verification means configured to carry out a remote software attestation of the secret group key managers.

12. A method for verifying the reliability of communication nodes of an overlay network, the overlay network comprising a plurality of groups of communication nodes, each group of nodes being operated by a different operator, a secret group key being associated with each operator, the communication nodes being configured to transmit and receive data packets, to and from nodes of the plurality of groups, the method being implemented on a processor, and comprising: - at a data transmitting node, steps consisting of: - issue a secret group key request to a group key manager for each operator, and receive a copy of a valid secret group key, after validation of the legitimate software state of said issuing node by the group key manager of said operator; - calculating in a secure hardware enclave of said transmitting node an authentication code based on data of a packet to be transmitted and the secret group key of the operator of said transmitting node, said secure hardware enclave storing a copy of each secret group key associated with each operator; and - insert into a data packet to be transmitted, said authentication code; - at a data receiving node, steps consisting of: - calculating in a secure hardware enclave of said receiving node an authentication code based on the data of a received packet and the secret group key of the operator of the node sending the data packet, said secure hardware enclave storing a copy of each secret group key associated with each operator of the overlay network; - comparing the calculated authentication code with an authentication code contained in the received data packet; and - validate or reject the received data packet, depending on the result of the comparison of the authentication codes.

13. Method according to claim 12 in which the step of inserting an authentication code into a data packet to be transmitted is replaced by steps consisting of calculating a cumulative digest over several periods of data transmission, and inserting an authentication code calculated from the cumulative digest, where a cumulative digest is initialized to a constant value at the start of the period, a data stream transmitted over several periods is made up of a set of segments, and such that for any new segment transmitted, the current cumulative digest is generated from the cumulative digest associated with the previous segment and the content of the data stream of the current segment.

14. A computer program product, said computer program comprising code instructions for carrying out the steps of the method according to claim 11 or 12, when said program is executed on a computer.

Images