Patent Application
20220156390
The present invention relates to trusted execution environments (TEE), and in particular to a method and a system for performing attestation of an application running in a TEE of a remote host.
In the context of Trusted Execution Environments (TEE), remote attestation allows a verifier to collect evidence that a specific application runs untampered in a TEE of a remote host machine. For instance, in a blockchain network a full blockchain node may implement a TEE (e.g. in form of a secure enclave) that, in respect to a lightweight blockchain client's request, obtains unspent transaction output, UTXO, information and provides this information to the lightweight client. In such cases, prior to sending her request to the TEE, the lightweight blockchain client may perform an attestation with the TEE, in order to verify honest TEE execution, e.g. by verifying that a certain enclave code has been properly initialized.
Attestation is usually achieved by means of a digital signature scheme and a trusted component on the host machine. The host machine computes the “identity” of the application running in a local TEE, and signs the computed identity with a private key. The corresponding public key is certified by a trusted certification authority. The identity of the application being attested is usually computed by applying a suitable hash function to the application binary; further data related to the configuration of the host machine may also be used as additional input to the hash function. The signature over the identity is sent to the verifier, along with the certificate of the public key issued by the certification authority.
Therefore, considering the above scheme, the verifier has 1) to verify the validity of the certificate, 2) to verify the signature, and 3) to check that the identity signed by the remote host matches a reference identity of the application being attested. As such, the verifier needs to be well aware of the details of the host where the application is running and the details of the attestation scheme in place. In particular, the verifier must be aware of the signature scheme used by the host machine in order to verify its signature. Further, the verifier must be aware of the expected identity of the application being attested. This expected identity may depend on the architecture of the host machine and the attestation protocol being used. In fact, the application binary may be architecture-dependent, and also the attestation scheme being used may add other host-related information when computing the identity of the application being attested. To make the matter worse, the signature output by a host machine may not be publicly verifiable. In such scenarios, a designated attestation server may be involved to verify the signature and provide a (binary) response to the verifier. At times, the attestation server only allows registered verifiers.
As a result, given the current landscape of different TEEs and attestation mechanisms, it may not be straightforward or sometimes not even possible for a verifier to carry out a remote attestation protocol for a given application. For example, the verifier may not be able to compute the expected application identity for a given host architecture, or simply the verifier may not be registered with the attestation server involved in the protocol.
In an embodiment, the present disclosure provides a method that performs remote attestation using a gateway between a verifier and a remote host. The remote host has a trusted execution environment (TEE), in which an application to be attested is running. The gateway receives an attestation request from the verifier, determines a type of the TEE of the remote host and an expected identity of the application to be attested and selecting an attestation protocol based on the determined type of the TEE of the remote host, and verifies the expected identity of the application to be attested by executing the selected attestation protocol with the remote host and transmitting an attestation result to the verifier.
Subject matter of the present disclosure will be described in even greater detail below based on the exemplary figures. All features described and/or illustrated herein can be used alone or combined in different combinations. The features and advantages of various embodiments will become apparent by reading the following detailed description with reference to the attached drawings, which illustrate the following:
Embodiments of the present invention provide improved and further developed method and systems for performing remote attestation in such a way that a verifier is enabled to attest an application running in a TEE of a remote host, independently of the type of TEE or the attestation mechanism used by the remote host.
In accordance with an embodiment of the present invention, a method for performing remote attestation is provided, the method comprising:
using a gateway between a verifier and a remote host, wherein the remote host includes a trusted execution environment, TEE, in which an application to be attested is running;
receiving, by the gateway, an attestation request from the verifier;
determining, by the gateway, a type of the TEE of the remote host and an expected identity of the application to be attested and selecting an attestation protocol based on the determined type of the TEE of the remote host; and
verifying, by the gateway, the expected identity of the application to be attested by executing the selected attestation protocol with the remote host and transmitting an attestation result to the verifier.
Furthermore, an embodiment of the present invention provides a system for performing remote attestation, the system comprising a gateway to be disposed between a verifier and a remote host, wherein the remote host includes a trusted execution environment, TEE, in which an application to be attested is running, wherein the gateway is configured to provide for execution of the following steps:
receiving an attestation request from the verifier;
determining a type of the TEE of the remote host and an expected identity of the application to be attested and selecting an attestation protocol based on the determined type of the TEE of the remote host; and
verifying the expected identity of the application to be attested by executing the selected attestation protocol with the remote host and transmitting an attestation result to the verifier.
According to aspects of the present invention, an attestation gateway may be introduced between the verifier and the host where the TEE application is running. The attestation gateway can be configured to act as a verifier by itself or, more specifically, to perform attestation on behalf of the verifier. The gateway mediates between the verifier and an application to be attested running in a secure environment on the remote machine. In this way, the verifier is relieved from a number of computational tasks. In particular, it is not necessary to have different attestation services running on the verifier to cater for all types of TEEs and there is no need for the verifier to be aware of any single attestation execution steps. In fact, the verifier merely has to issue an attestation request including some minimum parameters and to receive a corresponding attestation result via the TEE attestation gateway, while the attestation procedure itself is performed by the gateway.
Consequently, according to embodiments of the present invention, even devices with rather limited computational capabilities are enabled to perform remote attestation for a diverse set of heterogeneous devices. In this context, the present invention overcomes the issue of attesting remote applications in a scenario where heterogeneous TEEs are available and applications may be deployed in any of them.
According to embodiments of the present invention, the attestation gateway comprises computational means to carry out any of the remote attestation protocols that may be used by the remote host.
According to embodiments of the present invention, the attestation gateway may comprise several modules that are configured to communicate with each other, wherein each of the modules is configured to perform a dedicated subtask of the remote attestation procedure. The gateway may comprise four modules: a platform identification module, a compilation module, an identity computation module, and a remote attestation module. The platform identification module may probe the host machine and identify the type of TEE running on that machine. The compilation module may be configured to compile the application code supplied by the verifier in accordance with the type of TEE where the application is running as detected by the platform identification module. The identity computation module may compute the expected identity of the application based on the compiled application supplied by the compilation module and the type of TEE as detected by the platform identification module. Finally, the remote attestation module may hold the verifier logic for a number of remote attestation protocols, select the appropriate one base on the type of TEE that runs on the host machine, and engage in a remote attestation protocol with the host machine. As will be appreciated by those skilled in the art, alternative implementations where the allocation of subtasks of the remote attestation procedure to individual modules of the attestation gateway differs from the allocation described above, are likewise possible.
According to embodiments of the present invention, the host may deploy an application A within the local TEE and the identity computation module may compute an expected identity IdA of the application A based on the compiled code of the application A and the type of TEE running at the host. In the context of the attestation procedure executed by the attestation gateway, the attestation gateway receives a signature from the host on an application identity Id′A. The attestation gateway may be configured to verify that the expected identity IdA matches Id′A and forward the result of the verification to the remote verifier.
According to embodiments the attestation gateway may use a digital signature scheme in the communication with the host machine. In this context, when the host machine computes the identity of the application to be attested (for instance by applying a suitable hash function to the application binary) and signs the computed identity with a private key, the signature over the identity, along with the certificate of the corresponding public key issued by a certification authority, may be sent to the attestation gateway. The attestation gateway may then use the public key to verify the validity of the certificate, to verify the signature, and to check that the identity signed by the remote host matches an expected (reference) identity of the application to be attested.
According to embodiments in which the attestation protocol in place involves a designated attestation server, the attestation gateway, specifically the remote attestation module of the attestation gateway, may leverage an attestation proxy, in particular an attestation proxy such as the one defined by Claudio Soriente, Ghassan Karame, Wenting Li, Sergey Fedorov: “ReplicaTEE: Enabling Seamless Replication of SGX Enclaves in the Cloud”, CoRR.abs/1809.05027, which is incorporated herein by reference.
According to one or more embodiments of the present invention, all dedicated modules may run on the same processing system and may even be implemented on the same electronic component. Alternatively, the modules may be implemented on different entities, wherein communication and interaction between the modules may be accomplished by means of wired or wireless communication technologies.
According to embodiments of the present invention, the communication between the verifier and the gateway as well as the communication between the gateway and the remote host may be implemented by using open protocols.
There are several ways how to design and further develop the teaching of the present invention in an advantageous way. To this end it is to be referred to the following explanation of exemplary embodiments of the present invention by way of example, illustrated by the drawings. In connection with the explanation of the exemplary embodiments of the present invention by the aid of the drawing, generally exemplary embodiments and further developments of the teaching will be explained.
Remote attestation is an essential feature of any distributed application that leverages Trusted Execution Environments (TEE). Via remote attestation, a verifier obtains evidence that a reference application runs untampered within a TEE of a remote machine. A number of TEE are currently available (e.g., Intel SGX, as described by V. Costan, et al., “Intel SGX explained.”, in Cryptology ePrint Archive (2016), or ARM TrustZone, as described at https://www.arm.com/products/silicon-ip-security) and different versions of a given TEE are provided by a range of vendors (e.g., Qualcomm and Trustonic offer a different version of TrustZone each).
Given such a heterogeneous landscape of TEEs, applications may be deployed in different systems, each implementing its own attestation mechanism. A verifier, therefore, must be aware of the machine hosting the application and of the attestation mechanism implemented by that host machine.
Embodiments of the present invention solve the above problem by means of an attestation gateway 30, as exemplary illustrated in
According to the illustrated embodiment, the gateway 30 is composed of four modules: a platform identification module 32, a compilation module 34, an identity computation module 36, and a remote attestation module 38.
As illustrated in
The compilation module 34 is configured to receive information on the code of the application 24, as supplied by the verifier 10, and to compile this application code in accordance with the type of TEE 22 where the application 24 is running, as detected by the platform identification module 32.
The identity ID of the application 24 may be computed by picking a hash function H, the application binary B, and computing the identity as ID=H(B). The hash function to be used depends on the attestation scheme in place. It could be SHA256 or any other function defined by the attestation scheme being used. According to embodiments, the identity may also include some platform attributes, e.g., the CPU model. In the latter case, let P be the platform parameters to be included, the identity may be computed as ID=H(P∥B) where ∥ denotes concatenation. It should be noted that which platform attributes (if any) are used to compute the identity of an application depends on the attestation scheme being used.
Based on the compiled application code supplied by the compilation module 34 and the type of TEE 22 as detected by the platform identification module 32, the identity computation module 36 is configured to compute the identity of the application 24 by applying the respective identity computation scheme in place, e.g., by computing ID=H(B) as exemplarily mentioned above. The identity of the application 24 is computed as an expected identity assuming that the information the identity computation module 36 received from the compilation module 34 (i.e. the compiled application code) and from the platform identification module 32 (i.e. the type of TEE 22) were correct.
Finally, the remote attestation module 38 is configured to hold the verifier logic for a number of remote attestation protocols, to select the right one based on the type of TEE 22 running on the host machine, 20 and to engage in a remote attestation protocol with the host machine 20 using the selected remote attestation protocol.
As the host machine 20 replies with a signature on the identity of the application 24 to be attested, the remote attestation module 38 checks the validity of the signature and that the signed identity matches the one computed by the identity computation module 36. If both checks succeed, the remote attestation module 38 provides a positive answer to the verifier 10; otherwise, it provides a negative answer to the verifier 10.
The flow starts at 201 and, when a remote verifier 10 issues a request for remote attestation of application 24, this request is received at the gateway 30 at 202. As a minimum requirement, the request should at least include the code of the application 24 for which the verifier 10 requests attestation, as well as information on the endpoint of the remote host 20 that runs or deploys the application 24 within the local TEE 22. For instance, the endpoint information can include an IP address of the host 20.
Considering the internal architecture of the attestation gateway 30 as illustrated in
At 204, the compilation module 34 compiles the code of the application 24 supplied by the verifier 10 for the trusted platform as identified and communicated by the platform identification module 32. To accomplish this task, according to an embodiment the compilation module 34 may be preconfigured with a number of architecture-dependent compilers 35. The compilers 35 may either reside directly on the compilation module 34, as exemplarily illustrated in
At 205, the identity computation module 36 uses the compiled code supplied by the compilation module 34 and the TEE 22 type of the host 20 as identified by the platform identification module 32, to compute the expected identity of the application 24. The expected identity is sent to the remote attestation module 38 of the gateway 30.
At 206, the remote attestation module 38 starts, as a verifier or, more precisely, on behalf of the verifier 10, a remote attestation protocol for the application 24 running on the host 20. The remote attestation protocol to be used is selected by the remote attestation module 38 in accordance with the remote attestation protocol in use by the host 20, wherein the selection is based on the type of TEE 22 running on the host 20 as informed by the platform identification module 32.
Using the selected remote attestation protocol, the remote attestation module 38 issues a request for remote attestation of the application 24 to the host 20. In response to the attestation request, the TEE subsystem 22 on the host 20 issues a signature on the identity of the application 24 running in the host's 20 local TEE 22. Upon receipt of the signature, at 207, the remote attestation module 38 first verifies the received signature. If, at 208, the signature proofs to be valid, the remote attestation module 38 continues with the second check at 209. This second check aims at verifying that the signed identity matches the expected identity as received from the identity computation module 36. If, at 210, this check turns out to be also successful, the remote attestation module 38 provides a positive attestation result to the verifier 10 at 211. If any of the two checks turns out to be unsuccessful, either at 208 or at 210, the remote attestation module 38 provides a negative attestation result to the verifier 10 at 212 before ending the process 213.
According to another embodiment, instead of informing the verifier 10 just of the final attestation result (i.e. positive or negative), the results of both verifications performed at 207 and at 209, respectively, may be directly forwarded to the verifier 10. Optionally, the remote attestation module 38 may forward the signature received from the host 20 to the verifier 10.
Many modifications and other embodiments of the invention set forth herein will come to mind the one skilled in the art to which the invention pertains having the benefit of the teachings presented in the foregoing description and the associated drawings. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.
While subject matter of the present disclosure has been illustrated and described in detail in the drawings and foregoing description, such illustration and description are to be considered illustrative or exemplary and not restrictive. Any statement made herein characterizing the invention is also to be considered illustrative or exemplary and not restrictive as the invention is defined by the claims. It will be understood that changes and modifications may be made, by those of ordinary skill in the art, within the scope of the following claims, which may include any combination of features from different embodiments described above.
The terms used in the claims should be construed to have the broadest reasonable interpretation consistent with the foregoing description. For example, the use of the article “a” or “the” in introducing an element should not be interpreted as being exclusive of a plurality of elements. Likewise, the recitation of “or” should be interpreted as being inclusive, such that the recitation of “A or B” is not exclusive of “A and B,” unless it is clear from the context or the foregoing description that only one of A and B is intended. Further, the recitation of “at least one of A, B and C” should be interpreted as one or more of a group of elements consisting of A, B and C, and should not be interpreted as requiring at least one of each of the listed elements A, B and C, regardless of whether A, B and C are related as categories or otherwise. Moreover, the recitation of “A, B and/or C” or “at least one of A, B or C” should be interpreted as including any singular entity from the listed elements, e.g., A, any subset from the listed elements, e.g., A and B, or the entire list of elements A, B and C.
| Number | Date | Country | Kind |
|---|---|---|---|
| 19161063.3 | Mar 2019 | EP | regional |
This application is a U.S. National Phase application under 35 U.S.C. § 371 of International Application No. PCT/EP2019/061076, filed on Apr. 30, 2019, and claims benefit to European Patent Application No. EP 19161063.3, filed on Mar. 6, 2019. The International Application was published in English on Sep. 10, 2020 as WO2020/177879 A1 under PCT Article 21(2).
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2019/061076 | 4/30/2019 | WO | 00 |
