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

Abstract

The invention relates to a device for verifying the reliability of communication nodes in an overlay network composed of a plurality of groups of communication nodes, each group operated by a different operator, and a secret group key associated with each operator. The nodes are configured to send and receive data packets to and from nodes in the plurality of groups. The method consists of performing implicit remote software attestation, which is combined with the data exchanges between the nodes of the overlay network, by allowing an authentication code to be included in each exchanged data packet. Each node that receives a data packet simultaneously receives proof of the legitimate software status of the sending node. If the legitimacy of the sending node cannot be proven, the packet is ignored. Figure 3

Description

Title of the invention: 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 in order to provide a set of services to users of this network. The network nodes may 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. This is the case when, for example, a TOR overlay network that provides an anonymization service is the target of effective cyberattacks, the anonymity of the users is then compromised.

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

[0006] One such countermeasure is remote software attestation mechanisms, which overlay network nodes may be subjected to.

[0007] Remote software attestation of a node makes it possible to remotely ensure 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 called into question, to the extent that 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, as a hardware characteristic for activating remote software attestation, we can cite the existence of a TPM module (acronym for “Trusted Platform Module” in English) on the hardware platform associated with the node.

[0011] Different hardware characteristics 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" in English) 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 carry out remote software certification is presented in various documents in the literature.

[0015] Remote software attestation requires the intervention of a certain number of services operated by independent actors and supported by servers. Several of these services can be supported in a single server. We thus find verification and evaluation services during a software attestation operation.

[0016] A verification service is supported by a server machine which 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 (acronym for “Operating System” in English) which 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 upon 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 on the status of the target node: either it is approved or it is 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 approved and unapproved 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 the 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 reliable nodes by again calling one or more verification services, so as to update the status of the nodes used, and to terminate the use of nodes which have lost their reliable node status.

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

[0022] And whatever the rate at which 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 remedy 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, so that each node which receives a data packet receives at the same time the proof of the “legitimate” software state of the node sending the data packet.

[0029] In the event that 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 also the non-software compromise of the node at the time it produced this datagram.

[0031] In one embodiment, a report may be generated by the receiving node before ignoring a compromised received packet, thus providing statistics in the node regarding reliable and other nodes.

[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 an 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 superimposed 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 the remote software attestation solutions of the prior art 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 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 enclave ma. hardware 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 according to 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 the 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 a remote software attestation of 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 transmitting node, consisting of: calculating an authentication code, based on the data of a packet to be transmitted 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 transmitted, said authentication code.The method comprises at a data receiving node, steps consisting in 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 sending 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] Different 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] [Fig.l] schematically presents an architecture of an overlay network making it possible to implement the method of the present invention in one embodiment.

[0052] [Fig.2] schematically presents an alternative embodiment of the architecture of superimposed network of [Fig.l].

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

[0054] [Fig.4] illustrates a sequence of steps carried out by a node of a network superimposed to transmit a data packet, according to an embodiment of the method of the invention.

[0055] [Fig.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] [Fig.6] illustrates a sequence of operations performed for the distribution of group keys to the nodes of an overlay network.

[0057] [Fig.7] is a temporal representation of a communication between a node transmitter and a receiver node based on the calculation of a cumulative digest to verify the reliability of the transmitter 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] [Fig.l] 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. [Fig.l] illustrates three operators by way of non-limiting example: Operator A, Operator B, Operator C. A plurality of nodes operated by operator A are named Node Al (or Al), 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 Cl (or Cl), Node C2 (or C2), ..., Node Ck (or Ck).

[0061] Each operator is in charge of an entity called “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 [Fig.l], 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. enabling 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 [Fig.l], the group secret keys GKA, GKB, GKC of the operators A, B, C, are for example distributed to the nodes A1, A2, B1, B2, C1 and C2 which are configured (illustrated by a “TPM” rectangle) 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 certain cases. These data communications are made by data packets, for example by 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 groups of nodes of the overlay network.

[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 receiving mode must have all the group keys in order to perform the reliability verification of a transmitting node.

[0070] [Fig.l] 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 “TPM” rectangle).

[0071] Thus, the components of an overlay network participating in the reliability verification method of the invention each have a secure hardware enclave TPM. The GKX group keys (represented inside a TPM) are only known and generated 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] Still advantageously, a group secret key GKX is not known either to other group key managers of an overlay network, nor to administrators of the group key managers.

[0074] [Fig.2] schematically presents an alternative embodiment of the overlay network architecture of [Fig.l].

[0075] This variant allows a group key manager to perform an attestation of a node prior to providing a group secret key GKX to this node.

[0076] This variant aims to remedy the problem on the architecture of [Fig.l], where nothing forces a group key manager to carry out an attestation of a node before providing it with a secret key. To counter this flaw, it is proposed to implement verification services to regularly carry out a remote attestation of the software of the group key managers.

[0077] The verification services can in turn call on evaluation services, which can also call on source publication services (“OSS Repository” in [Fig.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] [Fig. 3] schematically presents 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 of the network and / or terminals using readers.

[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 transmitted, a comparison module 318 for performing a comparison of authentication codes, 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) can 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] [Fig.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 in the network. The data packet may come 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 transmitted 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:

[0092] MAC = Digest(packet, GKX), where GKX is the currently valid group key for operator X and the term "packet" corresponds to the binary content of the packet of data.

[0093] 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 in a following step 406, the method makes it possible to transmit into the network, via the transmitter module 306, the packet which contains the authentication code.

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

[0095] 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 makes it possible to ensure 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 transmitting node, at the time of creation of the packet.

[0096] 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.

[0097] [Fig.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.

[0098] 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.

[0099] 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.

[0100] 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.

[0101] 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 correspond or not.

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

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

[0104] In one embodiment, a status report may be generated by the receiving node before ignoring a compromised received packet, thereby providing statistics in the node regarding reliable nodes and compromised nodes.

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

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

[0107] 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.

[0108] When a node is activated at initialization, its secure hardware enclave or TPM must obtain a copy of all valid group keys from all operators.

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

[0110] It is possible that one or all of the group key managers may not have prior knowledge of the node for which a request is addressed to them.

[0111] 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.

[0112] 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.

[0113] Upon receipt of the certificate (AIK Cert + Id), the group key manager verifies that the key is signed by the manufacturer of the hardware enclave (for example, the manufacturer of a TPM module). This verification can be done via a public key infrastructure or (PKI) for "Public Key Infrastructure" in English.

[0114] Then the manager sends a remote software attestation request to the node, as well than a nonce (nonce2), by signing this composite message with its private key (for example “Apriv” for the group key manager A).

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

[0116] 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).

[0117] 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.

[0118] 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.

[0119] To assess the legitimate or potentially compromised state of the host platform, the group key manager may 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.

[0120] 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 the group key manager A.

[0121] 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.

[0122] 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.

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

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

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

[0126] 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 cannot be used (for example for the calculation of a MAC) only 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 time 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.

[0127] In the key distribution mechanism, an entity, called a "Source Publication 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 evaluate the state of a platform. The sources are signed by the entity and the key manager must verify the signature (possibly using a PKI).

[0128] Calculating an authentication code results in a request to the secure module for each packet sent and received. This can lead to a bottleneck phenomenon at the secure module level, in particular if the node is required to process large data flows in terms of throughput.

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

[0130] 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.

[0131] [Fig.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.

[0132] The example is illustrated over a validity period of a GKX key, for a transmitter node having a GKX secret key and a receiver peer node also having the GKX secret key.

[0133] 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). The information (TCP flow) is divided into segments (packets). It is assumed that the injection of segments into a TCP flow is done according to a protocol making it possible to delimit and identify these segments.

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

[0135] A CTRL1 type packet is intended to delimit sub-periods at the level of the transmitting node (it forms the boundary between two periods), and a CTRL2 packet is intended to include an authentication code (MAC) concerning the period which has just elapsed.

[0136] The authentication code is calculated in a similar way to the method described for [Fig.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:

[0137] MAC = Digest(cumulative_digest_over_last_elapsed_period, GKX), where GKX is the currently valid group key for an operator X.

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

[0139] At the start 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:

[0140] digest_cumulatifn = Digest(digest_cumulatifn_i, contenu_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.

[0141] Those skilled in the art know 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.

[0142] 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.

[0143] [Fig.7] does not show the CTRL2 packet because the transmitting node has a time tolerance, noted “tcrl2max”, to transmit it at the start of the CTRL1 period.

[0144] 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. [Fig.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 start 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".

[0145] The transmitting 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 in inserting in each sub-period a packet of type CTRL1, intended to define the period of calculation of the authentication code.

[0146] When the receiving node receives a CTRL2 type 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.

[0147] 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.

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

[0149] 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 in order to compare it with the one received in the CTRL2 packet, without stopping processing the received data stream.

[0150] The variant described here does not completely resolve the risk of sudden compromise of a node (following for example the execution of a malicious executable file on the node), which will lead a very rapid attack to compromise the service provided by the overlay network. For this it is important that the CTRL1 period is low, 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, notes the possible divergence of authentication code, and ceases all interaction with the suspect node.

[0151] It is possible for the receiving node to defer to the application level the processing of the received stream for a CTRL1 period, until all the 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 proposed 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: - calculation means (314) 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 the secret group key of said operator, the calculation of the authentication code being carried out in a secure hardware enclave (310) of said node, said secure hardware enclave storing (312) a copy of each secret group key associated with said operators;- insertion means (316) configured to insert into a data packet to be transmitted an authentication code calculated in the hardware enclave of the transmitting node; - comparison means (318) 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 (320) configured to validate or reject a data packet received by a receiving node, depending on the result of the comparison of the authentication codes.;

2. The device according to claim 1 wherein the computing means (314) 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.

3. The device of claim 1 or 2 further comprising means configured to receive a copy of each secret group key from said operators.

4. The device according to claim 3 wherein the means for receive 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.

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 of claim 5 wherein the secure hardware enclave further comprises means configured to implement a sealing mechanism on PCR platform configuration registers.

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

8. 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.

9. An overlay network-based telecommunications system according to the preceding claim, further comprising verification means configured to perform remote software attestation of the secret group key managers.

10. A method of 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 operates on a processor, and comprising: - at a data transmitting node, steps consisting of: calculating an authentication code, based on the data of a packet to be transmitted 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 transmitted, said authentication code; - 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 validation means configured to validate or reject a received data packet, depending on the result of the comparison of the authentication codes.;

11. The method of claim 10 further comprising steps of distributing the secret group keys of the operators to each node of the overlay network, the step of distributing each key being performed by a key manager of each operator, and comprising at least one step of remote software attestation between the key manager and a node.

12. Method according to claim 10 or 11 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.

13. A computer program product, said computer program comprising code instructions for carrying out the steps of the method according to any one of claims 10 to 12, when said program is executed on a computer.

Images