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 in an overlay network. Field of the invention

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

[0002] A digital communications network typically consists of communication nodes operated by various operators to provide a set of services to users of that network. The 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, which provide email-type message sending services, and 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, for example, when a TOR overlay network, which provides an anonymization service, is the target of successful cyberattacks; the anonymity of users is then compromised.

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

[0006] One of these countermeasures consists of remote software attestation mechanisms, to which the nodes of the overlay network can be subjected.

[0007] Remote software attestation of a node makes it possible to ensure remotely 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, insofar 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] One can cite, for example, as a hardware characteristic for enabling remote software attestation, 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, in a first approximation, 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 (except for the manufacturer of the TPM module 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 certification is presented in various literature documents.

[0015] Remote software attestation involves the intervention of several services operated by independent actors and supported by servers. Several of these services can be hosted on the same server. Verification and evaluation services are thus included in a software attestation operation.

[0016] A verification service is provided by a server machine that remotely verifies that target nodes have not been compromised. A verifier obtains from a target machine its "software state" as observed by the TPM module on the target node, certified by the manufacturer of this TPM module. This state is characteristic of a software history on that node, which takes the form of a number of cryptographic "digests." While not exhaustive, examples include 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 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 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 the 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, before any use of the overlay network, to obtain an assessment of the status of all the nodes of 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 again using one or more verification services, so as to update the status of the nodes used, and to terminate the use of nodes that have lost their trusted node status.

[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 regardless of 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] Therefore, 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] One object of the present invention is to remedy the aforementioned drawbacks of known approaches, by proposing a method and an associated device, which eliminates the risk of using a corrupted node in an overlay network.

[0026] Advantageously, the present invention offers a solution to this problem by allowing immediate reactivity 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 that receives a data packet simultaneously receives proof of the "legitimate" software state of the node sending the data packet.

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

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

[0031] In one embodiment option, a report can be generated by the receiving node before ignoring a received compromised packet, thus allowing the node to have statistics on which nodes are reliable and which are not.

[0032] If the user of an overlay network has a terminal machine that is capable of evaluating an authentication code, it can then 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, layered anonymization 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 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 for verifying the reliability of communication nodes in an overlay network is proposed, 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 send and receive data packets, to and from nodes in the plurality of groups.The device includes: - computing means configured so that a node of a group operated by an operator calculates an authentication code based on the data of a packet to be sent 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 emit an authentication code calculated in the hardware enclave of the sending 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 in the received packet and the secret group key of the operator of said sending node, said calculation of the authentication code being performed 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, according to 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 calculate 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 an issuing node.

[0039] In one embodiment, the device further includes means configured to receive a copy of each secret group key of 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 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 TPM secure platforms defined by the "Trusted Computing Group" consortium.

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

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

[0044] The invention also relates to a telecommunication system based on an overlay network, the overlay network comprising a plurality of communication node groups, 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 send and receive data packets, to and from nodes of the plurality of groups, the telecommunication system being characterized in that all or part of the nodes of the overlay network comprises a device according to the invention.

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

[0046] The invention further addresses a method for verifying the reliability of communication nodes in 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 send and receive data packets, to and from nodes in the plurality of groups.The process is implemented on a processor, and includes steps at the level of 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 said authentication code into the data packet to be sent.The method includes, at a data-receiving node, steps for comparing an authentication code contained in a received data packet with an authentication code calculated based on the data in the received packet and the secret group key of the operator of the sending node, the calculation of the authentication code being performed in a secure hardware enclave of said receiving node; and includes validation means configured to validate or reject a received data packet, depending on the result of the authentication code comparison.

[0047] In one embodiment, the method further includes steps consisting of distributing the operators' secret group keys to each node of the overlay network, the distribution step of each key being operated by a key manager of each operator, and comprising at least one remote software attestation step 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 object of the present invention is a computer program product, said computer program comprising code instructions enabling the steps of the process of the invention to be carried out when said program is executed on a computer. Description of the figures

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

[0051] Fig. 1 schematically presents an architecture of a superimposed network enabling the implementation of the process of the present invention in one embodiment.

[0052] Fig.2 schematically presents a variant embodiment of the superimposed network architecture of Fig.1.

[0053] Figure 3 schematically presents the structure of a node of a superimposed network in one embodiment.

[0054] Figure 4 illustrates a sequence of steps carried out by a node of an overlay network to send a data packet, according to one embodiment of the process of the invention.

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

[0056] Figure 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 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 describing an embodiment, a secure hardware enclave as defined in the invention is considered to be a code execution enclave secured at the silicon level. Although different types of secure enclaves could be adapted to implement the invention, for the sake of simplicity in the description, a secure hardware enclave of the "TPM" type is considered, i.e., having standardized characteristics according to the specifications of TPM secure platforms defined by the Trusted Computing Group consortium. This type of secure enclave represents the most general approach (as it is not limited to Intel® microprocessors, for example, like the SGX enclave).

[0059] Fig. 1 schematically presents an architecture of a superimposed network 100 allowing the process of the present invention to be implemented in one embodiment.

[0060] The nodes of an overlay network are operated by various operators who contribute to the overlay network. Figure 1 illustrates three operators by way of non-limiting example: Operator A, Operator B, Operator C. A plurality of nodes operated by the operator Nodes A are named Node A1 (or A1), Node A2 (or A2), ..., Node A1 (or A1). 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 "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.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 the generation of a secret key (GKA) and its distribution "GKA distribution".

[0063] Similarly, a group key manager B is configured to manage a secret key GKB for the node group Bj operated by operator B, and a group key manager C is configured to manage a secret key GKC for the node group 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 that are configured to participate in the reliability verification process of the invention.

[0065] Thus, as illustrated in [Fig.1], the group secret keys GKA, GKB, GKC of operators A, B, C, are for example distributed to nodes Al, A2, Bl, B2, Cl 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 network nodes, or even between all pairs of nodes in some cases. These data communications are done by data packets, for example by packets (UDP), an acronym for "User Datagram Protocol".

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

[0069] In terms of packet transmission, only the group key of the operator of the sending node 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 check of a sending 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 "TPM" rectangle).

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

[0074] Figure 2 schematically presents a variant embodiment of the architecture of superimposed network of the [Fig.l].

[0075] This variant allows a group key manager to attest to a node prior to providing a GKX group secret key to that node.

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

[0077] Verification services may in turn call upon evaluation services, which may also call upon source publication services (“OSS Repository” on [Fig.2]).

[0078] Thus, taking up the example of three group key managers, three verification services (X, Y, Z) are implemented, each capable of performing remote checks 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 presents the structure of a node in a superimposed 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 network nodes and / or user terminals.

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

[0082] 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 includes various modules configured to enable the implementation of the invention. Thus, the node includes, at the level of 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 includes an insertion module 316 for inserting an authentication code into a data packet to be sent, 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 can be supported by the transmitter module 306.

[0086] In one embodiment, the comparison module (318) as well as the validation module (320) can be taken over 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 level of the secure hardware enclave of a node of an overlay network, to send a data packet, according to an embodiment of the method of the invention.

[0089] The 400 process is initiated when a node in an overlay network belonging to a group of nodes operated by an operator X needs to send a data packet into the network. The data packet may originate from a data packet received and processed according to the node's specific application.

[0090] In a first step 402, the process allows the calculation, by the calculation module 314, of 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:

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

[0093] In a subsequent step 404, the method allows the calculated authentication code to be inserted, by means of the insertion module 316, into the outgoing packet, and then in a subsequent step 406, the method allows the packet containing the authentication code to be sent into the network, via the transmitter module 306.

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

[0095] Thus, advantageously, the authentication code calculated according to the invention exhibits the properties of a MAC used in other contexts, that is to say, it ensures the integrity of the data in the packet into which it is inserted. Furthermore, inserting the calculated authentication code into the secure hardware enclave of a node adds a guarantee of the legitimacy of the sending node at the time the packet is created.

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

[0098] The process 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 may originate 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 it may originate from a node of the overlay network belonging to a group of nodes operated by another operator Z.

[0099] In a subsequent step 504, the method allows 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 sending 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 operator X or the key GKZ if the data packet comes from a node operated by operator Z.

[0100] Advantageously, the 312 key storage module allows all group secret keys distributed by the key managers of the different operators to be stored.

[0101] In a subsequent step 506, the method allows the authentication code calculated by the receiving node to be compared with the authentication code inserted in the received packet, and then in a subsequent step 508, the method allows the received packet to be validated or rejected depending on whether the authentication codes match or not.

[0102] If the packet is validated, this 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, this means that the sending node is compromised, and the received packet is ignored.

[0104] In one embodiment option, a status report can be generated by the receiving node before ignoring a received compromised packet, thus allowing the node to have statistics on reliable and compromised nodes.

[0105] Group secret keys are distributed to the nodes of an overlay network by group key managers, at node initialization and when keys that have expired are renewed.

[0106] Figure 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 overlay 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 group key manager A, "Request GKB" for group key manager B, "Request GKC" for 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 requests the node to provide (Request AIK Cert) a key identity certificate or (AIK) for "Attestation Identity Key" in English.

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

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

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

[0115] When the node receives this message, it first checks the signature. It can rely on a PKI to do this.

[0116] Next, it queries its secure module to obtain an attested measurement of the host platform's state (Measurements). This measurement typically consists, in the case of a TPM module, of a list of "PCR" register values ​​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 registries.

[0119] 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 T 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 group key manager A.

[0121] It encrypts this GKA key with the public key associated with the node's AIK certificate, such that only the recipient's secure hardware enclave (and no other) can recover 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 the expiry of this validity period.

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

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

[0125] Upon receiving 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 in decrypted form 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 deny its host any use of this GKA key without first verifying the value of the TPM's PCR registers. 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 time the GKA key is received. 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).Because a registry is modified, the host can no longer call upon the TPM to use the GKA key.

[0127] In the key distribution mechanism, an entity, referred to as the "Source Publication Service," provides reference sources that can be compiled at the key manager level and converted into digests. This allows key managers to determine which digests are authorized for evaluating 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 requires the secure module to be used with each packet sent and received. This can lead to a bottleneck in the secure module, particularly if the node has to process high data throughput.

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

[0130] Also, to circumvent this risk, a variant 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] The [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 sending node having a GKX secret key and a receiving peer node also having the GKX secret key.

[0133] In the example of this variant of the embodiment, information is sent from the sending node to the receiving node via the TCP protocol (Transmission Control Protocol). 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 that allows these segments to be delimited and identified.

[0134] The principle of this variant is to inject two types of short packets into the stream: 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 sending node level (it makes the boundary between two periods), and a CTRL2 type packet is intended to include an authentication code (MAC) concerning the period that has just passed.

[0136] The authentication code is calculated in a similar manner to the process 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(digest_cumulative_over_last_period_elapsed, GKX), where GKX is the current valid group key for an operator X.

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

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

[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 that period.

[0141] A person skilled in the art is familiar with the cumulative digest technique, which has the advantage of not having to memorize a large volume of data to calculate a digest on all 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 sending node has a time tolerance, noted "tcrl2max", to transmit it at the beginning of the CTRL1 period.

[0144] As the sender, the node is synchronized with its GKX key manager, which renews the key before each new period, thus defining the "GKX period" of validity before renewal. Figure 7 shows a GKX key renewal operation at the end of the period, for both the sender and the receiver. This operation can be started in advance of the new validity period, without exceeding a delay denoted "Trenew". At the beginning of a new During the GKX period, the receiving node may still be allowed to use the old GKX group key, but without exceeding a maximum time limit noted as "Rxtol".

[0145] The sending node subdivides the GKX validity period into sub-periods of equal duration, each including a period reserved for calculating an authentication code. This period, also referred to here as the "CTRL1 period," is reserved by inserting a CTRL1 type packet into each sub-period, which defines the period for calculating the authentication code.

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

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

[0148] Advantageously, at the beginning of period CTRL1, a sending node can continue to process emitted segments in parallel with the operation of the secure module which is being asked to calculate an authentication code.

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

[0150] The variant described here does not completely eliminate the risk of sudden compromise of a node (for example, following the execution of a malicious executable file on the node), which would lead to a very rapid attack to compromise the service provided by the overlay network. Therefore, it is important that the CTRL1 period be short, so as to minimize this risk. Indeed, it is necessary to wait for the current CTRL1 period to elapse before the receiving node receives a CTRL2, detects any potential discrepancy in authentication codes, and ceases all interaction with the suspect node.

[0151] 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 the data is "validated" by the receipt of an associated CTRL2. However, this can lead to excessive latency at the application level, and this mode of operation cannot be systematically implemented. For example, if the CTRL1 period is 1 second, this mode of operation results in a latency of at least 1 second.

Claims

Demands

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 send and receive data packets, to and from nodes of the plurality of groups, the device comprising: - means of communication configured so that a group node operated by an operator sends a secret group key request to a group key manager for each operator, and receives an encrypted copy of a valid secret group key, after validation of the legitimate software state of said node by the group key manager of said each operator;- a secure hardware enclave (310) comprising: - storage means (312) for storing a decrypted copy of each valid secret group key; - computing means (314) configured to calculate an authentication code based on the data of a packet to be transmitted and the stored decrypted 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 based on the data of the received packet and a stored decrypted 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 authentication codes.;

2. The device according to claim 1 wherein the computing means (314) are configured to compute an authentication code with a content-based cryptographic hash function binary of a data packet and copy of the operator's secret group key of a sending node.

3. The device according to claim 1 or 2 wherein the validation of the legitimate software state of a node consists for a group key manager to send the node a remote software attestation request, and for said node to solicit the secure hardware enclave to obtain an attested measure 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 currently 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 TPM secure 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 according to any one of the preceding claims further comprising means for calculating a cumulative digest over several data emission periods and means for sending an authentication code calculated from the cumulative digest.

8. The device according to the preceding claim wherein a data stream emitted over several periods consists of a set of segments, and wherein a cumulative digest is initialized to a constant value at the beginning of the period and such that for any new segment emitted, 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.

9. A telecommunications system based on an overlay network, the overlay network comprising a plurality of communication node groups, each node group 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 originating from nodes of the plurality of groups, the telecommunication system being characterized in that all or part of the nodes of the superimposed network comprise a device according to any one of the preceding claims.

10. Telecommunications system based on an overlay network according to the preceding claim, further comprising verification means configured to perform remote software attestation of secret group key managers.

11. A method for verifying the reliability of communication nodes in 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 send and receive data packets to and from nodes in the plurality of groups, the method being implemented on a processor, and comprising: - at the level of a data-sending node, steps consisting of: - sending a secret group key request to a group key manager for each operator, and receiving an encrypted copy of a valid secret group key, after validation of the legitimate software state of said sending node by the group key manager of said each operator;- to store in a secure hardware enclave of the sending node a decrypted copy of each valid secret group key; - to calculate in the secure hardware enclave of said sending node an authentication code based on the database of a packet to be sent and the stored decrypted copy of a valid secret group key of the operator of said sending node; and - to insert into a data packet to be sent the said authentication code calculated in the secure hardware enclave; - at the level of a data receiving node, steps consisting of: - calculating in a secure hardware enclave of said receiving node an authentication code based on the database of a received packet and the stored decrypted copy of the secret group key of the operator of the data packet sending node; - comparing the calculated authentication code with an authentication code contained in a received data packet; and; - validate or reject the received data packet, depending on the result of the authentication code comparison.

12. A method according to claim 11, wherein 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, where a cumulative digest is initialized to a constant value at the beginning of the period, a data stream transmitted over several periods consists of a set of segments, and such that for each 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

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

Images