Method and apparatus for certifying distributed services

Abstract

The present invention relates to secure communication with a system of services distributed in a network. To this end, the present invention provides a node for providing services to client nodes in a network, wherein the node is used to: execute code for providing the service to the client node in an enclave of a Trusted Execution Envoronment (TEE); execute a code library in the enclave, thereby proving the identity of the provided service to the client node. In another embodiment, the service provided to the client node is a distributed service, which includes the collaboration results of multiple neighbor nodes; the neighbor nodes are directly connected to the node or connected to the node through other intermediate nodes; the code library is used to prove the identity of the distributed service to the client node.

Description

Technical Field

[0001] The present invention relates to the field of communications, and in particular to a method and device for securely communicating with a service system distributed in a network. Background Art

[0002] A trusted execution environment, such as Intel’s software guard extension (SGX) technology, is a secure area inside the main processor that ensures that applications running in it have the following properties:

[0003] 1. Code immutability – the logic of the protected application cannot be changed.

[0004] 2. Data confidentiality – application data cannot be accessed.

[0005] 3. Attestation - The protected application is able to prove its identity to third parties with which it communicates, that the application is indeed the specific program running in the TEE.

[0006] SGX is attested via a proprietary protocol that generates a signed report based on the protected code and the enclave. The report typically contains a hash of a public key and can be verified by Intel's enhanced privacy ID (EPID) system. To communicate with a third party, the enclave can send the signed report and the public key to the third party to verify the authenticity of the report; check that the hash of the public key is equal to the hash contained in the report; and then use the public key to generate a shared secret-based channel with the enclave.

[0007] Currently, attestation protocols are suitable for single applications but not for distributed service or microservice based systems, as shown in the following network architecture of the prior art.

[0008] Figure 1 A web server (WS) is described. The web server is the front end of a site that can be accessed by clients. Also included in the figure is an application server (AS) and a database server (DB). Obviously, the functionality provided by the application relies on all three components, not just the web server itself. Therefore, any certification process performed by the web server to establish trust with the client must include all components. In other words, the web server, which is the front end to be accessed by the client, must convince the connected client that the web server can distinguish between the above deployment and other deployments, in which one of the components WS or DB has been replaced by a potentially untrustworthy component.

[0009] Figure 2Another deployment of distributed services in the prior art is described. This poses a challenge to the existing proof protocol provided by SGX technology. TS1 and TS2 in the network architecture 201 are two trusted services. When deployed, the application should be able to distinguish between the above topology and potential malicious deployments of form 202, where the client may inadvertently connect to a fake pair TS1 and TS2, emulating the services and interactions of the real service pair TS1 and TS2.

[0010] Figure 3 Yet another deployment of a distributed service in the prior art is described. This also poses a challenge to the existing proof protocols provided by SGX technology. The two deployments 301 and 302 of a distributed service are functionally equivalent, even though the two deployments have different topologies. This typically occurs during the inbound and outbound scaling of an application, requiring additional modules in response to increased load. In topology 301, the load balancer (LB) plays the role of a client-accessible front end, distributing the load across two web servers (WS), while topology 302 uses additional web servers running the same code to cope with the increased load. Therefore, the two deployments 301 and 302 can be two instances of the same application at two different times, and therefore should be considered two legitimate instances of the same pattern.

[0011] The only existing attestation mechanism is the one provided by SGX, but it is only applicable to a single application. It does not provide a solution for distributed applications, where the distributed application includes more than one enclave communicating with each other. Summary of the invention

[0012] In view of the above-mentioned problems and shortcomings, the present invention aims to improve the server solution of the traditional client based on the Transport Layer Security (TLS) protocol. In particular, the purpose of the present invention is to provide a server node. The server node executes a special code library, wherein the special code library enables the server node to prove to the client node the identity of the service provided by the server node to the client node. In particular, the service provided to the client node is a distributed service of a network composed of collaborative nodes, wherein the code library is used to prove the identity of the distributed service to the client node.

[0013] The objects of the invention are achieved by the solutions provided in the attached independent claims. Advantageous realizations of the invention are further defined in the dependent claims.

[0014] A first aspect of the present invention provides a node for providing a service to a client node in a network, wherein the node is used to: execute code for providing a service to the client node in an enclave of a trusted execution environment (TEE); execute a code library in the enclave to prove the identity of the provided service to the client node.

[0015] The code library executed in the node for providing services to the client nodes in the network enables the node to prove to the client nodes that it is indeed the node intended to provide a specific service and not any other potentially malicious intermediate node.

[0016] In a first implementation of the first aspect, the service provided to the client node is a distributed service, which includes the collaboration results of multiple neighboring nodes; the neighboring nodes are directly connected to the node or connected to the node through other intermediate nodes; the code library is used to prove the identity of the distributed service to the client node.

[0017] While the TEE ensures the integrity of data and code running in the enclave in the node, the additional code base ensures that each service or microservice can prove itself to be a legitimate service provider, where the service or microservice contributes to the service provided to the client and can run in the additional node or enclave respectively.

[0018] In another implementation of the first aspect, the code library is used to: when executed, prove the identity of the distributed service to the client node by calculating a trusted distributed identity (TDID), wherein the trusted distributed identity is an injective function of the topology of the distributed service and the code library.

[0019] The codebase may contain a special distributed protocol for evaluating the TDID of each (micro)service that contributes to the service provided to the client. The TDID is a unique identifier of a distributed service based on the topology and codebase of the distributed service. Any change in the topology or codebase, i.e. in the application deployment of the distributed service, may result in a change in the TDID, which may trigger the stopping of the service to the client for security reasons.

[0020] In another implementation of the first aspect, the code library is further used to: when executed, prove the identity of the distributed service to the client node by sending a report to the client node, wherein the report includes the TDID.

[0021] To communicate with a client node, the node's enclave may send a report containing the TDID to the client node, which will verify the authenticity of the report based on the TDID.

[0022] In another implementation of the first aspect, the node is further used to: collect the trusted local ID (TLID) of each neighbor node among the multiple neighbor nodes, wherein the TLID is provided and certified by the TEE through the corresponding secure communication channel; combine the values ​​of the TLID; and calculate the TDID of the distributed service based on the value of the combined TLID.

[0023] In another implementation of the first aspect, the TDID is calculated according to a recursive equation:

[0024] TDID=

[0025] TDID(v) = 0, if v has no neighbor nodes;

[0026] TDID(n)=hash(TLID1, TDID(n1), TLID2, TDID(n2), ..., TLIDN, TDID(RN)), where TLIDx is the TLID of each neighbor node in the plurality of neighbor nodes received on the corresponding secure communication channel.

[0027] By using the recursive formula, a unique TDID for a specific application deployment providing a distributed service to a client can be calculated. According to the formula, each of the multiple neighbor nodes belonging to the distributed service can be triggered to provide its unique TLID back to the previous node through a secure channel, and the previous node collects the TLIDs of its neighbors. This process can be repeated recursively until a triggering node is reached that constitutes a front-end node providing a service to the client.

[0028] In another implementation of the first aspect, the TEE is based on instruction codes provided by software guard extension (SGX) technology.

[0029] SGX performs attestation via a dedicated protocol by which a signed report is generated based on the protected code and the enclave. The report typically contains a hash of a public key and can be verified by an EPID system, which is an algorithm used for attestation in a trusted system while preserving privacy. To communicate with a third party or client, the enclave can send the signed report and the public key to the third party or client to verify the authenticity of the report; check that the hash of the public key is equal to the hash contained in the report; and then use the public key to generate a channel based on a shared secret with the enclave. For the purposes of the present invention, any technology that ensures the immutability and confidentiality of the data and code of the enclave and can provide a secure channel between the service provider node and the client can be used.

[0030] A second aspect of the present invention provides a system for providing services to client nodes in a network. The system includes a node described in the first aspect or any one of the implementation forms of the first aspect and a plurality of neighbor nodes connected to the node. The node and the plurality of neighbor nodes form a system based on distributed services or microservices, and each node is used to execute code in a trusted execution environment (TEE).

[0031] In a first implementation of the second aspect, each neighbor node of the plurality of neighbor nodes is configured to generate a respective TLID and a respective (local instance ID, LIID), wherein each service code instance to be executed on the additionally installed neighbor node has a unique LIID.

[0032] In order to generate a unique TDID for a distributed service, each of the multiple neighbor nodes that contribute to the provided service can be enabled to calculate a trusted local ID, which is a function of the code base that provides a unique number. Since an instance of a microservice is a copy of the service code transmitted to an additional node, the TLID of the service is the same. In order to track the allowed number of such instances, a local instance ID (i.e., a unique number) can be attributed to each instance.

[0033] In another implementation of the second aspect, each of the multiple neighbor nodes is used to: the node receives a probe request to generate a corresponding TLID; if the node is running an instance of the same service code or has no other neighbors, notify the node and return the corresponding TLID; otherwise, forward the probe request to other neighbors.

[0034] In this distribution scheme, the code base of the (front-end) node can be enabled to send a probe request to its neighbor node, and if the neighbor node also has a neighbor node, the neighbor node is also enabled to perform the same operation. The probe (request) can be spread to the network of nodes belonging to the same distributed service system, and the TLID of each qualitatively different (running different code) node can be collected. The accumulated TLID can be received at the originating (front-end) node to synthesize a TDID. The TLID of the node running the same code instance on another neighboring node must generate the same TLID, which is not considered for calculating the TDID, but is reported to the originating (front-end) node together with the fact that the node only runs an instance.

[0035] In another implementation of the second aspect, one of the plurality of neighbor nodes is configured to stop receiving requests if the node runs an instance of the same service code but returns a TLID different from a TLID of another instance of the same service code.

[0036] To prohibit malicious interference with distributed services, neighbor nodes pretending to run instances of the same service code can be disabled if it is detected that the neighbor node provides a deviated TLID.

[0037] In another implementation manner of the second aspect, the one neighbor node among the plurality of neighbor nodes is further configured to: recalculate the TLID of the node after reconstruction.

[0038] A third aspect of the present invention provides a method for providing services to client nodes in a network. The method comprises the following steps: a node executes code for providing services to client nodes in an enclave of a trusted execution environment (TEE); the node executes a code library in the enclave, thereby proving the identity of the service provided to the client node.

[0039] The fourth aspect of the present invention provides a computer program product including program code, which is used to control the device described in the first or second aspect or any implementation of the first or second aspect, or to execute the method described in the third aspect when implemented on a processor.

[0040] It should be noted that all devices, elements, units and methods described in this application can be implemented in software or hardware elements or any combination thereof. All steps performed by various entities described in this application and the functions described to be performed by various entities are intended to indicate that each entity is suitable for or used to perform each step and function. Even in the description of the following specific embodiments, the specific functions or steps to be performed by the external entity are not reflected in the description of the specific elements of the entity that performs the specific steps or functions, but the technician should be aware that these methods and functions can be implemented in respective software or hardware elements or any combination thereof. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] In conjunction with the accompanying drawings, the following description of specific embodiments will illustrate the above aspects of the present invention and their implementation methods, wherein:

[0042] Figure 1 The network architecture provided by the prior art is shown.

[0043] Figure 2 Another network architecture provided by the prior art is shown.

[0044] Figure 3 Another network architecture provided by the prior art is shown.

[0045] Figure 4 The device provided by the embodiment of the present invention is shown.

[0046] Figure 5 The method provided by the embodiment of the present invention is shown. DETAILED DESCRIPTION

[0047] Figure 4 A node 400 provided by an embodiment of the present invention is shown. The node can be used to execute code 402 to provide services to a client node 404 in an enclave 401 of a TEE; and execute an additional code library 403 in the enclave 401 to prove the identity of the provided service to the client node.

[0048] The code library 403 can also be used to prove to a third party or client node 404 that the service application that can be distributed among multiple neighbor cooperation nodes 406 to 410 and provide services to the client node 404 is actually a specific distributed program authorized to provide services to the client.

[0049] The code base 403 is also used to prove the identity of the distributed service to the client node 404 by calculating a trusted distributed identity (TDID) when executed, wherein the trusted distributed identity is an injective function of the topology and code base of the distributed service. Since malicious attempts to replace nodes or code within nodes of a service system will result in changes in the topology and / or code base, the corresponding injective function that maps the code base and / or topology to a unique number used as a TDID will also produce a deviation number, which may trigger an alarm in the client node.

[0050] In another embodiment of the present invention, the node 400 may be used to collect a trusted local ID (TLID) of each of the plurality of neighbor nodes, wherein the TLID is provided and certified by the TEE through a corresponding secure communication channel, and the secure communication channel connects the nodes 406 to 410 to the node 400 directly or through other intermediate nodes. The corresponding secure communication channel may enable each microservice or service node 400 providing services to the client 404 and the neighbor nodes 406 to 410 of the 406 to 410 subnet to use a standard SGX certification mechanism to prove its distributed identity to a higher-level node that initiates the identification process by inserting a hash of its corresponding TLID in the report.

[0051] The node 400, as the highest-level node in the service subnet of the network including the plurality of nodes 400 and 406 to 410, provides distributed services to the client nodes, and can then also be used to combine the value of the TLID and calculate the TDID of the distributed service based on the value of the combined TLID. The TDID of the distributed service can be considered as a fingerprint of the distributed service that uniquely represents the topology and code base of the distributed service.

[0052] The calculation of the TDID may be performed by the node 400 according to the following scheme of the characteristic values ​​of the various components of the service subnet, thereby allowing the accumulation of the TLID of each neighbor node in the plurality of neighbor nodes in the service subnet providing distributed services:

[0053] The local instance ID (LIID) of the neighbor node 410 can be defined by assigning a unique ID to each instance of the service code, which is not identifiable to the code. This can be achieved by generating a random number on first boot and sealing it on disk for subsequent reboots. The local instance ID can be used for loop detection and does not affect the distributed ID of the enclave or the distributed IDs of other enclaves to which the enclave may be connected.

[0054] A trusted local ID (TLID) may be a unique number representing a code base of software running on each of the plurality of nodes 406 to 410, and the TLIDs of instances of service code running on different nodes are the same. Node 410 may be an instance of code running on node 406, for example, to perform some load balancing. The TLID may be provided and proven by the TEE.

[0055] DM LIB channel: Each node of the service subnet maintains a secure channel with each trusted node from which the node obtains services. This channel can be created through the TEE attestation mechanism. Since the attestation mechanism allows the TLID of the attested neighbor node to be provided, each such channel can contain the TLID of the node connected to it. The DM lib channel is used to run distributed identity computation securely.

[0056] The code base in the node may also include a detection algorithm that can be used to calculate the TDID according to the following distributed algorithm:

[0057] Send a probe (SET) subroutine to all neighbors, where SET is the set {LIID} through a secure channel; and wait for responses. Let r1, ..., rN be the responses received from direct neighbor nodes 406, 407, and 410, then the TDID can be calculated as follows:

[0058] (1) TDID = hash(TLID1, r1, TLID2, r2, ..., TLIDN, RN), where TLIDx is the local enclave ID received on channel x during the attestation protocol.

[0059] To generate a response (as described above), the neighbor node may execute the above probe request according to the following algorithm:

[0060] When a node S in a subnet receives a probe request "Probe (SET)", it performs the following operations:

[0061] If LIID(S) is in "SET", return 0.

[0062] If S has no neighbor nodes, return 0.

[0063] Send a Probe(SET+{LIID(S)}) request to all neighbors and wait for responses.

[0064] (2) Return hash(TLID1, r1, TLID2, r2, ..., TLIDM, rM), where r1, ..., rM are neighbor responses.

[0065] Now use Figure 4The scheme developed above is explained by the elements of . Once the probe reaches the periphery of the subnet, i.e. nodes 408 and 409, these nodes both return a response of "0" because each of these nodes no longer has neighbors. Moving to the next lower level, i.e. nodes 406, 407 and 410, it will be appreciated that nodes 406 and 410 also respond to node 400 with "0", while node 407 responds to node 400 with hash(TLID1, 0, TLID2, 0) (according to function (2) above), where TLID1 is the TLID of node 408 and TLID2 is the TLID of node 409.

[0066] Using the collected information, node 400 can calculate according to the hash function, namely hash(TLID3, r3, TLID4, r4, TLID5, r5), and calculate the (final) TDID according to function (1), where

[0067] TLID3 is the TLID of the node 406, and r3 is the response of the node 406 (="0").

[0068] TLID4 is the TLID of the node 407, and r4 is the response of the node 407 (="hash(TLID1, 0, TLID2, 0)").

[0069] TLID5 is the TLID of node 410, the instance running the code of node 406, and r5 is the response of node 410 (="0").

[0070] According to the above scheme, the TLID of each node 406 to 410 of the subnet may be delivered to the node 400, and the node 400 may calculate the authorized TDID for representing the complete service topology and the service client node code.

[0071] In another implementation of node 400, its code library can also be used to send a probe request to all instances of the same type of neighbor node application. If all responses, i.e., the TLIDs of the instances, are the same, only one of them is used for hash calculation to generate the TDID. In this way, the previous assumption of the limitation of a fixed number of neighbor nodes in the entire life cycle of the distributed service application is overcome, and the embodiment of the present invention supports scalable deployment. If one of the responses of the instance is different, node 400 will enter a "failure" state and will stop receiving requests from client 404. Node 400 must recalculate the TDID every time a trusted channel is reestablished. If the TDID changes, the node may decide to stop providing the service and return an error. The embodiment of the present invention provides Figure 3 Solutions to the discussed prior art problems.

[0072] Figure 5According to an embodiment of the present invention, a method 500 is shown. The method comprises the following steps: (501) the node executes code for providing services to the client node in an enclave of a trusted execution environment; (502) the node executes a code library in the enclave, thereby proving the identity of the provided service to the client node. The method 500 can be executed by the node 400 provided by the embodiment of the present invention.

[0073] The invention has been described in conjunction with different embodiments and implementations as examples. However, other variants can be understood and obtained by a person skilled in the art by practicing the claimed invention, studying the drawings, the disclosure and the independent claims. In the claims and the specification, the term "comprising" does not exclude other elements or steps, and "a" does not exclude the plural. A single element or other unit may fulfil the functions of several entities or items described in the claims. The fact that certain measures are set forth in mutually different dependent claims does not mean that a combination of these measures cannot be used in an advantageous implementation.

Claims

1. A node (400) for providing services to a client node (404) in a network, characterized in that The node is used to: Executing code (402) for providing the service to the client node (404) in an enclave (401) of a trusted execution environment (TEE); executing a code base (403) in the enclave (401) to prove the identity of the provided service to the client node; The service provided to the client node is a distributed service, which includes the result of cooperation of multiple neighboring nodes (406 to 410); the neighboring nodes are directly connected to the node (400) or connected to the node (400) through other intermediate nodes; the code library (403) is used to prove the identity of the distributed service to the client node; The code base (403) is used to: when executed, prove the identity of the distributed service to the client node by calculating a trusted distributed identity TDID, wherein the trusted distributed identity is an injective function of the topology of the distributed service and the code base.

2. The node according to claim 1, characterized in that The code library (403) is also used to: when executed, prove the identity of the distributed service to the client node (404) by sending a report to the client node, wherein the report includes the TDID.

3. The node according to claim 1 or 2, characterized in that: The node is also used to: Collecting a trusted local ID (TLID) of each neighbor node of the plurality of neighbor nodes, wherein the TLID is provided and certified by the TEE through a corresponding secure communication channel; and combining values ​​of the TLID; The TDID of the distributed service is calculated based on the value of the combined TLID.

4. The node according to claim 3, characterized in that The TDID is calculated according to the recursive equation: TDID= TDID(v) = 0, if v has no neighbor nodes; TDID(n)=hash(TLID1, TDID(n1), TLID2, TDID(n2), ..., TLIDN, TDID(RN)), where TLIDx is the TLID of each neighbor node in the plurality of neighbor nodes received on the corresponding secure communication channel.

5. The node according to any one of claims 1 to 4, characterized in that: The TEE is based on instruction codes provided by software guard extension (SGX) technology.

6. A system for providing services to client nodes in a network, characterized in that include: A node (400) according to any one of claims 1 to 5; a plurality of neighbor nodes (406 to 410) connected to the node, The node and the plurality of neighboring nodes form a system based on distributed services or microservices, and each node is used to execute code in a trusted execution environment (TEE).

7. The system according to claim 6, characterized in that Each neighbor node of the plurality of neighbor nodes is configured to generate a respective TLID and a respective local instance ID (LIID), wherein each service code instance to be executed on the additionally installed neighbor node has a unique LIID.

8. The system according to claim 7, characterized in that Each neighbor node among the plurality of neighbor nodes is used for: The node (400) receives the probe request to generate a corresponding TLID; If the node is running an instance of the same service code or has no other neighbors, the node is notified and the corresponding TLID is returned; Otherwise, the probe request is forwarded to other neighbors.

9. The system according to claim 8, characterized in that A neighbor node among the plurality of neighbor nodes is configured to stop receiving requests if the neighbor node runs an instance of the same service code but returns a TLID that is different from a TLID of another instance of the same service code.

10. The system according to claim 9, characterized in that The one neighbor node among the plurality of neighbor nodes is further configured to: recalculate the TLID of the node after the reconstruction.

11. A method for providing services to client nodes in a network, characterized in that include: The node executes code to provide services to client nodes in the enclave of the trusted execution environment; The node executes a code base in the enclave, thereby proving the identity of the service provided to the client node; The service provided to the client node is a distributed service, which includes the collaboration results of multiple neighboring nodes; the neighboring nodes are directly connected to the node or connected to the node through other intermediate nodes; the code library is used to prove the identity of the distributed service to the client node; The node executes the code base and proves the identity of the distributed service to the client node by calculating a trusted distributed identity TDID, wherein the trusted distributed identity is an injective function of the topology and code base of the distributed service.

12. A computer program product comprising program code, characterized in that For controlling a node according to any one of claims 1 to 5, or for controlling a node in a system according to any one of claims 6 to 10, or for performing a method according to claim 11 when implemented on a processor.

Images