Scalable proof for trusted execution environments

Abstract

To provide a system, a method, and a program for realizing scalable attestation for trusted execution environments.SOLUTION: In function-as-a-service (FaaS) environments, a client makes use of a function executing within a trusted execution environment (TEE) on a FaaS server. Multiple tenants of the FaaS platform provide functions to be executed by the FaaS platform via a gateway. A client device of each tenant provides code and data for any number of functions to be executed within any number of TEEs on the FaaS platform and accessed via the gateway. Additionally, each client device provides code and data for a single surrogate attester TEE. The client device attests each of the other TEEs of the tenant by using the surrogate attester TEE, and establishes trust with the functions in those TEEs.SELECTED DRAWING: Figure 6

Description

Technical Field

[0001] The subject matter disclosed in this specification generally relates to a trusted execution environment (TEE) for hardware. Specifically, this disclosure addresses systems and methods for scalable attestation and orchestration of functions within a TEE.

Background Art

[0002] Hardware privilege levels may be used by a processor to restrict memory access by applications operating on a device. The operating system operates at a higher privilege level, can access all memory of the device, and can define memory ranges for other applications. Applications operating at a lower privilege level are restricted to accessing memory within the ranges defined by the operating system and cannot access the memory of other applications or the operating system. However, applications have no protection from a malicious or compromised operating system.

[0003] An enclave is enabled by a processor to provide protection that ensures that code and data loaded within the enclave are protected from access by code executing outside the enclave. Thus, an enclave provides an isolated execution environment that prevents access to data and code contained within the enclave from malicious software, including the operating system, at the hardware level.

Brief Description of the Drawings

[0004] Some embodiments are shown by way of example and not limitation in the figures of the accompanying drawings. [Figure 1] A network diagram showing a network environment suitable for a server that uses a TEE to provide a service as a service according to some exemplary embodiments. [Figure 2]This is a block diagram of a function-as-a-service server suitable for scalable proof of TEE, with several exemplary embodiments. [Figure 3] This is a block diagram of conventional ring-based memory protection. [Figure 4] This is a block diagram of an enclave-based memory protection suitable for reducing TEE latency, according to several exemplary embodiments. [Figure 5] This is a block diagram of a database schema suitable for use in scalable proof of TEE, with several exemplary embodiments. [Figure 6] This is a block diagram of a communication link between a function and a device, suitable for use in scalable proof of a TEE, according to several exemplary embodiments. [Figure 7] This flowchart shows the operation of a server-side method suitable for providing scalable proof of TEE, according to several exemplary embodiments. [Figure 8] This flowchart shows how a client-friendly method of utilizing TEE's scalable proof works, based on several exemplary embodiments. [Figure 9] This flowchart shows how a client-friendly method of utilizing TEE's scalable proof works, based on several exemplary embodiments. [Figure 10] This is a block diagram showing an example of a software architecture for a computing device. [Figure 11] This is a block diagram of a machine representing an exemplary form of a computer system, in which instructions can be executed to cause the machine to perform one or more of the methods discussed herein. [Modes for carrying out the invention]

[0005] Exemplary methods and systems are directed toward scalable attestation of TEEs. In its most common sense, a TEE is any trusted execution environment, regardless of how its trust is obtained. An enclave is a portion of memory protected from access by processes outside the enclave, even if those processes are operating at an elevated privilege level. As an example, a TEE is discussed as one provided by executing code within an enclave. However, other types of TEEs may be used.

[0006] A TEE can be used to enable the secure handling of sensitive information by protecting it from all software outside of the TEE. A TEE may also be used in modular programming, where each module contains everything necessary for its own functionality without being exposed to vulnerabilities caused by other modules. For example, a successful code injection attack against one TEE cannot affect the code of another TEE.

[0007] Total memory encryption (TME) protects data in memory from being accessed by bypassing the processor. The system generates an encryption key within the processor at boot time and never stores this key outside the processor. The TME encryption key is ephemeral because it does not persist across reboots and is never stored outside the processor. All data written to memory by the processor is encrypted using the encryption key and decrypted when read back from memory. Therefore, hardware-based attacks attempting to read data directly from memory without processor intervention will fail.

[0008] Multi-key TME (MKTME) extends TME to utilize multiple keys. Individual memory pages can be encrypted using the TME's temporary key or a software-provided key. This can potentially provide greater security against software-based attacks than TME because an attacker would need to identify the specific key used by the target software, rather than having the processor automatically decrypt any memory the attack software gains access to.

[0009] In a Function-as-a-Service (FaaS) environment, clients utilize functions that run within a TEE (Third-Effective Execution Environment) on a FaaS server. The FaaS platform provides a cloud computing service that executes application logic but does not store data. Before providing sensitive data to a function, the client verifies that the function is running on a TEE and therefore the sensitive data cannot be accessed by other functions that are not part of the trusted environment.

[0010] Several complete or partial solutions exist for proof. For example, a public key can be embedded in the code block provided to the FaaS server for execution in TEE. The client device can encrypt the data before sending it to the function in the code block. Thus, the client device is assured that only code with access to the public key can access the encrypted data. However, this function can still be executed in an insecure environment. Furthermore, an attacker could extract the public key from the code block and use it in malicious code that impersonates the intended function.

[0011] When an enclave is created, it can be "measured." In this context, a measurement refers to a set of data sufficient to uniquely identify the attributes and contents of the enclave. Thus, two enclaves will have the same measurement only if they contain the same code and data, use the same amount of memory, and have the same security level. The measurement of an enclave is performed by a hardware processor and stored in a protected register or memory. The measurement can be signed by the processor using an asymmetric proof key based on the Elliptic-Curve-Digital-Signature-Algorithm (ECDSA). Another processor, incorporating the corresponding decryption key, can verify the signature. The signed data can include a timestamp and an identifier of the signer. In this way, the recipient can verify that the signed data is currently valid and originating on the FaaS server.

[0012] Using this proof mechanism, a client can prove that the functionality it accesses directly is indeed running on the TEE. However, it can be beneficial for a FaaS server to provide gateway interfaces to multiple functions. For example, a representational state transfer (REST) ​​application programming interface (API) allows a client to make function calls using the Hypertext Transport Protocol (HTTP). In these implementations, the gateway application receives all REST API function calls, translates the uniform resource locator (URL) into function identifiers and function parameters, calls the function with the function parameters, receives the results, and delivers the results over the network. The gateway may also operate within the TEE, in which case the client device can prove the gateway. However, the gateway's measurements do not prove to the client device that the underlying functionality is also running on the TEE.

[0013] Multiple tenants of a FaaS platform can provide functionality performed by the FaaS platform via a gateway. A tenant is a group of users who share common access to data, such as users with accounts linked to a specific company. Data protection between tenants may be a goal for both tenants and the FaaS platform. A FaaS platform includes one or more FaaS servers in one or more data centers. Therefore, the gateway may include a load balancer for distributed computing or other functionality. Because the FaaS platform provides functionality to multiple tenants via a gateway, no single tenant can control the gateway.

[0014] As discussed herein, each tenant can provide code and data for any number of functions that run within any number of TEEs on the FaaS platform and are accessed via a gateway. Furthermore, each tenant can provide code and data for a single surrogate attester TEE. A tenant's client device uses the surrogate attester TEE to authenticate each of the tenant's other TEEs and establish trust with the functions within those TEEs. Once the functions are authenticated, the client device is confident that the tenant's other TEEs are running on the same platform as the gateway (which can also be authenticated).

[0015] Because the tenant controls the contents of the delegated certificate TEE, the delegated certificate TEE can be designed to securely certify each of the tenant's deployed TEEs, something the gateway cannot do. Since only one delegated certificate TEE is required for each tenant, this solution is scalable and allows for the creation of any number of TEEs for each tenant without increasing the certification overhead.

[0016] Compared to existing methods for proving tenant enclaves, the methods and systems discussed herein enable the use of gateways to access enclaves without requiring direct proof through the network for each enclave, thus reducing network usage. System security is enhanced because the overhead of a single delegated certificateer (TEE) does not increase when tenant functionality is protected by finer-grained enclaves. When these effects are considered as a whole, one or more of the methodologies described herein can avoid the need for certain effort or resources that would otherwise be involved in proving enclaves. Computational resources used by one or more machines, databases, or networks can similarly be reduced. Examples of such computing resources include processor cycles, network traffic, memory usage, data storage capacity, power consumption, and cooling capacity.

[0017] Figure 1 is a network diagram showing a network environment 100 suitable for a server that provides functionality as a service using TEE, according to several exemplary embodiments. The network environment 100 includes FaaS servers 110A and 110B, client devices 120A and 120B, and network 130. FaaS servers 110A to 110B provide functionality to client devices 120A to 120B via network 130. FaaS servers 110A and 110B may be collectively referred to as FaaS server 110, or generically as FaaS server 110. Client devices 120A and 120B may be collectively referred to as client device 120, or generically as client device 120.

[0018] Client devices 120A and 120B can be devices of different tenants, whereby each tenant desires to ensure that their tenant-specific data and code are not accessible by other tenants. Thus, FaaS servers 110A-110B can use enclaves for each FaaS provided. FaaS servers 110A-110B and client devices 120A and 120B can each be implemented, in whole or in part, in a computer system as described hereinafter with respect to FIG. 9.

[0019] The systems and methods described herein can be used to provide attestation of TEEs in a scalable manner. For example, an attestation proxy enclave for each tenant can be created by FaaS server 110 to enable attestation by client device 120 of the functions provided before accessing the functions through the gateway.

[0020] Any of the machines, databases, or devices shown in FIG. 1 can be implemented on a general-purpose computer that is modified (e.g., configured or programmed) by software to be a dedicated computer for performing the functions described herein for that machine, database, or device. For example, a computer system capable of implementing any one or more of the methods described herein will be discussed later with respect to FIG. 9. As used herein, a "database" is a data storage resource and can store data structured as a text file, table, spreadsheet, relational database (e.g., an object-relational database), triple store, hierarchical data store, document-oriented NoSQL database, file store, or any suitable combination thereof. The database may be an in-memory database. Further, any two or more of the machines, databases, or devices shown in FIG. 1 may be combined into a single machine, database, or device, or the functions described herein for any single machine, database, or device may be subdivided among multiple machines, databases, or devices.

[0021] The FaaS server 110 and the client device 120 are connected by a network 故130. The network 130 can be any network that enables communication between machines, databases, and devices. Thus, the network 130 can be a wired network, a wireless network (e.g., a mobile or cellular network), or any suitable combination thereof. The network 130 can include one or more portions that constitute a private network, a public network (e.g., the Internet), or any suitable combination thereof. Each of the devices is connected to the network 130 using a network interface.

[0022] Figure 2 is a block diagram 200 of a FaaS server 110A suitable for scalable proof of TEE, according to several exemplary embodiments. The FaaS server 110A includes a communication module 210, a gateway function 220, a trusted component 230 for the application, a trusted domain module 240, a surrogate attester 250, shared memory 260, and private memory 270, all of which are shown configured to communicate with one another (e.g., via a bus, shared memory, or switch). Any one or more of the modules described herein may be implemented using hardware (e.g., a machine's processor). For example, any module described herein may be implemented by a processor configured to perform the operations described herein for that module. Furthermore, any two or more of these modules may be combined into a single module, and the functions described herein for a single module may be subdivided among multiple modules. Furthermore, according to various exemplary embodiments, modules described herein as being implemented within a single machine, database, or device may be distributed across multiple machines, databases, or devices.

[0023] The communication module 210 receives data sent to the FaaS server 110A and sends data from the FaaS server 110A. For example, the communication module 210 can receive a request from a client device 130A to perform a function. After the function is performed, the result of the function is provided to the client device 130A by the communication module 210. The communication sent and received by the communication module 210 may be mediated by the network 130. The called function may be mediated by another function. For example, the communication module 210 can provide a URL to the gateway function 220. The gateway function 220 parses the URL and calls a function in the trusted component 230.

[0024] The gateway function 220 can run either inside or outside the enclave. If the gateway function does not run within the enclave, the gateway function 220 is vulnerable to attack if the operating system or other untrusted components are compromised. Trusted components 230 run within the enclave. Therefore, even if the operating system or untrusted components 220 are compromised, the data and code of trusted components 230 remain secure.

[0025] The trusted domain module 240 creates and protects the enclave and is responsible for the execution transition between the gateway function 220 and the trusted component 230. Signed code may be provided to the trusted domain module 240, which verifies that the code has not been modified since it was signed. The signed code is loaded into a portion of the physical memory designated as part of the enclave. Hardware protection then prevents untrusted software from accessing, modifying, executing, or appropriately combining these actions on the enclave memory. This code may be encrypted using a key available only to the trusted domain module 240.

[0026] Once the trusted component 230 is initialized, the gateway function 220 can invoke the functions of the trusted component 230 using special processor instructions of the trusted domain module 240 to transition from untrusted mode to trusted mode, or between trusted enclaves. The trusted component 230 performs parameter verification, executes the requested function if the parameters are valid, and returns control to the gateway function 220 via the trusted domain module 240. Multiple trusted components 230 may be instantiated within the FaaS server 110A, each providing one or more functions.

[0027] Trusted Domain Module 240 may be implemented as one or more components of Intel® Software Guard Extensions (SGX), Intel® Trust Domain Extensions (TDX), or Intel® hardware processors that provide both. In Intel® SGX, proof is a mechanism by which a third entity establishes that a software entity is operating on an Intel® SGX-enabled platform protected within an enclave before providing confidential and protected data to that software. Proof relies on the platform's ability to generate credentials that accurately reflect the enclave's signature, including information about the enclave's security characteristics. The Intel® SGX architecture provides mechanisms to support two forms of proof: a mechanism for creating basic assertions between enclaves operating on the same platform, which supports local or in-platform proof, and then another mechanism that provides a foundation for proof between an enclave and a remote third party.

[0028] The proxy certificater 250 generates an attestation for the enclave (e.g., trusted component 230). The attestation is an evidence structure that uniquely identifies the certified enclave and the host (e.g., FaaS server 110A) using asymmetric encryption and supported by the built-in processor functionality. The attestation can be provided to the client device 120 via the communication module 210, allowing the client device 120 to verify that the trusted component 230 is intact. For example, the processor may be manufactured with a built-in private key using hardware that prevents access to the key. Using this private key, the processor can sign the attestation structure to generate a signed structure. Using the corresponding public key published by the hardware manufacturer, this signature can be verified by the client device 120. This allows the client device 120 to assure that the enclave on the remote device (e.g., FaaS server 110A) was actually created without tampering.

[0029] Both the gateway function 220 and the trusted component 230 can access and modify the shared memory 260, but only the trusted component 230 can access and modify the private memory 270. Figure 2 shows only one trusted component 230 and only one private memory 270, but each tenant may have multiple trusted components 230, each with its own corresponding private memory 27. Furthermore, multiple applications may run in separate memory spaces, and therefore in separate shared memory 260s. In this context, “shared” means that the memory is accessible by all software and hardware that have access to the memory space (e.g., applications and their operating systems), but not necessarily by all applications running on the system.

[0030] The tenant's proxy certificate 250 can verify the integrity of one or more trusted components 230 for the tenant. Therefore, by communicating with a single proxy certificate 250, the tenant's client device 120 can verify any number of trusted components 230 using a single gateway function 220 before calling the functions of those components.

[0031] Mutual certification between enclaves (for example, between a proxy certificater 250 and each of one or more trusted components 230 in the same tenant, or between two trusted components 230) can be enabled by having each enclave maintain a list of measurement hashes (e.g., MRENCLAVE values ​​provided by Intel® SGX) of the enclaves it certifies. The measurement hashes may be stored in a manifest, and the hash values ​​of the manifest are loaded when the enclave is created, thereby securing the measurement hashes that the enclave trusts. Thus, after requesting the measurement hash of another enclave from a secure processor (e.g., using Intel® SGX or TDX), the requested hash can be compared to the stored hash to confirm that the other enclave is one of the trusted enclaves without the use of a third-party certificate verifier. Therefore, as long as the proxy certificate 250 is trusted by the tenant and can prove to other enclaves running on the FaaS server, the tenant can prove that all of the enclaves are secure.

[0032] Figure 3 is a block diagram 300 of a conventional ring-based memory protection system. Block diagram 300 includes applications 310 and 320, and an operating system 330. The operating system 330 executes processor commands at ring 0 (Intel® and AMD® processors), exception level 1 (ARM® processor), or an equivalent privilege level. Applications 310-320 execute processor commands at ring 3 (Intel® and AMD® processors), exception level 0 (ARM® processor), or an equivalent privilege level.

[0033] The hardware processor prevents code running at a lower privilege level from accessing memory outside the memory range defined by the operating system. Therefore, the code of application 310 cannot directly access the memory of operating system 330 or application 320 (as indicated by "X" in Figure 3). Operating system 330 exposes certain functions to applications 310-320 by predefining specific access points (e.g., by call gates, SYSENTER / SYSEXIT instructions in Intel® processors, SYSCALL / SYSRET instructions in AMD® processors, or any appropriate combination or equivalent thereof).

[0034] Because the operating system 330 has access to all of the memory, applications 310 and 320 have no protection from a malicious operating system. For example, a competitor could modify the operating system before running application 310, gain access to the code and data of application 310, and enable reverse engineering.

[0035] Furthermore, if an application can exploit a vulnerability in operating system 330 and elevate itself to the operating system's privilege level, this application can access all of the memory. For example, application 310 normally cannot access application 320's memory (as indicated by the X between applications 310 and 320 in Figure 3), but after elevating itself to ring 0 or exception level 1, it can access application 320's memory. Therefore, if a user is tricked into running a malicious program (e.g., application 310), private data of the user or application provider may be accessed directly from memory (e.g., banking passwords used by application 320).

[0036] Figure 4 is a block diagram 400 of an enclave-based memory protection suitable for reducing TEE latency, according to several exemplary embodiments. Block diagram 400 includes an application 410, an enclave 420, and an operating system 430. The operating system 430 executes processor commands at ring 0 (Intel® and AMD® processors), exception level 1 (ARM® processor), or an equivalent privilege level. The application 410 and enclave 420 execute processor commands at ring 3 (Intel® and AMD® processors), exception level 0 (ARM® processor), or an equivalent privilege level.

[0037] The operating system 430 allocates memory for the enclave 420 and instructs the processor to load the code and data into the enclave 420. However, once instantiated, the operating system 430 has no further access to the memory of the enclave 420. Therefore, even if the operating system 430 is malicious or compromised, the code and data in the enclave 420 remain secure.

[0038] Enclave 420 can provide functionality to application 410. The operating system 430 can control whether application 410 is permitted to invoke the functionality of enclave 420 (for example, by using the ECALL instruction). Therefore, a malicious application could potentially gain the ability to invoke the functionality of enclave 420 by compromising the operating system 430. Nevertheless, the hardware processor prevents the malicious application from directly accessing the memory or code of enclave 420. Thus, the code within enclave 420 cannot assume that its functionality is being invoked correctly or by a non-attacker, but the code within enclave 420 has complete control over parameter checks and other internal security measures and is only exposed to its own internal security vulnerabilities.

[0039] Figure 5 is a block diagram of a database schema 500 suitable for use in scalable certification of TEE, according to several exemplary embodiments. The database schema 500 includes a certification table 510 and a remote function table 540. The certification table 510 includes rows 530A, 530B, and 530C in format 520. The certification table 510 can be used by a delegated certifier 250, client devices 120A-120B, or any suitable combination thereof. The remote function table 540 includes rows 560A, 560B, and 560C in format 550. The remote function table 540 can be used by client devices 120A-120B.

[0040] The format 520 of the certification table 510 includes an enclave identifier field and a status field. Each of rows 530A to 530C stores data for one enclave. The enclave identifier is a unique identifier for the enclave. For example, when an enclave is created, the trusted domain module 240 may assign the following unused identifier to the created enclave. The status field indicates the status of the enclave, such as attested, unattested, or not owned by a certification tenant.

[0041] Therefore, in the example in Figure 5, the certification table 510 shows three enclaves. One of the enclaves is certified, one is not certified, and one is not owned. Thus, when the certification table 510 is integrated into the proxy certificater 250, a status request from the client device 120A may be responded with an indicator that only enclave 0 is certified. As a result, the client device 120A can only authorize calls to the FaaS server 110A for the functions associated with enclave 0. Alternatively, the proxy certificater 250 may respond to the request by attempting to certify the uncertified enclave (e.g., enclave 1 in row 530B) before providing the result to the client device 120A.

[0042] In an embodiment where the certification table 510 is stored on the client device 120, an application running on each client device 120 may check the status field of the enclave corresponding to the function before calling the function using the FaaS server 110A. Thus, uncertified functions are not called, and tenant data is not exposed to the function. Lazy attestation may be performed so that the TEE of a function is certified only in response to a certification request on the client device.

[0043] Alternatively, or furthermore, each client device 120 may use a remote function table 540. The format 550 of the remote function table 540 includes a function name, a server identifier, and a status field. Each of rows 560A to 560C stores data for a single function. The function name is a unique identifier for the function. The server identifier identifies the server that performs the function. In the example in Figure 5, server 10.0.0.1 performs the DSP and FOLD functions, and server 10.0.0.2 performs the ENCRYPT function. In the example in Figure 5, the server identifier is an Internet Protocol (IP) address, but other identifiers may be used. The status field indicates the status of the enclave containing the function, such as certified or uncertified.

[0044] Figure 6 is a block diagram 600 of the communication links between functions and devices, suitable for use in scalable certification of TEE, according to several exemplary embodiments. As shown in Figure 6, FaaS110A provides a gateway 610, functions 620A, 620B, 620C, and 620D, and delegated certificate clients 630A and 630B. Referring to Figure 2, gateway 610 corresponds to gateway function 220, functions 620A-620D correspond to four trusted components 230, and delegated certificate clients 630A-630D correspond to two delegated certificates 250.

[0045] Client devices 120A and 120B from two different tenants contact FaaS 110A via two interfaces: a gateway 610 and a delegate certificate client 630A or 630B corresponding to the tenant. FaaS server 110A provides functions 620A, 620B, 620C, and 620D, each in a separate TEE. In this example, delegate certificate client 630A certifies the TEE for functions 620A and 620B, including code provided by the tenant associated with client device 120A for execution on FaaS server 110A. Similarly, delegate certificate client 630B certifies the TEE for functions 620C and 620D, including code provided by the tenant associated with client device 120B for execution on FaaS server 110A. The proxy certificate client 630A cannot certify the TEE for functions 620C and 620D because the proxy certificate client 630A was not provided by the same tenant that provided the code for functions 620C and 620D. Because these were provided by different tenants, the secret security information used by functions 620C-620D is not available to proxy certificate client 630A. Therefore, the addition of proxy certificate clients 630A-630B does not compromise the inter-tenant security provided by the use of TEE.

[0046] After proving functions 620A and 620B using the delegated certificate client 630A, the client device 120A uses the gateway 610 to call one of functions 620A or 620B, ensuring that the correct function is being invoked in a secure environment. This process may be repeated for any number of clients of any number of tenants, each tenant having any number of protected functions 620A-620D, but using only one delegated certificate client 630A-630B per tenant. As a result, the scalability of the FaaS server 110A is improved compared to a system that provides remote certification for each TEE without a delegated certificate client, and the security of the FaaS server 110A is improved compared to a system that does not allow remote certification for each TEE.

[0047] Figure 7 is a flowchart illustrating the operation of Method 700, suitable for server execution when providing scalable proof of TEE, in several exemplary embodiments. Method 700 includes operations 710, 720, 730, and 740. As an example, but not limited to, Method 700 can be executed by the FaaS server 110A in Figure 1, using the modules, databases, and structures shown in Figures 2 to 4.

[0048] In operation 710, the trusted domain module 240 creates a first TEE for the first function, a second TEE for the second function, and a gateway for remote access to the first function. Referring to Figure 4, the first function may be function 420A, the second function may be the proxy certificate client 430A, and the gateway may be gateway 410. In some exemplary embodiments, the proxy certificate client 430A is verified by the client device 120A by requesting and verifying the certificate data of the proxy certificate client 430A itself. Once the certificate of the certificate client 430A is complete, the client device 120A can provide the proxy certificate client 430A with an encryption key to be used by the proxy certificate client 430A for further communication with the client device 120A.

[0049] In some exemplary embodiments, the gateway 410 is verified by the client device 120A requesting and verifying proof data for the gateway 410 itself. In other exemplary embodiments, the gateway 410 is not verified by the client device 120A.

[0050] Creating a TEE may include the step of processing a request that includes a pre-calculated hash value for the TEE and points to a portion of shared memory 260 containing the code and data for the TEE (e.g., the portion identified by the address and size included in the request). The trusted domain module 240 can perform a hash function on the binary memory state (e.g., the portion of shared memory 260 indicated in the request) to verify that the hash value provided in the request matches the calculated hash value. If the hash values ​​match, the trusted domain module 240 has verified that the indicated memory actually contains the code and data for the requested TEE. If the hash values ​​do not match, the trusted domain module 240 can return an error value and prevent the modified memory from being loaded into the enclave.

[0051] The FaaS server 110A receives a request to verify the integrity of the second TEE via the network 130 (operation 720). For example, a remote function call to the first function may be made. As a further example, a proxy certificate client 430A may be called to verify the integrity of the TEE, including function 420A.

[0052] In operation 730, the FaaS server 110A performs a first function to generate proof data for the second TEE. For example, the measurement of the second TEE may be accessed by the first function and signed using a key exchanged between the first function and the client device 120A before receiving the first function call in operation 720.

[0053] The data and code for the TEE may include a self-signed certificate from the TEE's creator. This self-signed certificate allows the trusted domain module 240 to verify that the data and code loaded into the TEE have not been modified since they were signed. The signed data includes the creator's identifier. Therefore, the certification data for the second TEE indicates both that the TEE has not been modified since signing and the creator's identifier. The validity of the TEE is verified if the creator is the tenant associated with client device 120A. For further protection, the certification data for the second TEE may be generated within the second TEE and exported to the first function. The certification data may be a structure containing the second TEE's identity, one or more attributes of the second TEE, a message authentication code (MAC), or any appropriate combination thereof. This structure may be signed using a temporary private key.

[0054] The memory space of the TEE can be encrypted using the ciphertext stealing (XTS) mode of the Advanced Encryption Standard (AES) in Xor-encrypt-xor (XEX) based Tweaked-codebook mode, which uses a temporary 128-bit memory encryption key. Furthermore, cryptographic integrity protection may be provided using a MAC based on Secure Hash Algorithm 3 (SHA-3). The MAC is the part of the information used to identify the message. The MAC protects the data integrity of the message by enabling verification that can detect any changes to the message content.

[0055] The first function, in operation 740, is to provide certification data over the network. Continuing this example, client device 120A receives the signed certification data, verifies that the data was signed by an already certified delegated certificate client 430A, and verifies that the certification data correctly identifies the second TEE.

[0056] Alternatively, the first function may verify the signed structure and provide the client device with an indicator of whether the proof was successful or unsuccessful, rather than providing the proof data itself. Verifying the proof data may include verifying the signature of the proof data using a temporary public key corresponding to the temporary private key used for signing.

[0057] Once the verification of the second TEE is complete, the client device 120A can securely invoke the second function of the second TEE via the gateway. Invoking the second function of the second TEE may include providing parameters to the second function, generating a return value, and providing the return value to the client device 120A via the network 130.

[0058] In some exemplary embodiments, a second function requests access to data from a first TEE. For example, a client device 120A can provide configuration data to the first TEE via a direct connection as shown in Figure 4, and function 420A can access that data and reduce the number of parameters communicated via the gateway 410. The first TEE determines whether the second TEE has been validated, and only if the second TEE has been validated can it share the requested data. This ensures that tenant data is not shared with unvalidated functions.

[0059] Data may be passed between TEEs by encrypting the data in one TEE using a temporary key and providing access to the encrypted data and temporary key to another TEE. Hardware protection can prevent the temporary key from being used from unprotected memory (e.g., code running outside the TEE).

[0060] Figure 8 is a flowchart illustrating the operation of Method 800, suitable for client execution when utilizing TEE's scalable proof, in several exemplary embodiments. Method 800 includes operations 810, 820, and 830. Example, but not limited, Method 800 can be executed by client device 120A in Figure 1 using the modules, database, and structure shown in Figures 2-4.

[0061] In operation 810, a client device (e.g., client device 120A) verifies the integrity of the first TEE on the remote server (e.g., FaaS server 110A). For example, client device 120A may request signed certificate data from proxy certification client 430A. Proxy certification client 430A generates the certificate data from within the TEE, and the certificate data is signed with a hardware-protected key accessible only from within the TEE. Client device 120A receives the signed certificate data, verifies the signature using client device 120A's trusted domain module 240, and verifies this certificate data against a local copy of the certificate data generated before the TEE's code and data were provided to the remote server.

[0062] In operation 820, the client device verifies the integrity of the second TEE on the remote server by making a first remote function call to the first function of the first TEE. For example, client device 120A can call proxy certification client 430A to verify the integrity of the TEE, including function 420A. Proxy certification client 430A performs local certification of the second TEE and sends a secure confirmation to client device 120A that the TEE of function 420A has been certified.

[0063] In some exemplary embodiments, the first remote function call includes data from the client device 120A for the second TEE to be verified. In these exemplary embodiments, the proxy verification client 430A compares the verification data received from the client device 120A with the verification data received locally for the second TEE. If the two sets of verification data match, a verification response is provided to the client device 120A. Otherwise, the proxy verification client 430A indicates that the second TEE could not be verified.

[0064] In other exemplary embodiments, the TEE of the proxy certification client 430A includes proof data for a second TEE when the proxy certification client 430A is deployed. In these exemplary embodiments, the proxy certification client 430A compares the stored proof data with proof data locally received for the second TEE to determine whether to send a verification response or to send an indicator that the second TEE could not be verified.

[0065] In operation 830, based on the verification provided by the first function, the client device makes a second remote function call to the first function of the second TEE. For example, if the proxy certification client 430A verifies the second TEE, the client device 120A can invoke the verified function 420A. Invocation of the verified function 420A may be direct, as is the invocation of the proxy certification client 430A, or it may be indirect, utilizing the gateway 410.

[0066] Therefore, by using method 800, the client device 120A can verify any number of functions in any number of TEEs on the FaaS server 110A simply by directly calling the proxy certification client 430A, reducing the complexity of the verification process on both the client and the server, and reducing network traffic and associated overhead.

[0067] Figure 9 is a flowchart illustrating the operation of Method 900, suitable for client execution when utilizing TEE's scalable proof, in several exemplary embodiments. Method 900 includes operations 910, 920, 930, 940, and 950. As an example, but not limited to, Method 900 can be executed by client device 120A in Figure 1 using the modules, databases, and structures shown in Figures 2-4.

[0068] In operation 910, the client device (e.g., client device 120A) determines whether the TEE of the function has been verified on the remote server (e.g., FaaS server 110A). For example, the remote function table 340 in Figure 3 may be queried to determine if an entry for the function exists and if the function has been verified.

[0069] If TEE is proven, the client device invokes the function on the remote server (operation 920). Referring to row 360A of the remote function table 340, the client device verifies in operation 910 that the DSP function is proven, and in operation 920 invokes the DSP function on server 10.0.0.1.

[0070] However, if the TEE is not proven, the client device requests proof from the remote server in operation 930. As discussed with respect to method 800 and block diagram 600, this can be done by making remote function calls to different functions in different TEEs on the remote server.

[0071] In operation 940, the client device checks the result of the requested proof. If the proof is successful, local data indicating whether the function has been proven is updated (for example, by adding a row to the proof table 310 or updating an existing row in the remote function table 340), and the remote function is invoked (operation 920).

[0072] If the proof is unsuccessful, a local version of the function is invoked (operation 950). In some exemplary embodiments, the computing power of the remote server is greater than that of the client device, and therefore, it is preferable to use the remote server when a secure function is available. However, by enabling the function to be invoked locally, applications utilizing the function can continue even if the remote server is unable to provide the function.

[0073] Therefore, by using method 900, the client device 120A can verify any number of functions in any number of TEEs on the FaaS server 110A simply by directly calling the proxy certification client 430A, reducing the complexity of the verification process on both the client and the server, and reducing network traffic and associated overhead. Furthermore, when a function is not available remotely or is insecure, the function can be invoked locally, enabling greater reliability.

[0074] In consideration of the implementation of the subject matter described above, this application discloses the following list of examples. A single feature of an example, or two or more features of an example obtained in combination and in combination with one or more features of optionally one or more further examples, are further examples that similarly fall within the scope of the disclosure of this application.

[0075] Example 1 is a system that provides remote certification of a trusted execution environment (TEE), the system comprising at least one processor, a network interface operationally coupled to the processor, and memory coupled to the at least one processor for storing instructions that, when executed by the processor, cause the at least one processor to perform an operation, the operation comprising creating a first TEE for a first function, creating a second TEE for a second function, providing a gateway for remote access to the first function, receiving requests from a client device and via the network interface to verify the integrity of the second TEE, executing the first function in response to the request to generate certification data for the second TEE, and providing the certification data to the client device via the network interface.

[0076] In Example 2, the subject matter of Example 1 includes the generation of the proof data of the second TEE, which includes generating a signed structure from within the second TEE that includes the identity of the second TEE, the attributes of the second TEE, and a message authentication code (MAC), the structure being signed using a temporary private key, and verifying the signed structure using the first function of the first TEE.

[0077] In Example 3, the subject matter of Examples 1 and 2 further includes the operation of receiving a function call at the gateway from the client device and via the network interface, the function call being associated with the second function, and in response to the function call, executing the second function and generating a return value, and providing the return value to the client device via the network interface.

[0078] In Example 4, the subject matter of Example 3 further includes the operation, in response to the function call, requesting access to the data of the first TEE by the second function.

[0079] In Example 5, the subject matter of Example 4 further includes determining that the second function has been verified by the first function, and providing the requested access to the data based on the determination that the second function has been verified, in response to a request by the second function for access to the data of the first TEE.

[0080] In Example 6, the subject matter of Example 5 includes that providing the requested access to the data includes encrypting the data using a temporary key and providing the second function with access to the temporary key.

[0081] In Example 7, the subject matter of Examples 1-6 further includes the operation receiving a second request to verify the integrity of the first TEE before receiving the request to verify the integrity of the second TEE.

[0082] In Example 8, the subject matter of Examples 1-7 includes the fact that the gateway is not verified by the client device.

[0083] In Example 9, the subject matter of Examples 1-8 includes the fact that the gateway provides remote access to the third function of the third TEE, and the first function cannot verify the integrity of the third TEE.

[0084] In Example 10, the subject matter of Example 9 further includes the operation of creating a fourth TEE for a fourth function and receiving a second function call to the fourth function from a second client device and via the network interface, wherein the second function call verifies the integrity of the third TEE.

[0085] Example 11 is a method for providing remote certification of a trusted execution environment (TEE), the method comprising: a processor creating a first trusted execution environment (TEE) for a first function; the processor creating a second TEE for a second function; the processor providing a gateway for remote access to the first function; receiving a request from a client device and via a network interface to verify the integrity of the second TEE; in response to the request, the processor performing the first function to generate certification data for the second TEE; and providing the certification data to the client device via the network interface.

[0086] In Example 12, the subject matter of Example 11 includes the generation of the proof data of the second function, which includes generating a signed structure from within the second TEE that includes the identity of the second TEE, the attributes of the second TEE, and a message authentication code (MAC), the structure being signed using a temporary private key, and the processor verifying the signed structure using the first function of the first TEE.

[0087] In Example 13, the subject matter of Examples 11-12 is the gateway receiving a function call from the client device and via the network interface, the function call being associated with the second function, the steps include: having the processor perform the second function in response to the function call and generate a return value; and providing the return value to the client device via the network interface.

[0088] In Example 14, the subject matter of Example 13 includes the step of requesting the second function to access the data of the first TEE in response to the function call.

[0089] In Example 15, the subject matter of Example 14 includes the steps of determining that the second function has been verified by the first function, and providing the requested access to the data of the first TEE in response to a request for access to the data of the first TEE by the second function, based on the determination that the second function has been verified.

[0090] In Example 16, the subject matter of Example 15 includes that providing the requested access to the data includes encrypting the data using a temporary key and providing the second function with access to the temporary key.

[0091] In Example 17, the subject matter of Examples 11-16 includes the step of receiving a second request to verify the integrity of the first TEE before receiving the request to verify the integrity of the second TEE.

[0092] In Example 18, the subject matter of Examples 11-17 includes the fact that the gateway is not verified by the client device.

[0093] In Example 19, the subject matter of Examples 11-18 includes the fact that the gateway provides remote access to the third function of the third TEE, and the first function cannot verify the integrity of the third TEE.

[0094] In Example 20, the subject matter of Example 19 includes the steps of: the processor creating a fourth TEE for a fourth function; and receiving a second function call to the fourth function from a second client device and via the network interface, wherein the second function call verifies the integrity of the third TEE.

[0095] Example 21 is a non-temporary computer-readable medium having instructions that cause at least one processor to provide remote proof of a trusted execution environment (TEE) by performing an operation, the operation including creating a first trusted execution environment (TEE) for a first function, creating a second TEE for a second function, providing a gateway for remote access to the first function, receiving a request from a client device and via a network interface to verify the integrity of the second TEE, performing the first function in response to the request to generate proof data for the second TEE, and providing the proof data to the client device via the network interface.

[0096] In Example 22, the subject matter of Example 21 includes the generation of the proof data of the second function, which includes generating a signed structure from within the second TEE, which includes the identity of the second TEE, the attributes of the second TEE, and a message authentication code (MAC), the structure being signed using a temporary private key, and verifying the signed structure using the first function of the first TEE.

[0097] In Example 23, the subject matter of Examples 21-22 further includes the operation of receiving a function call at the gateway from the client device and via the network interface, the function call being associated with the second function, and in response to the function call, executing the second function and generating a return value, and providing the return value to the client device via the network interface.

[0098] In Example 24, the subject matter of Example 23 further includes the operation, in response to the function call, requesting the second function to access the data of the first TEE.

[0099] In Example 25, the subject matter of Example 24 further includes determining that the second function has been verified by the first function, and providing the requested access to the data based on the determination that the second function has been verified, in response to a request by the second function for access to the data of the first TEE.

[0100] In Example 26, the subject matter of Example 25 includes that providing the requested access to the data includes encrypting the data using a temporary key and providing the second function with access to the temporary key.

[0101] In Example 27, the subject matter of Examples 21-26 further includes receiving a second request to verify the integrity of the first function before receiving the request to verify the integrity of the second function.

[0102] In Example 28, the subject matter of Examples 21-27 includes the fact that the gateway is not verified by the client device.

[0103] In Example 29, the subject matter of Examples 21-28 includes the fact that the gateway provides remote access to the third function of the third TEE, and the first function cannot verify the integrity of the third TEE.

[0104] In Example 30, the subject matter of Example 29 further includes the operation of the processor creating a fourth TEE for a fourth function, and receiving a second function call to the fourth function from a second client device and via the network interface, wherein the second function call verifies the integrity of the third TEE.

[0105] Example 31 is a system that provides remote certification of a trusted execution environment (TEE), the system comprising means for storage, network interface means, and processing means, which create a first TEE for a first function, create a second TEE for a second function, provide a gateway for remote access to the first function, receive requests from a client device and via the network interface means to verify the integrity of the second TEE, and in response to such requests, execute the first function to generate certification data for the second TEE, and provide the certification data to the client device via the network interface means.

[0106] In Example 32, the subject matter of Example 31 is that, in order to generate the proof data of the second TEE, the processing means includes generating a signed structure from within the second TEE that includes the identity of the second TEE, the attributes of the second TEE, and a message authentication code (MAC), the structure being signed using a temporary private key, and verifying the signed structure using the first function of the first TEE.

[0107] In Example 33, the subject matter of Examples 31-32 further includes the processing means receiving a function call at the gateway from the client device and via the network interface means, the function call being associated with the second function, the second function being executed in response to the function call to generate a return value, and the return value being provided to the client device via the network interface means.

[0108] In Example 34, the subject matter of Example 33 further includes the processing means responding to the function call by requesting access to the data of the first TEE through the second function.

[0109] In Example 35, the subject matter of Example 34 further includes determining that the second function has been verified by the first function, and providing the requested access to the data based on the determination that the second function has been verified, in response to a request by the second function for access to the data of the first TEE.

[0110] In Example 36, the subject matter of Example 35 includes the processing means encrypting the data using a temporary key and providing the second function with access to the temporary key in order to provide the requested access to the data.

[0111] In Example 37, the subject matter of Examples 31-36 further includes the processing means receiving a second request to verify the integrity of the first TEE before receiving the request to verify the integrity of the second TEE.

[0112] In Example 38, the subject matter of Examples 31-37 includes the fact that the gateway is not verified by the client device.

[0113] In Example 39, the subject matter of Examples 31-38 includes the fact that the gateway provides remote access to the third function of the third TEE, and the first function cannot verify the integrity of the third TEE.

[0114] In Example 40, the subject matter of Example 39 is that the processing means creates a fourth TEE for a fourth function, receives a second function call to the fourth function from a second client device and via the network interface means, the second function call includes verifying the integrity of the third TEE.

[0115] Example 41 is at least one machine-readable medium that, when executed by a processing circuit, includes an instruction causing the processing circuit to perform an operation that performs one of the operations in Examples 1 to 40.

[0116] Example 42 is an apparatus that includes means for carrying out any of Examples 1 to 40.

[0117] Example 43 is a system for implementing any of Examples 1 through 40.

[0118] Example 44 is a method for carrying out any of Examples 1 through 40.

[0119] Figure 10 is a block diagram 1000 showing an example of a software architecture 1002 for a computing device. Architecture 1002 can be used in combination with various hardware architectures, such as those described herein. Figure 10 is merely a non-limiting example of a software architecture, and many other architectures may be implemented to facilitate the functionality described herein. A typical hardware layer 1004 is shown, which can represent, for example, any computing device referenced above. In some examples, the hardware layer 1004 may be implemented according to the architecture of the computer system in Figure 10.

[0120] A typical hardware layer 1004 includes one or more processing units 1006 having associated executable instructions 1008. The executable instructions 1008 represent executable instructions of the software architecture 1002, including implementations such as methods, modules, subsystems, and components described herein, and may further include memory and / or storage modules 1010 having similar executable instructions 1008. The hardware layer 1004 may also include other hardware, such as other hardware represented by other hardware 1012, which represents any other hardware of the hardware layer 1004, such as other hardware shown as part of the software architecture 1002.

[0121] In the exemplary architecture of Figure 10, the software architecture 1002 can be conceptualized as a stack of layers, each providing specific functionality. For example, the software architecture 1002 may include layers such as the operating system 1014, libraries 1016, framework / middleware 1018, application 1020, and presentation layer 1044. Operationally, application 1020 and / or other components within the layer can invoke application programming interface (API) calls 1024 through the software stack and access responses, return values, etc., indicated as messages 1026 in response to the API calls 1024. The illustrated layers are essentially representative, and not all software architectures have all of them. For example, some mobile or dedicated operating systems may not provide framework / middleware 1018, while others may provide such a layer. Other software architectures may include further or different layers.

[0122] The operating system 1014 can manage hardware resources and provide common services. The operating system 1014 may include, for example, a kernel 1028, a service 1030, and a driver 1032. The kernel 1028 can function as an abstraction layer between the hardware layer and other software layers. For example, the kernel 1028 may be responsible for memory management, processor management (e.g., scheduling), component management, networking, and security settings. The service 1030 can provide other common services to other software layers. In some examples, the service 1030 includes an interrupt service. When an interrupt is accessed, the interrupt service detects the reception of the interrupt and, in response, can cause the architecture 1002 to pause its current processing and execute an interrupt service routine.

[0123] Driver 1032 may be responsible for controlling or interfaceing with the underlying hardware. For example, depending on the hardware configuration, driver 1032 may include a display driver, camera driver, Bluetooth® driver, flash memory driver, serial communication driver (e.g., Universal Serial Bus (USB) driver), Wi-Fi® driver, NFC driver, audio driver, power management driver, etc.

[0124] Library 1016 can provide a common infrastructure that can be used by application 1020 and / or other components and / or layers. Typically, library 1016 provides functionality that allows other software modules to perform tasks in a more convenient way than directly interface with the functionality of the underlying operating system 1014 (e.g., kernel 1028, services 1030, and / or drivers 1032). Library 1016 may include a system library 1034 (e.g., the C standard library) that can provide functions such as memory allocation, string manipulation, and mathematical functions. Furthermore, library 1016 may include API libraries 1036 such as a media library (e.g., a library that supports the presentation and manipulation of various media formats such as MPEG4, H.264, MP3, AAC, AMR, JPG, PNG), a graphics library (e.g., an OpenGL framework that can be used to render 2D and 3D graphic content on a display), a database library (e.g., SQLite that can provide various relational database functions), and a web library (e.g., WebKit that can provide web browsing functionality). Library 1016 may further include a wide range of other libraries 1038 to provide many other APIs to application 1020 and other software components / modules.

[0125] The framework / middleware 1018 can provide a higher level of common infrastructure that can be utilized by application 1020 and / or other software components / modules. For example, the framework / middleware 1018 may provide various graphical user interface (GUI) functions, high-level resource management, high-level location services, etc. The framework / middleware 1018 may also provide a wide range of other APIs that can be utilized by application 1020 and / or other software components / modules, some of which may be specific to a particular operating system or platform.

[0126] Application 1020 includes built-in applications 1040 and / or third-party applications 1042. Typical examples of built-in applications 1040, but not limited to, include contacts applications, browser applications, book reader applications, location applications, media applications, messaging applications, and / or game applications. Third-party applications 1042 may include any of a wide range of combinations of built-in applications and other applications. In a particular example, third-party applications 1042 (e.g., by an entity other than the vendor of a particular platform, Android) may be included. TM or iOS TM Applications developed using a Software Development Kit (SDK) are for iOS. TM Android TM This may also be mobile software running on a mobile operating system such as Windows® Phone or the operating system of another mobile computing device. In this example, the third-party application 1042 may invoke API calls 1024 provided by the mobile operating system, such as operating system 1014, to facilitate the functionality described herein.

[0127] Application 1020 can create a user interface for interacting with the system's user by utilizing operating system functions (e.g., kernel 1028, services 1030, and / or drivers 1032), libraries (e.g., system library 1034, API library 1036, and other libraries 1038), and framework / middleware 1018. Alternatively, or further, in some systems, user interaction may occur through a presentation layer, such as presentation layer 1044. In these systems, the application / module "logical" can be separated from the application / module aspects that interact with the user.

[0128] Some software architectures utilize virtual machines. In the example in Figure 10, this is represented by virtual machine 1048. A virtual machine creates a software environment in which applications / modules can run as if they were running on a hardware computing device. A virtual machine is hosted by a host operating system (operating system 1014) and typically, though not always, has a virtual machine monitor 1046, which manages the operation of the virtual machine and its interface with the host operating system (i.e., operating system 1014). The software architecture runs within virtual machine 1048, including the operating system 1050, libraries 1052, frameworks / middleware 1054, applications 1056, and / or presentation layer 1058. These layers of the software architecture running within virtual machine 1048 may be the same as or different from the corresponding layers described above.

[0129] Modules, components, and logic In this specification, specific embodiments are described as including logical or multiple components, modules, or mechanisms. A module may constitute either a software module (e.g., code embodied (1) on a non-temporary machine-readable medium, or (2) in a transmitted signal) or a hardware implementation module. A hardware implementation module is a tangible unit capable of performing a specific operation and may be configured or arranged in a specific manner. In exemplary embodiments, one or more computer systems (e.g., standalone, client, or server computer systems) or one or more hardware processors may be configured by software (e.g., an application or application portion) as a hardware implementation module that operates to perform a specific operation described herein.

[0130] In various embodiments, hardware implementation modules can be implemented mechanically or electronically. For example, a hardware implementation module may include dedicated circuitry or logic permanently configured to perform a specific operation (e.g., as a dedicated processor such as a field-programmable gate array (FPGA) or application-specific integrated circuit (ASIC)). A hardware implementation module may also include programmable logic or circuitry temporarily configured by software to perform a specific operation (e.g., as contained within a general-purpose processor or other programmable processor). It will be understood that the decision to implement a hardware implementation module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be determined by cost and time considerations.

[0131] Therefore, the term “hardware implementation module” should be understood to encompass tangible entities that are physically constructed, permanently configured (e.g., hardwired), or provisionally or temporarily configured (e.g., programmed) to operate in a particular manner and / or perform specific operations described herein. Given embodiments in which a hardware implementation module is temporarily configured (e.g., programmed), each hardware implementation module does not need to be configured or instantiated at any single point in time. For example, if a hardware implementation module includes a general-purpose processor configured using software, this general-purpose processor may be configured as different hardware implementation modules at different times. Thus, the software can configure the processor to, for example, configure a particular hardware implementation module at one point in time and different hardware implementation modules at different points in time.

[0132] Hardware implementation modules can provide information to or receive information from other hardware implementation modules. Therefore, the described hardware implementation modules can be considered to be communicatively coupled. When multiple such hardware implementation modules exist simultaneously, communication can be achieved via signal transmission (e.g., through appropriate circuits and buses connecting the hardware implementation modules). In embodiments where multiple hardware implementation modules are configured or instantiated at different times, communication between such hardware implementation modules can be achieved, for example, by storing and retrieving information in a memory structure that multiple hardware implementation modules have access to. For example, one hardware implementation module can perform an operation and store the output of that operation in a memory device with which it is communicatively coupled. A further hardware implementation module can then access this memory device at a later time to retrieve and process the stored output. Hardware implementation modules can also initiate communication with input or output devices and operate on resources (e.g., sets of information).

[0133] Various operations of the exemplary methods described herein may be performed, at least in part, by one or more processors that are configured temporarily (e.g., by software) or permanently to perform the relevant operations. Whether configured temporarily or permanently, such processors can constitute a processor implementation module that operates to perform one or more operations or functions. The modules referenced herein may include processor implementation modules in some exemplary embodiments.

[0134] Similarly, the methods described herein may be performed at least partially by a processor. For example, at least part of the operation of a method may be performed by one or more processors or processor implementation modules. The execution of a particular operation may be distributed among one or more processors and may reside within a single machine as well as be deployed across multiple machines. In some exemplary embodiments, one or more processors may be located in a single location (e.g., in a home environment, office environment, or server farm), while in other embodiments, the processors may be distributed across multiple locations.

[0135] One or more processors may also operate in a “cloud computing” environment or as “software as a service” (SaaS) to support the execution of related operations. For example, at least some of the operations may be performed by a group of computers (as an example of machines containing processors), and these operations may be accessible over a network (e.g., the Internet) and through one or more appropriate interfaces (e.g., APIs).

[0136] Electronic devices and systems Exemplary embodiments may be implemented in digital electronic circuits, or in computer hardware, firmware, or software, or in combination thereof. Exemplary embodiments may be implemented using computer program products, such as computer programs, which are materially embodied in an information carrier, for example, on a machine-readable medium, for execution by or control of a data processing device, such as a programmable processor, a computer, or multiple computers.

[0137] Computer programs can be written in any form of programming language, including compiled or interpretable languages, and can be deployed in any form, including as standalone programs or as modules, subroutines, or other units suitable for use in a computing environment. Computer programs can be deployed to run on a single computer, on multiple computers at a single site, or distributed across multiple sites and interconnected by a communication network.

[0138] In exemplary embodiments, the operation can be performed by one or more programmable processors that execute a computer program to perform a function by acting on input data and generating an output. The operation of the method can also be performed by a dedicated logic circuit, such as an FPGA or ASIC, and the apparatus of the exemplary embodiment may be implemented as a dedicated logic circuit, such as an FPGA or ASIC.

[0139] A computing system can include clients and servers. Clients and servers are generally geographically separated and interact via a communication network. The client-server relationship arises from computer programs running on each computer that have a client-server relationship with one another. In embodiments of deploying a programmable computing system, it will be understood that both hardware and software architectures are worth considering. Specifically, it will be understood that the choice of whether to implement certain functionality in permanently configured hardware (e.g., ASICs), in temporarily configured hardware (e.g., a combination of software and a programmable processor), or in a combination of permanent and temporarily configured hardware, can be a design choice. Below, we present hardware (e.g., machines) and software architectures that can be deployed in various exemplary embodiments.

[0140] Exemplary machine architecture and machine-readable media Figure 11 is a block diagram of a machine in an exemplary form of computer system 1100, on which instructions 1124 can be executed to cause the machine to perform one or more of the methods discussed herein. In alternative embodiments, the machine may operate as a standalone device or be connected to other machines (e.g., networked). In a networked deployment, the machine may operate in a server-client network environment with the capacity of a server or client machine, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), tablet PC, set-top box (STB), personal digital assistant (PDA), cellular telephone, web device, network router, switch, or bridge, or any machine capable of executing instructions (sequential or otherwise) specifying actions to be taken by that machine. Furthermore, although only a single machine is shown, the term “machine” shall also be interpreted to include any set of machines that individually or collectively execute a set (or more sets) of instructions to perform one or more of the methods discussed herein.

[0141] An exemplary computer system 1100 includes a processor 1102 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both), main memory 1104, and static memory 1106, which communicate with each other via a bus 1108. The computer system 1100 may further include a video display unit 1110 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 1100 further includes an alphanumeric input device 1112 (e.g., a keyboard or a touch-sensitive display screen), a user interface (UI) navigation (or cursor control) device 1114 (e.g., a mouse), a storage unit 1116, a signal generation device 1118 (e.g., a speaker), and a network interface device 1120.

[0142] Machine-readable media The storage unit 1116 includes a machine-readable medium 1122 in which one or more sets of data structures and instructions 1124 (e.g., software) that embody or utilize one or more of the methods or functions described herein are stored. The instructions 1124 are further located in the main memory 1104 and / or the processor 1102, all or at least partially, during their execution by the computer system 1100, and the main memory 1104 and the processor 1102 may also constitute the machine-readable medium 1122.

[0143] Although the machine-readable medium 1122 is shown as a single medium in exemplary embodiments, the term “machine-readable medium” may include a single or multiple mediums (e.g., a centralized or distributed database, and / or associated caches and servers) that store one or more instructions 1124 or data structures. The term “machine-readable medium” shall also be understood to include any tangible medium capable of storing, encoding, or carrying instructions 1124 for machine execution and causing a machine to execute one or more of the methods of the Disclosure, or capable of storing, encoding, or carrying data structures utilized by or associated with such instructions 1124. Accordingly, the term “machine-readable medium” shall be understood to include, but are not limited to, solid-state memory, as well as optical and magnetic media. Specific examples of machine-readable media 1122 include semiconductor memory devices, such as erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and non-volatile memory, including, for example, compact disc read-only memory (CD-ROM) and digital multipurpose disc read-only memory (DVD-ROM) disks. Machine-readable media are not transmission media.

[0144] transmission medium Instruction 1124 may further be transmitted or received through a communication network 1126 using a transmission medium. Instruction 1124 can be transmitted using a network interface device 1120 and one of a number of well-known transport protocols (e.g., Hypertext Transport Protocol (HTTP)). Examples of communication networks include local area networks (LANs), wide area networks (WANs), the Internet, mobile telephone networks, plain old telephone (POTS) networks, and wireless data networks (e.g., WiFi and WiMAX networks). The term “transmission medium” is to be understood to include any intangible medium on which instructions 1124 for execution by a machine can be stored, encoded, or carried, including digital or analog communication signals or other intangible mediums to facilitate communication of such software.

[0145] While this specification describes specific exemplary embodiments, it will be apparent that various modifications and changes can be made to these embodiments without departing from the broader spirit and scope of this disclosure. Therefore, the specification and drawings should be interpreted as exemplary, not restrictive. The accompanying drawings, which constitute part of this specification, illustrate, not restrictively, specific embodiments in which the subject matter can be carried out. The exemplary embodiments are described in sufficient detail to enable those skilled in the art to carry out the teachings disclosed herein. Other embodiments may be used and derived from them, thereby making structural and logical substitutions and changes without departing from the scope of this disclosure. Therefore, this detailed description should not be interpreted as restrictive, and the scope of the various embodiments is defined solely by the claims set forth separately and the entire scope of the equivalents to which such claims are entitled.

[0146] Embodiments of such inventive subject matter may be referred to individually and / or collectively in this specification by the term “invention,” not merely for convenience, and without the intention of voluntarily limiting the scope of this application to any one invention or inventive concept if multiple are actually disclosed. Therefore, it should be understood that while certain embodiments are illustrated and described herein, any arrangement calculated to achieve the same objective may substitute for any particular embodiment shown. This disclosure is intended to cover any and all adaptations or variations of any of the various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will become apparent to those skilled in the art who have considered the above description.

[0147] Some parts of the subject matter discussed herein may be presented in terms of algorithms or symbolic representations of operations on data stored as bits or binary digital signals in machine memory (e.g., computer memory). Such algorithms or symbolic representations are examples of techniques used by those skilled in the field of data processing, conveying the substance of their operations to others skilled in the field. As used herein, “algorithm” is a self-consistent sequence of operations or similar processes that lead to a desired result. In this context, algorithms and operations include the physical manipulation of physical quantities. Typically, but not always, such quantities can take the form of electrical, magnetic, or optical signals that can be stored, accessed, transferred, combined, compared, or otherwise manipulated by a machine. Primarily for reasons of common usage, it is sometimes convenient to refer to such signals using words such as “data,” “content,” “bit,” “value,” “element,” “symbol,” “character,” “term,” “number,” and “digit.” However, these words are merely convenient labels and should be associated with appropriate physical quantities.

[0148] Unless otherwise specifically indicated, discussions using terms such as “processing,” “calculating,” “calculating,” “determining,” “presenting,” and “displaying” in this specification may refer to actions or processes of a machine (e.g., a computer) that manipulates or transforms data represented as a physical (e.g., electronic, magnetic, or optical) quantity within one or more memories (e.g., volatile memory, non-volatile memory, or any suitable combination thereof), registers, or other machine components that receive, store, transmit, or display information. Furthermore, unless otherwise specifically indicated, the terms “one” ("a" and "an") are used in this specification to include one or more instances, as is common in patent literature. Finally, when used in this specification, the conjunction “or” means non-exclusive “or” unless otherwise specifically indicated.

Claims

1. A system that provides remote certification for trusted execution environments (TEEs), At least one processor, A network interface operationally coupled to the aforementioned processor, The system includes a memory coupled to the at least one processor for storing instructions that, when executed by the processor, cause the at least one processor to perform an operation, and the operation is To create a first TEE for the first function, To create a second TEE for the second function, To provide a gateway for remote access to the first function, The communication module receives a request from a client device and via the network interface to verify the integrity of the second TEE, In response to the above request, The first function is performed to generate the proof data for the second TEE, The aforementioned certification data is provided to the client device via the network interface, A system that includes this.

2. The generation of the proof data for the second TEE is as follows: The process involves generating a signed structure from within the second TEE, which includes the identity of the second TEE, the attributes of the second TEE, and a message authentication code (MAC), and the structure is signed using a temporary private key. Verifying the signed structure using the first function of the first TEE, The system according to claim 1, including the following:

3. The aforementioned operation is, The gateway receives function calls from the client device and via the network interface, and the function calls are associated with the second function. In response to the aforementioned function call, The second function described above is performed to generate a return value, The return value is provided to the client device via the network interface, The system according to claim 1 or claim 2, further comprising:

4. The aforementioned operation is, In response to the aforementioned function call, the second function requests access to the data of the first TEE. The system according to claim 3, further comprising:

5. The aforementioned operation is, The first function determines that the second function has been verified, In response to a request for access to the data of the first TEE by the second function, the second function provides the requested access to the data based on the determination that it has been verified. The system according to claim 4, further comprising:

6. Providing the requested access to the aforementioned data is, Encrypting the aforementioned data using a temporary key, The second function is to provide access to the temporary key, The system according to claim 5, including the system described in claim 5.

7. The aforementioned operation is, Receiving a second request to verify the integrity of the first TEE before receiving the request to verify the integrity of the second TEE. The system according to any one of claims 1 to 6, further comprising:

8. The system according to any one of claims 1 to 7, wherein the gateway is not verified by the client device.

9. The gateway provides remote access to the third function of the third TEE, The first function cannot verify the integrity of the third TEE. The system according to any one of claims 1 to 8.

10. The aforementioned operation is, To create a fourth TEE for the fourth function, The second function call to the fourth function is received from a second client device and via the network interface, the second function call verifies the integrity of the third TEE, The system according to claim 9, further comprising:

11. A method for providing remote certification of a trusted execution environment (TEE), The processor creates a first trusted execution environment (TEE) for a first function, The processor provides a second TEE for a second function, The processor provides a gateway for remote access to the first function, The steps include receiving a request from a client device and via a network interface for a communication module to verify the integrity of the second TEE, In response to the above request, The processor performs the first function to generate proof data for the second TEE, The steps include providing the aforementioned certification data to the client device via the network interface, A method that includes this.

12. The generation of the proof data for the second function is The process involves generating a signed structure from within the second TEE, which includes the identity of the second TEE, the attributes of the second TEE, and a message authentication code (MAC), and the structure is signed using a temporary private key. The processor verifies the signed structure using the first function of the first TEE, The method according to claim 11, including the method described in claim 11.

13. The steps include: receiving a function call at the gateway from the client device and via the network interface, wherein the function call is associated with the second function; In response to the aforementioned function call, The processor performs the second function and generates a return value, The steps include providing the return value to the client device via the network interface, The method according to claim 11 or claim 12, further comprising:

14. In response to the aforementioned function call, the second function requests access to the data of the first TEE. The method according to claim 13, further comprising:

15. The first step is to determine that the second function has been verified by the first function, In response to a request for access to the data of the first TEE by the second function, the second function provides the requested access to the data based on the determination that it has been verified. The method according to claim 14, further comprising:

16. Providing the requested access to the aforementioned data is, Encrypting the aforementioned data using a temporary key, The second function is to provide access to the temporary key, The method according to claim 15, including the method described in claim 15.

17. The step of receiving a second request to verify the integrity of the first TEE before receiving the request to verify the integrity of the second TEE. The method according to any one of claims 11 to 16, further comprising:

18. The method according to any one of claims 11 to 17, wherein the gateway is not verified by the client device.

19. The gateway provides remote access to the third function of the third TEE, The first function cannot verify the integrity of the third TEE. The method according to any one of claims 11 to 18.

20. The processor provides a fourth TEE for a fourth function, The steps include receiving a second function call to the fourth function from a second client device and via the network interface, wherein the second function call verifies the integrity of the third TEE, The method according to claim 19, further comprising:

21. A computer program that causes at least one processor to provide remote proof of a trusted execution environment (TEE) by performing an operation, wherein the operation is: To create a first trusted execution environment (TEE) for the first function, To create a second TEE for the second function, To provide a gateway for remote access to the first function, The communication module receives requests from client devices and via the network interface to verify the integrity of the second TEE, In response to the above request, The first function is performed to generate the proof data for the second TEE, The aforementioned certification data is provided to the client device via the network interface, A computer program that includes [this].

22. The generation of the proof data for the second function is The process involves generating a signed structure from within the second TEE, which includes the identity of the second TEE, the attributes of the second TEE, and a message authentication code (MAC), and the structure is signed using a temporary private key. Verifying the signed structure using the first function of the first TEE, The computer program according to claim 21, including the computer program described in claim 21.

23. The aforementioned operation is, The gateway receives function calls from the client device and via the network interface, and the function calls are associated with the second function. In response to the aforementioned function call, The second function described above is performed to generate a return value, The return value is provided to the client device via the network interface, The computer program according to claim 21 or claim 22, further comprising:

24. A system that provides remote certification for trusted execution environments (TEEs), A means of memory, Network interface means, It is a processing means, Create a first TEE for the first function, Create a second TEE for the second function, A gateway is provided for remote access to the first function described above. The communication module receives a request from the client device and via the network interface means to verify the integrity of the second TEE. In response to the above request, The first function is performed to generate the proof data for the second TEE, The aforementioned certification data is provided to the client device via the network interface means. Processing means and A system that includes this.

25. In order to generate the proof data of the second TEE, the processing means, From within the second TEE, a signed structure is generated that includes the identity of the second TEE, the attributes of the second TEE, and a message authentication code (MAC), and the structure is signed using a temporary private key. The signed structure is verified using the first function of the first TEE. The system according to claim 24.

26. A computer-readable storage medium storing a computer program according to any one of claims 21 to 23.

Images