A cross-platform measurement verification method and system for enclaves in a heterogeneous trusted execution environment

Abstract

The application provides a cross-platform measurement verification method and system of an enclave under a heterogeneous trusted execution environment, and is applied to direct verification of the enclave under the heterogeneous TEE. The method comprises the following steps: a cloud service provider generates a load program and constructs an enclave for a cross-platform application; a trusted measurement mapping calculates a cross-platform measurement and a native measurement of the enclave under the heterogeneous TEE for the cross-platform application; and a verifier remotely authenticates a target enclave by using the cross-platform measurement of the target cross-platform application held in advance through the trusted measurement mapping. The application has the beneficial effects of simplifying the verification mode of the enclave between the heterogeneous TEEs, promoting the interconnection of the heterogeneous TEEs, providing a measurement means based on the hardware characteristics of the TEE for the load program, and thus realizing a more secure and reliable verification scheme.

Description

[Technical Field]

[0001] This invention relates to the field of computer technology, specifically to a cross-platform measurement and verification method and system for enclaves in a heterogeneous trusted execution environment. [Background Technology]

[0002] With increasing emphasis on privacy and the widespread adoption of cloud computing, many privacy-preserving applications have been deployed in Trusted Execution Environments (TEEs) on cloud servers. A TEE is a secure enclave within the CPU, protecting the confidentiality and integrity of internally loaded code and data even when privileged software (such as the operating system) outside the secure zone is untrusted. Enclaves are typically identified by a hash digest of their initial code and data, also known as the enclave's metric. Simultaneously, TEEs provide a remote authentication mechanism to authorize remote users to verify the communication enclave's metric to establish trust and facilitate the transmission of private data. Currently successful and commercially available TEEs include Intel SGX, AMD SEV, and ARM TrustZone. Furthermore, various RISC-V-based TEEs have emerged, such as Penglai and Keystone.

[0003] Because different TEEs are typically designed based on different instruction set architectures, applications developed for a specific TEE architecture generally cannot run on TEEs with other architectures. However, as cloud servers begin to support various heterogeneous TEEs, support for cross-platform TEE applications will benefit both cloud service providers and developers. To address the application deployment difficulties caused by the strong coupling between TEEs and hardware platforms, much work has attempted to separate TEE application development from the underlying hardware. For example, this can be achieved by using cross-platform programming languages ​​or intermediate representations (IRs) to develop applications. Specifically, developers use cross-platform languages ​​to develop applications, or compile the original code into a cross-platform IR, and then deploy it to a TEE runtime container associated with the underlying platform.

[0004] However, remote authentication for TEE applications based on TEE runtime containers differs slightly from that of ordinary enclaves. In traditional remote authentication, the calculation of the enclave metric is performed by the TEE itself; therefore, when remote authentication is successful, the remote user can be certain that the target enclave is the intended application. However, for applications based on TEE runtime containers, the traditional remote authentication process only applies to the TEE runtime container being verified (excluding the target application), while the authentication of the target application relies on the TEE runtime container for indirect authentication. However, when the TEE runtime container and the application reside in the same address space, this indirect authentication method may introduce new security issues. Specifically, attackers could provide malicious applications to compromise the TEE runtime container and gain control, thereby maliciously manipulating indirect authentication. Since the metric of the TEE runtime container is merely a hash digest of its initial data and code, users cannot distinguish between genuine and tampered TEE runtime containers through remote authentication, potentially leading to the leakage of private data.

[0005] To address the aforementioned issues, an existing solution is to utilize sandboxing technology to isolate the TEE runtime container from the target application serving as the payload, such as Software Fault Isolation (SFI). However, this not only incurs additional performance and memory overhead, but verifying the correct implementation of SFI is also a challenge. Furthermore, previous attacks have demonstrated that sandboxing technology cannot completely protect against payload attacks on the TEE runtime container.

[0006] In summary, existing solutions still have shortcomings. Our invention proposes a new solution for cross-platform metric verification of enclaves under heterogeneous TEEs. [Summary of the Invention]

[0007] The purpose of this invention is to provide a cross-platform metric verification method for enclaves in a heterogeneous Trusted Execution Environment (TEE), aiming to solve the security problems caused by the indirect verification of payload programs within enclaves in existing technologies.

[0008] To achieve the above objectives, the present invention employs a cross-platform metric verification method for enclaves under heterogeneous TEEs. This method is applied to directly verify enclaves under heterogeneous TEEs, where the enclave utilizes a TEE runtime container to run cross-platform payload programs. The verification parties include an Independent Software Vendor (ISV), a cloud service provider, a heterogeneous cloud platform, a trusted metric mapping, and a verification party. The ISV develops a cross-platform application, the cloud service provider constructs the enclave through the cross-platform application, the heterogeneous cloud platform runs the enclave, and the trusted metric mapping can be implemented through the TEE enclave to maintain the mapping information between cross-platform metrics and native metrics. The verification party needs to verify the target enclave. The method includes:

[0009] The cloud service provider described in M1 builds payload programs and constructs enclaves for cross-platform applications;

[0010] The trusted metric mapping described in M2 calculates cross-platform metrics and native metrics for enclaves under heterogeneous TEEs for cross-platform applications;

[0011] The verifier described in M3 uses pre-held cross-platform metrics of the target cross-platform application to remotely authenticate the target enclave through trusted metric mapping.

[0012] Preferably, the cross-platform metric verification method for enclaves under heterogeneous TEEs, wherein the trusted metric mapping service has multiple implementation forms, including, in addition to the TEE enclave-based implementation, the following:

[0013] Verification local compilation and calculation: Generate cross-platform metrics for cross-platform applications and compile and calculate native metrics using the native metric generation mechanism, thereby generating a mapping between the two;

[0014] Smart contracts on the blockchain: Using smart contracts to simulate the generation of native metrics, a trusted mapping between cross-platform metrics and native metrics is recorded on the blockchain.

[0015] Preferably, the cross-platform metric verification method for enclaves under heterogeneous TEE, wherein the cloud service provider M1 constructs enclaves for cross-platform applications, specifically includes:

[0016] S11 describes the ISV uploading cross-platform applications to the cloud service provider;

[0017] The cloud service provider in S12 determines the configuration information of the enclave. The configuration information of the enclave can be specified by the ISV, or determined by the cloud service provider if not specified.

[0018] S13 Optionally, if the configuration information of the enclave specifies that the program needs to be further compiled, the cloud service provider compiles the cross-platform application to obtain the payload program (corresponding to the platform). If no further compilation is required, the payload program is the original cross-platform application.

[0019] S14 The cloud service provider loads the payload program and establishes an enclave, which will run on a heterogeneous cloud platform;

[0020] The cloud service provider described in S15 returns the configuration information of the target enclave.

[0021] Preferably, the cross-platform metric verification method for enclaves under heterogeneous TEEs, specifically includes the configuration information of the enclave under heterogeneous TEEs, namely: the specific TEE architecture, processor security version number, enclave version number, and whether the program has been further compiled, etc.

[0022] Preferably, the cross-platform metric verification method for enclaves under heterogeneous TEE, wherein the trusted metric mapping described in M2 maps the cross-platform metric calculated by the cross-platform application to the native metric of the enclave under heterogeneous TEE, taking the trusted metric mapping based on TEE enclave implementation as an example, specifically includes the following steps:

[0023] The trusted metric mapping described in S21 pre-generates intermediate hash digests of enclaves under heterogeneous TEEs;

[0024] The ISV described in S22 performs remote authentication of the trusted measurement map and uploads the configuration information of cross-platform applications and enclaves to the trusted measurement map;

[0025] The S23 Trusted Measurement Map uses a hash digest algorithm to calculate a digest for cross-platform applications and records the digest results as a cross-platform metric.

[0026] S24 Optionally, if the enclave configuration information specifies that the program needs to be further compiled, the trust measurement mapping may optionally further compile the cross-platform application according to the enclave configuration information to obtain the payload program (corresponding to the platform). If no further compilation is required, the payload program is the original cross-platform application.

[0027] The trusted metric mapping described in S25 takes the payload program as input, continues the hash digest process from the intermediate hash digest, and finally obtains the native metric of the enclave under the heterogeneous TEE. The algorithm used in the hash digest process corresponds to the algorithm for generating native metrics in the heterogeneous TEE.

[0028] The trusted metric mapping storage described in S26 maps cross-platform metrics, native metrics of heterogeneous TEEs, and configuration information of heterogeneous TEE enclaves to a database for querying during remote authentication.

[0029] Preferably, the cross-platform metric verification method for enclaves under heterogeneous TEE, wherein the trusted metric mapping in step S21 pre-generates the intermediate hash state of the enclave under heterogeneous TEE, specifically includes: reserving a region (payload section) in the enclave of heterogeneous TEE for storing payload program code, executing the process of loading and metric enclave of heterogeneous TEE, stopping the digest when the payload section is about to be loaded and metricd, and outputting the calculated intermediate hash state.

[0030] Preferably, the cross-platform metric verification method for enclaves under heterogeneous TEEs, wherein the verifier M3 utilizes pre-held cross-platform metrics of the target cross-platform application to remotely authenticate the target enclave through trusted metric mapping, specifically includes the following steps:

[0031] The verification party described in S31 follows the traditional remote authentication protocol to obtain the quotation of the target enclave;

[0032] The verifier in S32a extracts the native metric of the enclave from the quote, initiates a query request to the trusted metric mapping, and sends the native metric and the enclave configuration information.

[0033] The trusted metric mapping process in S33a requests a query request, searches the database for the cross-platform metric corresponding to the cross-platform application of the enclave, and sends msg1 to the verifier, wherein msg1 contains the query result;

[0034] The trust metric mapping in S34 sends msg2 to the verifier, where msg2 contains its own quote and a summary value of the query result for verifying the integrity of msg1;

[0035] The verifier described in S35 performs remote authentication of the trust metric mapping through msg2 and verifies the integrity of the query result of msg1 through the summary value of the query result;

[0036] After S36a verification is passed, the verifier determines whether it is the target enclave by comparing the msg1 query results with the expected cross-platform metric.

[0037] Preferably, the cross-platform metric verification method for enclaves under heterogeneous TEEs, in addition to being based on comparing expected cross-platform metrics, also includes being based on comparing expected native metrics, differing from claim 6 in S32a, S33a, and S35a, specifically including:

[0038] The S32b verification direction initiates a query request for the trusted metric mapping and sends the configuration information for the expected cross-platform metric and enclave.

[0039] The trusted metric mapping described in S33b searches the database for the native metric of the cross-platform application corresponding to the enclave, and sends msg1 to the verifier, wherein msg1 contains the query results;

[0040] After S36b verification is successful, the verifier determines its true identity by comparing the msg1 query result with the native metric in the enclave quote.

[0041] A second aspect of the present invention provides a cross-platform metric verification system for enclaves under heterogeneous TEE, the cross-platform metric verification system for enclaves under heterogeneous TEE includes:

[0042] Trusted metric mapping: This includes a mapping generation module and a database module, which are used to generate and store the mapping between cross-platform metrics and native metrics, respectively.

[0043] Target Enclave: Includes the target application module, the target application runtime module, and the verification service module, used to run the target application and implement remote authentication functions.

[0044] As can be seen from the above, this invention provides a cross-platform metric verification method and system for enclaves under heterogeneous TEEs. It is applied to directly verify enclaves implemented by cross-platform applications under heterogeneous TEEs. The method includes: a cloud service provider constructing an enclave for the cross-platform application; a trusted metric mapping calculating cross-platform metrics for the cross-platform application and the native metrics of the enclave under the heterogeneous TEE; and the verification party using pre-held cross-platform metrics of the target cross-platform application to remotely authenticate the target enclave through the trusted metric mapping. The beneficial effects of this invention are that it simplifies the verification mode of enclaves between heterogeneous TEEs, promotes the interconnection and interoperability of heterogeneous TEEs, and provides a metric means based on the hardware characteristics of the TEE for the payload program, thereby achieving a more secure and reliable verification scheme. [Attached Image Description]

[0045] Figure 1 This is a schematic diagram of ISV deployment of target applications under the cross-platform metric verification method of enclave under heterogeneous TEE;

[0046] Figure 2 This is a schematic diagram illustrating the verification of the target application by the verification party under the cross-platform metric verification method of enclave under heterogeneous TEE.

[0047] Figure 3 This is a schematic diagram of the load section in Example 1;

[0048] Figure 4 This is a schematic diagram of the load section in Example 2.

Detailed Implementation Methods

[0049] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0050]

Example 1

[0051] This embodiment implements a cross-platform metric verification method for enclaves under heterogeneous TEE.

[0052] [The technical problem to be solved by the method in this embodiment]

[0053] To address the indirect verification vulnerabilities inherent in current TEE runtimes and the shortcomings of corresponding sandbox security strategies, this embodiment proposes an alternative strategy: incorporating the target application's content into the overall enclave metric, thereby directly proving the expected cross-platform application. Furthermore, since the metrics computed by heterogeneous TEE implementations—i.e., native metrics—are not cross-platform, we introduce the concept of cross-platform metrics to measure cross-platform applications. This verifies whether two heterogeneous enclaves are actually running the same cross-platform application, even if they have different native metrics.

[0054] [Technical Solution of this Embodiment]

[0055] This embodiment's method includes a secure cross-platform metric verification framework, PORTMR, supporting enclaves under heterogeneous TEEs. Within the PORTMR framework, cross-platform TEE applications are developed using cross-platform programming languages ​​or IR and employ cryptographic hash algorithms for metric generation to produce their cross-platform metrics. Then, the cross-platform TEE application undergoes an optional compilation phase to generate a payload program, which is finally hardcoded into a reserved part of the TEE runtime to generate the final enclave for the corresponding TEE platform. Therefore, the native metric of the target enclave will include the payload program's content, thereby directly achieving remote authentication of the payload program. To facilitate the use of cross-platform metrics, we introduce two mechanisms for deterministically deriving native metrics from cross-platform metrics, or deriving cross-platform metrics from native metrics, and design a trusted metric mapping based on TEE enclaves to implement these two mechanisms.

[0056] Based on the above scheme, we provide a prototype implementation of PORTMR by using WebAssembly (WASM) as the IR and WebAssembly MicroRuntime as the TEE runtime, and use Intel SGX and RISC-V Penglaienclave as different ISAs (x86 and RISC-V, respectively). The following describes the implementation of our developed TEE enclave example TPLENCL and the two metric mechanisms, as well as the relevant implementation methods of trusted mapping and verification services under the PORTMR framework.

[0057] [TPLENCL Implementation Method]

[0058] In this example, TPLENCL's primary task is to load and execute cross-platform applications in the form of WASM or a further compiled AoT located in the payload section. This is achieved by customizing WAMR's iwasm as the underlying VM kernel for TPLENCL. Another task, supporting remote authentication, is achieved by introducing two additional WebAssembly System Interface (WASI) APIs into TPLENCL, which will be detailed later in the section on their corresponding authentication methods.

[0059] iwasm supports executing WASM applications on mainstream architectures including x86, ARM, and RISC-V, thus extending our framework to various heterogeneous TEEs. iwasm already provides an SGX implementation of the WASI API and supports executing WASM / AoT payload programs within SGX enclaves. However, unlike existing methods, we no longer load WASM / AoT programs from external input files; instead, the enclave loads WASM / AoT programs from its own reserved payload section. Specifically, we provide an SDK library libsgx_wasm that reserves a section named .sgx_wasm to store the payload program and its size. To hardcode the WASM / AoT program into the .sgx_wasm section, we extended the SIGN_WASM mode in the Intel SGX SDK's signing tool. This mode first places the given WASM / AoT file and its size into the .sgx_wasm section, and then performs the traditional signing process for enclave.so.

[0060] iwasm itself does not support the Penglai enclave, so we ported iwasm to the Penglai enclave and supported calls to the WASI API. To hardcode the WASM payload program into the enclave during enclave creation, we modified the enclave driver in the Penglai SDK so that during enclave creation, the modified driver allocates a fixed-length payload section, creates a page at a predefined high address 0xFFFFFFF000000000, and copies the provided WASM binary and its size to the page in the enclave.

[0061] The payload section begins at a page-aligned address and is n times the page size PG (4KB), denoted as n*PG. To store both the WASM / AoT payload and its size simultaneously, the most straightforward design is to place them sequentially from the beginning of the section. Specifically, the payload section begins with the payload size, an 8-byte unsigned integer, followed by the payload buffer, and ends with zeros or other known values. Figure 3 As shown. However, using this method, with a fixed load section size, the computation time required to calculate the summary value for this section is almost the same as filling the entire load section, even if the actual load program is very small. Therefore, to further reduce the computation time, we place the load program and its size at the end of the load section and fill the beginning with known values ​​(i.e., zero), as shown. Figure 4 As shown, any intermediate hash state of TPLENCL can be calculated in advance, so when deriving the native metric, it is only necessary to continue the metric process from the intermediate hash state before the payload program, thereby achieving higher efficiency.

[0062] [Measurement Mechanism Implementation Method]

[0063] In this embodiment, inspired by MAGE, to improve the efficiency of calculating native metrics, we modified the Intel SGXSDK and Penglai SDK to adjust the order of the metric process, enabling the calculation of native metrics from intermediate hash states. First, as described in the TPLENCL embodiment, we minimized the size of the suffix portion of different TPLENCLs and output the intermediate hash state of the prefix portion to be hardcoded into MAPENCL. Below, we describe how SGX TPLENCL and PenglaiTPLENCL calculate native metrics from a given payload program.

[0064] For SGX, enclave pages are created and initialized by loading the enclave.so binary, and enclave metrics are updated simultaneously with enclave page creation. SGX TPLENCL reserves the .sgx_wasm section for loading payload programs. In this embodiment, following the method described in MAGE, we modify the enclave.so parser and loader in the Intel SGX SDK so that the .sgx_wasm section is loaded last. Specifically, when the modified loader loads the .sgx_wasm section during enclave creation, it will temporarily skip it and load the pages in that section at the last moment before enclave initialization. Since the prefix contains everything except the WASM / AoT payload program, the suffix is ​​minimized. Furthermore, we introduce another mode, GEN_WASM_VM_MR, to extend the Intel SGX SDK's signing tools. In this mode, the intermediate hash state of SHA256, including the intermediate hash value, the number of blocks processed before .sgx_wasm, and the offset of .sgx_wasm, will be output for native metric calculation.

[0065] For Penglai enclaves, enclave metrics are calculated by traversing memory from lowest to highest address using page tables. We modified the Penglai enclave driver to store the WASM payload program at a predefined address (i.e., 0xFFFFFFF000000000). Since this is the highest address in the default memory layout of the enclave in the Penglai enclave SBI, the WASM payload is calculated last, thus achieving the smallest suffix portion. Furthermore, we modified the SBI implementation of PLencave_attest() (the Penglai enclave SDK API for obtaining enclave metrics and generating enclave reports) so that when the payload section start address is encountered, the intermediate hash state and the total number of bytes processed are output for native metric calculation.

[0066] Calculating native metrics first requires determining the metadata of the intermediate hash state and TPLENCL configuration information. This metadata consists of three distinct fields: the first field, TEE Type, specifies the type of the target TEE platform; the second field, CPU SVN, represents the security version number of the TEE implementation; and the third field, TPLENCL Version, represents the version number of TPLENCL on the target TEE platform. Each of these three fields directly impacts the intermediate hash state. Furthermore, as described in the TPLENCL implementation method, to improve the efficiency of calculating native metrics, we also provide a startup function, `derivation_init()`, for calculating a list of intermediate hash states with prefix pages of different sizes.

[0067] For the payload program, when the target TEE platform (e.g., SGX TPLENCL)'s TEE runtime supports AoT mode, we can choose the wamrc compiler to compile the WASM code into an AoT binary file as the payload program. The wamrc compiler is part of WAMR and is compatible with the TPLENCL VM kernel (i.e., iwasm). Therefore, to export the native metrics of TPLENCL with AoT as the payload program, the compilation process needs to be reproduced using the same compiler, wamrc.

[0068] Given the target TEE platform information and a WASM or AoT binary file, we first retrieve the corresponding intermediate hash state list pre-computed in `derivation_init()`. Then, we calculate the index of the page the payload program should hardcode in `TPLENCL` and obtain the corresponding intermediate hash state from the list. Finally, we continue the measurement process using the contents of the input WASM or AoT binary file and obtain the native measurement of the expected target enclave using the target TEE's corresponding cryptographic hash algorithm.

[0069] In this embodiment, we use SHA256 to generate a 256-bit digest of the WASM as a cross-platform metric. SHA-256 is one of the Secure Hash Algorithms 2 (SHA-2) series and is one of the most secure hash functions available today. Therefore, the generated digest can identify the input WASM code while successfully protecting its integrity.

[0070] To obtain the mapping between native metrics and cross-platform metrics, native metrics need to be calculated using the native metrics mechanism implementation method. Further mapping information is generated, including cross-platform metrics, native metrics, and target enclave configuration information. The target enclave configuration information includes four fields: TEE Type, CPU SVN, TPLENCL Version generated during TPL generation, and Payload Format, indicating whether the payload program's specific format is derived from WASM or AoT binary files, thus indicating whether the cross-platform code has undergone further compilation.

[0071] [Metric Mapping and Validation Implementation Methods]

[0072] To support the PORTMR framework, we implemented MAPENCL on a TEE enclave to compute and maintain the mapping between cross-platform metrics and native metrics. Our MAPENCL implementation is based on SGX and Occlum, and provides two WASI APIs on the TPLENCL side for WASM applications to obtain their own cross-platform metrics and native metrics.

[0073] In MAPENCL, this embodiment includes an API called `req_measurement_generation()` for generating metric maps. After MAPENCL initialization, `derivation_init()` is first called to calculate the intermediate hash state list. Subsequently, if AoT mode support is required, MAPENCL needs to reproduce the compilation process, which must be deterministic and reproducible to ensure the generation of native metrics identical to those on the cloud platform. In this example, our multiple experiments showed that `wamrc` produced the same compilation results, therefore we believe that the `wamrc` used meets the requirements of determinism and reproducibility. To ensure the reliability of the compilation process, we placed `wamrc` in an enclave and used Occlum to implement MAPENCL. After the metric map calculation is completed, MAPENCL stores the map locally through a predefined mapping structure to achieve native metric derivation and cross-platform metric derivation services for the verifier. To achieve efficient querying of the map, we use SQLite, a C library that implements a small, fast SQL database engine to index the map. The integrity of the SQL database is protected by Occlum's simple encrypted file system. Furthermore, a MAPENCL can share its metric map with another MAPENCL after mutual verification using mechanisms such as MAGE, saving the time required to generate metric maps on another MAPENCL. Therefore, a set of MAPENCLs can share their metric maps and provide services in a distributed manner, rather than running a single centralized MAPENCL.

[0074] In MAPENCL, this embodiment also includes an API called `req_measurement_mapping()`, which takes cross-platform metric (or native metric), TEE type, CPU SVN, TPLENCL version, and payload format as input and searches its database for records with matching fields. If no record is found, MAPENCL will request an upload of a WASM application to generate a mapping. If such a record (mapping) is found, MAPENCL generates a report in which the SHA-256 hash digest of the record is sent as its report data to the quote enclave to obtain a quote with an EPID signature. Subsequently, MAPENCL sends a request to Intel Certification Service (IAS) with the quote as the request body of the IAS report. The IAS report contains basic fields such as certificate, response body containing the quote and quote status, and signature of the response body, which TPLENCL will use to verify the validity of the report and the identity of MAPENCL. These three fields of the IAS report, along with the query results, are sent back to the user or the enclave that issued the request.

[0075] In TPLENCL, to facilitate WASM application developers in using cross-platform metrics, this embodiment introduces and implements two WASI APIs, namely get_native_measurement() and get_portable_measurement(), which are used by WASM programs within the enclave to obtain their own cross-platform metrics and the enclave's native metrics.

[0076] For SGX TPLENCL, `get_native_measurement()` uses the `sgx_create_report()` API provided by the Intel SGX SDK to generate a report and retrieve the native measurement from the generated report. `get_portable_measurement()` first retrieves the native measurement to send to MAPENCL. Since network access is not supported within the enclave, this example also introduces several network-related APIs to enable communication between TPLENCL and MAPENCL. MAPENCL responds with the mapping and three fields of the IAS report (i.e., certificate, signature, and response body). Verifying the returned mapping results involves the following five steps:

[0077] 1. Verify the certificate using the IAS root key obtained from IAS and pre-hardcoded into TPLENCL. If successful, this ensures that the IAS report was indeed returned from IAS and the certificate key was extracted.

[0078] 2. Verify the signed response body using the certificate key. If successful, TPLENCL can be confident that the response body has not been modified;

[0079] 3. Check the quote status in the response body to ensure that the EPID signature of the quote has been correctly verified by IAS. If the status is OK, the quote is valid;

[0080] 4. Compare the metric in the quote with the expected MAPENCL metric, which is hardcoded into TPLENCL's initial data in advance. This makes TPLENCL believe that the IAS report is a response to the MAPENCL request, rather than some other malicious enclave.

[0081] 5. Verify the native metrics within the map and compare the map's hash with the report data to ensure the map's integrity. If all the above verification processes are successful, TPLENCL can trust the returned map and return the cross-platform metrics within it.

[0082] For Penglai enclave TPLENCL, the existing get_report() API in the Penglai enclave SDK calculates and returns a hash digest of the real-time content in the enclave's memory. However, this hash digest is likely to differ from the hash digest with the initial content. To address this, we extended the Penglai enclave SBI and Penglai enclave SDK with the new API get_initial_report(), which generates a report containing metrics of the initial content. It is called by get_native_measurement() to retrieve native metrics. The Penglai enclave get_portable_measurement() process is similar to that of Intel SGX. Like Intel SGX, Penglai enclaves do not support network access. To enable network communication between the Penglai enclave TPLENC and MAPENC, we extended five socket-related APIs on the Penglai enclave SDK and Penglai enclave SBI, including eapp_socket(), eapp_socket_connect(), eapp_socket_send(), eapp_socket_recv(), and eapp_socket_shutdown(). The verification process of get_portable_measurement() is implemented using the WolfSSL library, which is integrated into the Penglai enclave SDK.

[0083] Since the expected MAPENCL metric can only be determined after the prefix portion of TPLENCL is determined, we hardcode the MAPENCL metric into the suffix portion of TPLENCL. On the other hand, since the derivation of the native metric requires the content of the suffix portion, MAPENCL can obtain this information (i.e., its own metric) at runtime to complete the derivation. Furthermore, for simplicity, we reserve the last 64 bytes of the payload section as a suffix portion to store the MAPENCL metrics of both TPLENCLs, instead of creating a new reserved area.

[0084] Those skilled in the art will understand that all or part of the methods described in the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM).

[0085] The above description is only a preferred embodiment of the present invention. It should be noted that those skilled in the art can make several improvements and additions without departing from the principle of the present invention, and these improvements and additions should also be considered within the scope of protection of the present invention.

Claims

1. A cross-platform metric verification method for enclaves in heterogeneous trusted execution environments, applied to directly verify enclaves in heterogeneous trusted execution environments, wherein the enclave utilizes a TEE runtime container to run a cross-platform payload program, and a heterogeneous cloud platform runs the enclave, characterized in that, The method includes: S1, cloud service providers build payload programs and construct enclaves for cross-platform applications; specifically including: S11, ISV uploads the cross-platform application to the cloud service provider; S12, The cloud service provider determines the configuration information of the enclave. The configuration information of the enclave is specified by the ISV, or determined by the cloud service provider if not specified. S13, if the configuration information of the enclave specifies that the program needs to be further compiled, the cloud service provider compiles the cross-platform application to obtain the payload program; if no further compilation is required, the payload program is the original cross-platform application. S14, The cloud service provider loads the payload program and establishes an enclave, which will run on the heterogeneous cloud platform; S15, the cloud service provider returns the configuration information of the target enclave; S2, Trusted Metric Mapping calculates cross-platform metrics and native metrics for enclaves under heterogeneous TEEs for cross-platform applications; specifically, it includes the following steps: S21, the trusted metric mapping pre-generates intermediate hash digests of enclaves under heterogeneous TEEs; S22, ISV performs remote authentication of the Trusted Measurement Map and uploads configuration information for cross-platform applications and enclaves to the Trusted Measurement Map; S23, the trusted metric mapping uses a hash digest algorithm to calculate a digest for cross-platform applications and records the digest results as a cross-platform metric; S24, if the enclave configuration information specifies that the program needs to be further compiled, the trust measurement mapping may optionally further compile the cross-platform application according to the enclave configuration information to obtain the payload program; if no further compilation is required, the payload program is the original cross-platform application. S25, the trusted metric mapping takes the payload program as input, continues the hash digest process from the intermediate hash digest, and finally obtains the native metric of the enclave under the heterogeneous TEE. The algorithm used in the hash digest process corresponds to the algorithm for generating native metrics in the heterogeneous TEE. S26, The trusted measurement mapping stores the cross-platform measurement, the native measurement of heterogeneous TEE, and the configuration information of the enclave of heterogeneous TEE to the database for querying during the remote authentication process; S3, the verifier uses the cross-platform metrics of the target cross-platform application held in advance to remotely authenticate the target enclave through trusted metric mapping.

2. The cross-platform metric verification method for enclaves in a heterogeneous trusted execution environment according to claim 1, characterized in that, The implementation of the trusted measurement mapping service also includes: Verification local compilation and calculation: Generate cross-platform metrics for cross-platform applications and compile and calculate native metrics using the native metric generation mechanism, thereby generating a mapping between the two; Smart contracts on the blockchain: Using smart contracts to simulate the generation of native metrics, a trusted mapping between cross-platform metrics and native metrics is recorded on the blockchain.

3. The cross-platform metric verification method for enclaves in a heterogeneous trusted execution environment according to claim 1, characterized in that, The configuration information of the enclave under the heterogeneous TEE mentioned in S12 specifically includes: TEE architecture, processor security version number, enclave version number, and whether the program has been further compiled.

4. The cross-platform metric verification method for enclaves in a heterogeneous trusted execution environment according to claim 1, characterized in that, The trusted measurement mapping described in S21 pre-generates the intermediate hash state of the enclave under the heterogeneous TEE, specifically including: reserving a region in the enclave of the heterogeneous TEE for storing payload program code, executing the process of loading and measuring the enclave of the heterogeneous TEE, stopping the digest when the payload is about to be loaded and measured, and outputting the calculated intermediate hash state.

5. The cross-platform metric verification method for enclaves in a heterogeneous trusted execution environment according to claim 1, characterized in that, The verifier described in S3 uses pre-held cross-platform metrics of the target cross-platform application to remotely authenticate the target enclave through trusted metric mapping, specifically including the following steps: S31, The verification party follows the traditional remote authentication protocol to obtain the quotation of the target enclave; S32a, the verifier extracts the native metric of the enclave from the quotation of the target enclave, initiates a query request to the trusted metric mapping and sends the native metric and the configuration information of the enclave; S33a, the trusted metric mapping process query requests, searches the database for the cross-platform metric corresponding to the cross-platform application of the enclave, and sends msg1 to the verifier, wherein msg1 contains the query results; S34, the trust metric map sends msg2 to the verifier, msg2 contains its own quote and a summary value of the query result for verifying the integrity of msg1; S35, the verifier performs remote authentication of the trust metric mapping through msg2, and verifies the integrity of the query result of msg1 through the summary value of the query result; S36a, After successful verification, the verifier determines whether it is the target enclave by comparing the msg1 query result with the expected cross-platform metric.

6. The cross-platform metric verification method for enclaves in a heterogeneous trusted execution environment according to claim 5, characterized in that, In addition to cross-platform metrics based on comparison expectations, validation methods also include native metrics based on comparison expectations, specifically including: S32b, the verification direction initiates a query request for the trusted metric mapping and sends the configuration information of the expected cross-platform metric and enclave; S33b, the trusted metric mapping searches the database for the native metric of the cross-platform application corresponding to the enclave, and sends msg1 to the verifier, wherein msg1 contains the query result; S36b, After successful verification, the verifier determines its true identity by comparing the query result of msg1 with the native metric in the enclave quote.

7. A cross-platform metric verification system for enclaves in a heterogeneous trusted execution environment, used to implement the method described in any one of claims 1-6, characterized in that, include: Trusted metric mapping includes a mapping generation module and a database module, which are used to generate and store cross-platform metric and native metric mappings, respectively. A target enclave is used to run the target application and implement remote authentication.

8. The cross-platform metric verification system for enclaves in a heterogeneous trusted execution environment according to claim 7, characterized in that, include: The target enclave includes: The target application module is used to run the application provided by the ISV as a payload in an enclave of a heterogeneous trusted execution environment; The runtime module of the target application is used to execute the payload program and provides the runtime support required by the payload program; The verification service module provides interfaces for remote authentication between enclaves and verification parties in heterogeneous trusted execution environments.

Images