WO2020078534A1

WO2020078534A1 - Node and method for secure server communication

Info

Publication number: WO2020078534A1
Application number: PCT/EP2018/078148
Authority: WO
Inventors: Dan Touitou; Naor SHLOMO; Avigail Oron
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2018-10-16
Filing date: 2018-10-16
Publication date: 2020-04-23
Also published as: CN113261252A; EP3857838A1; CN113261252B

Abstract

The present invention provides a node (100) which is suitable for allowing a client node to access a trusted service provided by another node in a network and comprises two units. The first unit (101) is configured to sign a certificate to certify the ownership of a public key, wherein the public key is owned by an enclave of a trusted execution environment, TEE, in the another node and a code to be executed for providing the trusted service to the client node is protected in the enclave. The second unit (102) is configured to make the signed certificate available to the client node. The certificate may be a certificate, which an enclave running in the another node provides to the node´s first unit (101) to demonstrate that it is an authentic part of a web domain (e.g. example.com) which a client node wants to securely access without risking to expose sensitive data to a man-in-the-middle purporting to be the trusted service.

Description

NODE AND METHOD FOR SECURE SERVER COMMUNICATION

TECHNICAL FIELD The present invention relates to the communications field, and to a node and a method for securely communicating with a server in a network.

BACKGROUND

A Trusted Execution Environment, TEE, such as InteEs Software Guard Extensions, SGX, technology or AMD’s Secure Memory Encryption, SME, is a secure area inside a main processor that ensures that an application running in it has the following properties:

1. Code immutability - logic of the protected application cannot be altered

2. Data confidentiality - application data cannot be accessed

3. Attestation - the protected application has the ability to prove to a third party it is communicating with its identity, i.e. that it is indeed a specific program running in the TEE.

SGX performs attestation by using a dedicated protocol through which the protected code, the enclave, generates a signed report. This report usually contains a hash of a public key and can be verified e.g. by InteEs Enhanced Privacy ID (EPID) system. In order to communicate with a third party the enclave may send the signed report and the public key to the third party, which will verify the report authenticity, checks that the hash of the public key is equivalent to the hash included in the report and then uses that public key to generate a shared secret based channel with the enclave.

Currently the standard way for clients to securely communicate with a server based on HTTPS-technology is via the cryptographic protocol named Transport Layer Security (TLS). During a TLS session establishment the server provides the client with an x.509 certificate. The certificate contains a public key and a subject name and its authenticity is proved by a Certificate Authority signature. Upon reception and verification of the certificate the client and the server generate a shared secret that will be used for the continuation of the session.

As we can see, the TEE attestation is not standard and cannot be utilized directly by an HTTPS-client. According to SGX-specifications, the way to fill this gap is to provide the enclave with a private key of a signed certificate, in other words the expectation is that the administrator securely connects with the enclave and after attestation protocol provides the enclave with a signed certificate and the certificate’s private key.

However, this approach is not viable for applications aiming to provide full trust to the customers, because a user wanting to provide his sensitive data to the application cannot differentiate between the enclave and some man-in-the-middle-layer that got the private key from the administrator.

If it is intended to use the TEE technology instead of the above described TLS scheme, the user faces a problem. TEE attestation is performed by using a dedicated protocol through which the protected code, the enclave, generates a signed report. This report usually contains a hash of a public key and can be verified by Intel EPID system. However, this protocol is not supported by standard clients which expect to get an x.509 certificate.

Two ideas attempting to solve this problem have been published:

1) Extension for X.509 certificate (Knaught and alt.) - According to this solution in prior art an enclave adds to the certificate an extension containing a proof that the public key was generated by the enclave. This proof (an EPID signed report) is concatenated with the certificate as an x.509 extension. The main drawback of this approach is that it requires not only to changes the client's TLS stack to support this extension, but also to update it whenever a change in the attestation protocol is made.

2) Add-on for client’s browser (Krawiecka and Alt.) - According to this solution in prior art functionality of the browser is extended enabling it to verify the quote from the enclave and build a trusted channel with it. As well as in solution 1) changes are required on the client side and those changes are required, whenever the enclave attestation protocol is updated. SUMMARY

In view of the above-mentioned problems and disadvantages, the present invention aims to allow a client to access a trusted service in a network without adding functionality to either the client TLS stack or the browser. In particular, the present invention has the object to provide a new type of network node acting as a new certificate authority, whose signature attests that a public key provided to it belongs to a specific enclave. A further object is to provide the new certificate authority as a new layer of attestation to existing network nodes operating as a certificate authorities. Thus, the aim is to provide a trust certificate authority (TCA), which enforces a protocol through which the TCA attests to a client the authenticity of a specific enclave that belongs to a specific domain name.

The object of the present invention is achieved by the solution provided in the enclosed independent claims. Advantageous implementations of the present invention are further defined in the dependent claims.

A first aspect of the present invention provides a node for allowing a client node to access a trusted service provided by another node in a network, configured to sign a certificate to certify the ownership of a public key, wherein the public key is owned by an enclave of a trusted execution environment, TEE, in the another node and a code to be executed for providing the trusted service to the client node is protected in the enclave; and make the signed certificate available to the client node. This node executes the necessary measures instead of a client node to prove that a public key belongs to a specific enclave and not a potentially malicious man-in-the-middle.

In an implementation form of the first aspect, the format of the certificate comprises an additional protocol layer on top of the attestation protocol according to the X.509 standard.

Due to adding an additional protocol layer on top of the attestation protocol according to the X.509 standard instead of extending the X.509 standard, a client node does not need to be modified, because the client node receives a certificate according to the X.509 standard.

A second aspect of the present invention provides a system for allowing a client to access a trusted service provided by another node in a network, comprising a node according to the first aspect; another node, whereby the another node comprises a trusted execution environment, TEE, wherein a code to be executed for providing the trusted service to the client node and data is protected in the enclave; an administrator node of the another node; and an attestation authority node.

In an implementation form of the second aspect, the administrator node is configured to connect to the enclave, verify the authenticity of the enclave, and provide the enclave with a private key of the certificate of the another node; the enclave is configured to generate a random public key and create a signed report containing a hash of the public key, connect to the node and demonstrate to the node that the enclave belongs to the another node by using the private key of the another node, and provide the node with the signed report; and the node is further configured to verify the authenticity of the signed report by using an enhanced privacy ID, EPID, algorithm in an attestation authority node; and sign the certificate with a named subject, wherein the named subject comprises the enclave’s hash value.

This implementation form of a system for allowing a client to access a trusted service provided by another node in a network employs four nodes or entities, namely the node, another node, an administrator node and an attestation authority node, to ensure that an unmodified client node based on the HTTPS -standard may access a trusted service provided by another node in a safe manner, since the authenticity of the trusted service is assured by the interaction of the four node resulting in a certificate signed by the node and provided to a client node.

A third aspect of the present invention provides a method for allowing a client to access a trusted service provided by another node in a network, comprising the steps of signing, by a node, a certificate to certify the ownership of a public key, whereby the public key is owned by an enclave of a trusted execution environment, TEE, in the another node and a code to be executed for providing the trusted service to the client node and data is protected in the enclave; and making the signed certificate available to the client node.

In an implementation form of the third aspect, the method further comprises the steps of connecting, by an administrator of the another node, to the enclave; verifying, by the administrator, the authenticity of the enclave; providing, by the administrator, the enclave with a private key of the certificate of the another node; generating, by the enclave, a random public key and creating a signed report containing a hash of the public key;

connecting, by the enclave, to the node and demonstrating to the node that the enclave belongs to the another node by using the private key of the another node; providing, by the enclave, the node with the signed report; verifying, by the node, the authenticity of the signed report by using an enhanced privacy ID, EPID, algorithm in an attestation authority node; and wherein the step of signing, by the node, the certificate to certify the ownership of a public key comprises signing the certificate with a named subject, wherein the named subject comprises the enclave’s hash value.

In an implementation form of the third aspect, the creating of a signed report containing a hash of the private key is carried out via a quoting enclave.

A forth aspect of the present invention provides a computer program product comprising program code for controlling a node according to the first or second aspect, or for performing, when implemented on a processor, a method according to the third aspect.

It has to be noted that all devices, elements, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof.

BRIEF DESCRIPTION OF DRAWINGS

The above described aspects and implementation forms of the present invention will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which

Fig. 1 shows a node according to an embodiment of the present invention.

Fig. 2 shows a system according to an embodiment of the present invention.

Fig. 3 shows a method according to an embodiment of the present invention. Fig. 4 shows another method according to an embodiment of the present invention.

DETAILED DESCRIPTION OF EMBODIMENTS

Fig. 1 shows a node 100 according to an embodiment of the present invention. The node 100 is suitable for allowing a client node to access a trusted service provided by another node in a network and comprises two units. The first unit 101 is configured to sign a certificate to certify the ownership of a public key, wherein the public key is owned by an enclave of a trusted execution environment, TEE, in the another node and a code to be executed for providing the trusted service to the client node is protected in the enclave. The second unit 102 is configured to make the signed certificate available to the client node. The certificate may be a certificate, which an enclave running in the another node provides to the node's first unit 101 to demonstrate that it is an authentic part of a web domain (e.g. example.com) which a client node wants to securely access without risking to expose sensitive data to a man-in-the-middle purporting to be the trusted service.

However, since a certificate, possibly containing a private key from an administrator of the trusted service, could have been stolen by an imposter of a trusted service, a client node needs proof that the issuer of the certificate is indeed the specific enclave which the client node wants to access. To this end, the first unit 101 of the node 100 acting as a new trusted certificate authority is configured to provide a signature to the certificate proving to the client node that a public key, which the client intends to use to generate a shared secret based channel with the enclave of another node providing a trusted service, is indeed from the specific enclave and not from an impostor.

Fig. 2 shows a system 200 according to an embodiment of the present invention. The system comprises four nodes in a network, which may be employed to allow a client node (not shown) to access a trusted service provided by an (SGX, SME) enclave running in another node 203: an attestation authority node 201, a trusted certification authority (TCA) 202, which has been referred to as the node 100 in Fig. 1, an TEE enclave running in the another node 203 and an administrator node 204, which administrates the another node 203.

In an embodiment the above introduced nodes may be configured to cooperate in the following way to allow a client to access a trusted service without adding functionality to either the client TLS stack or Browser. It is assumed that the enclave, to which the client intends to reveal sensitive data, is part of a web domain (e.g. example.com):

An administrator node“Admin” or 204 of a web domain providing services to web clients is configured to connect to one of potentially a plurality of enclaves, which are entities designed to ensure integrity of data and proving to appropriately configured clients their identity and to verify the authenticity of the particular enclave, meaning that it is member of a“family” of enclaves or nodes which belong to a domain and are authorized to provide services by the administrator. Once the“membership” of the specific enclave 203 to the family is confirmed by the administrator (node), the administrator node 204 may provide it with an according certificate of the web domain, wherein the certificate comprises a (secret) private key of the administrator 204. The specific enclave 203 is configured to generate a random public key and to create via a quoting enclave a signed report containing a hash of the public key according to SGX specifications. The enclave 203 is further configured to connect to the TCA 202, to demonstrate that it belongs to the particular web domain by using the web domain certificate, which it has received from the administrator 204 and to provide the TCA 202 with the signed report. The TCA 202 is configured to verify the authenticity of the signed report according to Intel 's Enhanced Privacy ID (EPID) algorithm. The TCA 202 is further configured to sign the certificate with a subject name, which comprises the enclave’s hash value of the public key, when the signed report has been verified by the TCA 202. In further embodiment, the subject name may comprise a URL composed of the enclave’s hash value of the public key and the web domain (e.g. enclavehash.example.com). The signed certificate now provides proof to a client node that the public key from the enclave has indeed been issued by the same enclave.

Fig. 3 shows a method 300 for allowing a client to access a trusted service provided by another node in a network according to an embodiment of the present invention, wherein the method comprises the steps of signing 301, by a node, a certificate to certify the ownership of a public key, whereby the public key is owned by an enclave of a trusted execution environment, TEE, in the another node and a code to be executed for providing the trusted service to the client node and data is protected in the enclave; and making 302, by the node, the signed certificate available to the client node.

Fig. 4 shows a method 400 for allowing a client to access a trusted service provided by another node in a network according to another embodiment of the present invention, wherein the method 300 further comprises the steps of connecting 401, by an administrator of the another node, to the enclave; verifying, by the administrator, the authenticity of the enclave; providing, by the administrator, the enclave with a private key of the certificate of the another node; generating 402, by the enclave, a random public key and creating a signed report containing a hash of the public key; connecting 403, by the enclave, to the node and demonstrating to the node that the enclave belongs to the another node by using the private key of the another node; providing 404, by the enclave, the node with the signed report; verifying 405, by the node, the authenticity of the signed report by using an enhanced privacy ID, EPID, algorithm in an attestation authority node; and wherein the step of signing 301, by the node, the certificate to certify the ownership of a public key comprises signing 406 the certificate with a named subject, wherein the named subject comprises the enclave’s hash value of its public key.

The present invention has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed invention, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word“comprising” does not exclude other elements or steps and the indefinite article“a” or“an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.

Claims

1. Node (100) for allowing a client node to access a trusted service provided by another node in a network, configured to:

sign (101) a certificate to certify the ownership of a public key,

wherein the public key is owned by an enclave of a trusted execution environment, TEE, in the another node and a code to be executed for providing the trusted service to the client node is protected in the enclave, and

make (102) the signed certificate available to the client node.

2. Node according to claim 1, wherein the format of the certificate comprises an additional protocol layer on top of the attestation protocol according to the X.509 standard.

3. System (200) for allowing a client to access a trusted service provided by another node in a network, comprising:

the node (202) according to claims 1 or 2;

another node (203), whereby the another node comprises a trusted execution environment, TEE, wherein a code to be executed for providing the trusted service to the client node and data is protected in the enclave;

an administrator node (204) of the another node; and

an attestation authority node (201).

4. System according to claim 3, wherein

the administrator node (204) is configured to:

connect to the enclave,

verify the authenticity of the enclave, and

provide the enclave with a private key of the certificate of the another node; the another node (203) is configured to:

generate a random public key and create a signed report containing a hash of the public key,

connect to the node and demonstrate to the node that the enclave belongs to the another node by using the private key of the another node, and

provide the node with the signed report; and the node (202) is further configured to:

verify the authenticity of the signed report by using an enhanced privacy ID, EPID, algorithm in the attestation authority node (201); and

sign the certificate with a named subject, wherein the named subject comprises the enclave’s hash value.

5. Method (300) for allowing a client to access a trusted service provided by another node in a network, comprising the steps of:

Signing (301), by a node, a certificate to certify the ownership of a public key, whereby the public key is owned by an enclave of a trusted execution environment, TEE, in the another node and a code to be executed for providing the trusted service to the client node and data is protected in the enclave; and

making (302), by the node, the signed certificate available to the client node.

6. Method (400) according to claim 5, comprising the further steps of:

Connecting (401), by an administrator of the another node, to the enclave;

verifying, by the administrator, the authenticity of the enclave;

providing, by the administrator, the enclave with a private key of the certificate of the another node;

generating (402), by the enclave, a random public key and creating a signed report containing a hash of the public key;

connecting (403), by the enclave, to the node and demonstrating to the node that the enclave belongs to the another node by using the private key of the another node; providing (404), by the enclave, the node with the signed report;

verifying (405), by the node, the authenticity of the signed report by using an enhanced privacy ID, EPID, algorithm in an attestation authority node; and

wherein the step of signing, by the node, the certificate to certify the ownership of a public key comprises signing (406) the certificate with a named subject, wherein the named subject comprises the enclave’s hash value.

7. Method according to claim 6, wherein the creating of a signed report containing a hash of the private key is carried out via a quoting enclave.

8. Computer program product comprising program code for controlling a node according to one of the claims 1 to 4, or for performing, when implemented on a processor, a method according to claims 5 to 7.