Scaled Trusted Execution Environment for Application Services

Abstract

Various aspects of the subject technology relate to systems, methods, and machine-readable media for providing an application trusted execution environment. Various aspects may include performing attestation of each application enclave of multiple application enclaves for multiple applications. Aspects may also include receiving a request from a client. Aspects may also include selecting a load balancer for forwarding the request to the application enclave. Aspects may also include determining a sensitivity level of the request associated with secured environment parameters. Aspects may include routing, by an enclave server of the load balancer, the request to the application enclave according to the sensitivity level for execution of the multiple applications in the application trusted execution environment.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This disclosure is related to and claims priority under 35 U.S.C. §119(e) to U.S. Provisional Patent Application No. 63 / 405,325 by Michael Kaplan et al., entitled SCALED TRUSTED EXECUTION ENVIRONMENT FOR APPLICATION SERVICES, filed September 9, 2022, the contents of which are incorporated herein by reference in their entirety for all purposes.

[0002] The present disclosure relates generally to trusted execution environments implemented for web services such as microservices, and more particularly to scaled trusted execution environments for web services (e.g., internet-based microservices). [Background technology]

[0003] Current trusted execution environments involve isolating or separating computer memory (e.g., enclaves) to protect sensitive or confidential application data. For example, application source code or production code can be executed in a trusted portion of computer memory, such as a special encrypted memory area with restricted access. In this way, security guarantees or assurances can be provided for such code or applications executing in enclaves, including protecting private user information, ensuring correct execution of source code, and increasing privacy and security for services such as transaction processing, consensus, smart contracts, and key storage. However, enclave-based execution of microservices can lead to bottlenecks and delays when demand for network traffic through a particular node is high. Furthermore, the ad hoc nature of handling different microservices in a compartmentalized manner hinders network capacity utilization and scaling (e.g., incorporating new services, domains, and user segments). In many cases, trusted-based application execution is typically limited to the throughput of a single machine, limiting the feasible applications that can be built. Summary of the Invention

[0004] According to one embodiment, a computer-implemented method for providing an application trusted execution environment is provided. The method includes performing attestation of each application enclave of a plurality of application enclaves for a plurality of applications. The method also includes receiving a request from a client. The method also includes selecting a load balancer of a plurality of load balancers to forward the request to the plurality of application enclaves. The method also includes determining a sensitivity level of the request associated with secured environment parameters. The method also includes routing, by an enclave server of the load balancer, the request from the load balancer to an application enclave of the plurality of application enclaves according to the sensitivity level for execution of the application of the plurality of applications in the application trusted execution environment.

[0005] According to one embodiment, a system is provided that includes a processor and a memory containing instructions recorded thereon, which, when executed by the processor, cause the processor to perform a method for providing an application trusted execution environment. The method includes performing attestation of each application enclave of a plurality of application enclaves for a plurality of applications. The method also includes receiving a request from a client. The method also includes selecting a load balancer of a plurality of load balancers to forward the request to the plurality of application enclaves. The method also includes determining a sensitivity level of the request associated with secured environment parameters. The method also includes routing, by an enclave server of the load balancer, the request from the load balancer to an application enclave of the plurality of application enclaves according to a sensitivity level for execution of the application of the plurality of applications in the application trusted execution environment.

[0006] According to one embodiment, a non-transitory computer-readable storage medium is provided that includes instructions (e.g., a stored sequence of instructions) that, when executed by a processor, cause the processor to perform a method for providing an application trusted execution environment. The method includes performing attestation of each application enclave of a plurality of application enclaves for a plurality of applications. The method also includes receiving a request from a client. The method also includes selecting a load balancer of a plurality of load balancers to forward the request to the plurality of application enclaves. The method also includes determining a sensitivity level of the request associated with secured environment parameters. The method also includes routing, by an enclave server of the load balancer, the request from the load balancer to an application enclave of the plurality of application enclaves according to a sensitivity level for execution of the application of the plurality of applications in the application trusted execution environment.

[0007] According to one embodiment, a non-transitory computer-readable storage medium is provided that includes instructions (e.g., a sequence of stored instructions) that, when executed by a processor, cause the processor to perform a method for providing an application trusted execution environment. The method includes performing attestation of each application enclave of a plurality of application enclaves for a plurality of applications. The method also includes receiving a request from a client. The method also includes selecting a load balancer of a plurality of load balancers to forward the request to the plurality of application enclaves. The method also includes determining a sensitivity level of the request associated with secured environment parameters. The method also includes encrypting information associated with the request based on the sensitivity level and via an encryption mechanism shared with at least one of the plurality of application enclaves before sending the request to at least one of the plurality of application enclaves. The method also includes selecting an application enclave of the plurality of application enclaves based on the sensitivity level or the application. The method also includes routing, by an enclave server of the load balancer, the request from the load balancer to an application enclave of the plurality of application enclaves according to a sensitivity level for execution of the application of the plurality of applications in the application trusted execution environment. The method also includes verifying a response from the application enclave as authentic before returning the response to the client.

[0008] In yet another embodiment, a computer-implemented method includes, at a network server, receiving a request from a client device having a user to perform a service on an application running on the client device; identifying a level of sensitivity in the request based on a desired accessibility to the requested information; determining a degree of encryption for transmitting the request to a first dedicated server hosting the application running on the client device; and routing the request to the first dedicated server for processing.

[0009] These and other embodiments will become apparent to those skilled in the art upon review of the following. [Brief explanation of the drawings]

[0010] The accompanying drawings, which are included to provide a further understanding, and which are incorporated in and constitute a part of this specification, illustrate the disclosed embodiments and, together with the description, serve to explain the principles of the disclosed embodiments.

[0011] [Figure 1] FIG. 1 is a block diagram of a device operating environment in which aspects of the present disclosure can be implemented. [Figure 2] FIG. 1 is a block diagram of an example computing network of a blockchain-based platform for providing a scaled trusted execution environment for application information and code security, in accordance with certain aspects of the present disclosure. [Figure 3] 1 is a schematic illustration of an application request to a network server in a trusted and secured application execution environment, according to some embodiments. [Figure 4] 1 is a block diagram illustrating an example computer system in which aspects of the subject technology may be implemented. [Figure 5] FIG. 2 is a block diagram illustrating an example application in a trusted execution environment, in accordance with certain aspects of the present disclosure. [Figure 6] 1 is a flowchart illustrating steps in a method for providing a trusted execution environment for multiple application services, according to certain aspects of the present disclosure. [Figure 7] 1 is a flowchart illustrating steps in a method for identifying and assigning a sensitivity level to a service request from a user in a trusted execution environment, according to certain aspects of the present disclosure. [Figure 8] FIG. 1 is a block diagram illustrating an example computer system in which aspects of the present disclosure may be implemented.

[0012] In one or more implementations, not all of the components depicted in each figure may be required, and one or more implementations may include additional components not shown in the figures. The arrangement and types of components may be changed without departing from the scope of the present disclosure. Additional, different, or fewer components may be utilized within the scope of the subject disclosure. In the figures, components having the same or similar attributes are assigned the same or similar reference numbers, unless otherwise noted. DETAILED DESCRIPTION OF THE INVENTION

[0013] In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. However, it will be apparent to those skilled in the art that embodiments of the present disclosure may be practiced without some of these specific details. In other instances, well-known structures and techniques are not shown in detail so as not to obscure the present disclosure.

[0014] The detailed description set forth below describes various configurations of the subject technology and is not intended to represent the only configurations in which the subject technology may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of the subject technology. Thus, dimensions may be provided for certain embodiments as non-limiting examples. However, it will be apparent to those skilled in the art that the subject technology may be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form to avoid obscuring the concepts of the subject technology.

[0015] It should be understood that this disclosure includes examples of the subject technology and does not limit the scope of the included clauses. Various aspects of the subject technology will now be disclosed according to specific, but non-limiting, examples. The various embodiments described in this disclosure can be implemented in different ways and with modifications according to a desired application or implementation.

[0016] General Overview Trusted Execution Environments provide strong security, confidentiality, and tamper-proof guarantees for applications running within enclaves. These solutions can be used to protect private user information and ensure the correct execution of source code. However, networking solutions for building web services that leverage trusted execution environments are lacking. Current microservice patterns for scaling web2 services lack the desired security / confidentiality properties of trusted execution web services. Without a horizontal scaling solution, the transactions per second (TPS) of trusted execution-based applications are limited to the throughput of a single machine, limiting the feasible applications that can be built.

[0017] To solve the above-mentioned problems arising in the field of network-based computer applications, embodiments disclosed herein include a computer networking architecture for building web services that leverage and scale trusted execution environments. In particular, web services (e.g., web2, web3, etc.) can be horizontally scaled so that the applications being built can extend beyond the throughput of a single machine.

[0018] The present disclosure provides systems and methods for providing an application trusted execution environment. The application trusted execution environment includes a horizontally scaled architecture that functions as a trusted enclave-based web service for an internet service distributed system. For example, the disclosed environment may incorporate the use of an isolated microservices architecture pattern so that clients of the application trusted execution environment benefit from security, confidentiality, and tamper-proof assurance / authentication in a scaled application enclave model. The scaled application trusted execution environment of the present disclosure may have an increased amount of available throughput compared to a non-scaled environment to handle large volumes of client requests via scaled secure application enclaves for internet services. As an example, the disclosed scaled application trusted execution environment may be used to enhance the security and confidentiality of services (e.g., microservices) or applications running in the context of implemented blockchain-based exchanges, cryptocurrency exchanges, and the like. The present disclosure may also provide a load balancer and secured enclave architecture for securing application programming interface (API) requests from clients in a scaled environment, which advantageously improves security and allows for the use of different encryption levels depending on the nature / characteristics of each API request.

[0019] The present disclosure provides technical solutions to problems arising in computer networks and / or cryptography. Advantageously, the present disclosure enables an improved trusted execution environment architecture that scales throughput to handle sufficient volumes of requests in a scaled memory encryption-based web application having a public-facing API layer for processing the requests. The scaled environment can handle client requests as well as attestation and load balancing. The disclosed architecture can also provide sufficient security and confidentiality guarantees. Advantageously, the provided technical solution also enables the routing / networking layer of the architecture to be optimally scalable, allowing the processing costs of handling client connections (e.g., including encryption and / or other cryptographic protocols) to be offloaded from the application server. Such offloading can address application server scalability limitations, such as those due to sequential execution requirements of application logic. As an example, a scaled secure enclave architecture can include the execution of security-related instruction code. As an example, the present disclosure enables the implementation of a trustless exchange where the exchange operator advantageously does not have access to keys (e.g., public / private key pairs) associated with cryptocurrencies held by entities requesting services via a public-facing API layer.

[0020] Thus, execution of cryptocurrency-based or other requested web services can be handled and executed in secured enclaves based on the sensitivity level corresponding to the requested service. For example, execution of cryptocurrency-based operations can be performed without disclosing sensitive / confidential information indicated in requests sent to the exchange via the API layer. In particular, decrypted sensitive information can be visible only to application enclaves (e.g., routed by a load balancer) specifically selected to process the particular request, which advantageously improves the security and effectiveness of scaled memory encryption-based web applications. Load balancers can beneficially facilitate scaling (e.g., horizontal scaling) of web applications due to the combination of the use of isolated microservices architecture patterns for requested services (e.g., web2 services) and trusted execution environment-based services. Within a web application, a load balancer can function as a thin layer (e.g., for stateless applications) to handle any clustered request sequences or other clustering of public requests and route the requests to corresponding backend application enclaves. The load balancer may be or include any suitable type of load balancing mechanism, such as a load balancer application acting as a pass-through load balancer at a fixed Internet Protocol (IP) address (e.g., passing requests through to a routing / networking enclave), a load balancer enclave at an IP address indicated by a Domain Name System (DNS) record, etc.

[0021] The disclosed system addresses a problem in computer networking and computer cryptography technology: the technical problem of scaling a memory-based cryptographic environment for web services (e.g., for microservices, computer / internet applications, and providing sensitivity and confidentiality for various types of public requests to web services). The disclosed system solves this technical problem through multiple load balancers selected by clients of the web services, such that each load balancer routes requests to attested backend application enclaves to address the load on the enclave and the sensitivity level (e.g., confidentiality) of the type of application in which each request or service is used. The disclosed system can represent an enclave-based trusted execution environment for internet-based services, including public web APIs that may require authentication via Secure Sockets Layer (SSL) client certificates.

[0022] Alternatively, the load balancer may be or include one or more pass-through load balancers that can pass-through requests to routing and / or networking enclaves, such as in a round-robin manner. In such a configuration, it may be unnecessary for such load balancers to operate in secure enclaves because the pass-through load balancers do not terminate client Transport Layer Security (TLS) connections. As such, the pass-through load balancers do not have access to sensitive information and may act as entry points for forwarding client requests / connections to routing enclaves in a rate-limited manner, so that a single routing enclave instance is not overloaded by a particular client using the same IP address. Advantageously, routing and networking enclaves (or tiers in general) can be horizontally scalable to offload work for handling client connections handled by application servers. This may improve the overall throughput and scalability of the architecture, since such application servers may be limited by sequential execution requirements.

[0023] Regardless of which of multiple suitable load balancer mechanisms is implemented, the encrypted link established via SSL between the servers providing the service may terminate within a selected one of the application enclaves so that other actors, including operators of the physical machine on which the application enclave is located, cannot decrypt the request for the service. The security of providing a web service may be improved because the encrypted request is decrypted only for the application enclave that processes the encrypted request (e.g., rather than being decrypted by the load balancer, which may unnecessarily expose otherwise encrypted information to other actors / components, such as internal microservices behind the load balancer). As an example, the disclosed system may address problems associated with frontrunning, such as when other actors have access to otherwise confidential order information submitted by a requesting user to a cryptocurrency exchange to buy or sell in front of the requesting user.

[0024] Thus, by horizontally scaling a trusted execution environment, the disclosed system provides "best" order execution without revealing cryptographic keys associated with the cryptocurrency or order information indicated by a request for a cryptocurrency transaction until the requested transaction is executed. More generally, the disclosed system provides a scaled trusted execution environment that advantageously accommodates public API layer requests for services that require or correspond to different encryption levels. Different encryption levels may refer to varying degrees of encryption depending on the different levels of confidentiality (e.g., sensitivity levels) of different requests made to the public API layer. The disclosed scaled trusted execution environment may also provide attestation, load balancing, and handling of requests received from clients for various web service applications in a cryptographically confidential manner, such that application server limitations do not prevent the scaled trusted execution environment from handling a significant volume of client requests.

[0025] The load balancer may route requests to selected application enclaves, e.g., via enclave servers, based on, e.g., different confidentiality or sensitivity levels. Alternatively, the load balancer may simply pass the client request through to the routing and networking layer, which parses the request and routes it to the application enclave using encryption. In such a scenario, if one or both applications are running within a secure enclave, remote attestation may be applied so that the applications can establish trust with each other. If such trust can be established, the client TLS connection may be terminated within the routing / networking layer (e.g., the routing / networking enclave) rather than at the application enclave layer. In this way, the disclosed system may beneficially ensure that sensitive information in a given public request to the API layer is visible only to the selected or targeted application enclave handling the given request.

[0026] Exemplary System Architecture FIG. 1 is a block diagram of a device operating environment in which aspects of the present disclosure can be implemented. FIG. 1 illustrates an example network architecture 100 for providing a trusted execution environment platform, such as a trusted enclave-based web service for providing an application trusted execution environment, according to some embodiments. The network architecture of FIG. 1 includes one or more client devices 110 and one or more servers 130 communicatively coupled via a network 150. The servers 130 provide services, such as Internet-based services, including web2 services and web3 services, to the client devices 110 in the application trusted execution environment. Thus, the servers 130 may implement computer applications for a scaled trusted execution environment that provide various services, such as cryptocurrency-based services, transaction services, payment services, lookup services, data services, query services, and the like. A database 152 may store relevant information and data structures related to the trusted enclave-based web services. Server 130 may include an enclave server, multiple load balancers (or a single pass-through load balancer connected to multiple routing / networking enclaves as described herein), and multiple application enclaves configured for memory-based encrypted execution of computer code (e.g., to implement a trusted execution environment).

[0027] The trusted execution environment platform may advantageously enable servers 130 to provide requested services or microservices to client devices 110 in a secure, confidential, and decentralized manner. Secure and confidential processing of public requests by client devices 110 may be enabled by routing public requests to application enclaves according to the public request's sensitivity level, where encrypted or sensitive information in the public request is decrypted or visible only to the specific application enclave processing the request. The DNS record of server 130 may name a set of load balancers, such as multiple load balancers or a subset thereof. Client devices 110 may then each randomly select a given load balancer from the set of load balancers, thereby advantageously maintaining a nearly even distribution of load across the load balancers. Each selected load balancer may route requests from client devices 110 (e.g., corresponding requests via enclave servers) to multiple application enclaves, such as routing a given request to a given attested backend application enclave. Each selected load balancer may also route the request to multiple backend server components of one or more servers 130, which may or may not include application enclaves.

[0028] As an example, data read requests can be routed to a set of server / application enclaves, while more computationally expensive requests (e.g., order execution requests) can be routed to another set of application enclaves. Alternatively, the set of load balancers can be replaced with a single (or two or more) pass-through load balancers. The pass-through load balancers can be located at fixed IP addresses to provide rate limiting (e.g., to prevent clients from spamming a single routing enclave instance) and round-robin routing of requests from client devices 110. Because pass-through load balancers do not terminate TLS connections for client devices 110, it may not be necessary for the pass-through load balancers to operate within secure enclaves. Rather, TLS connection termination can be offloaded to an enclave routing / networking layer. In this way, aggregate load can be reduced and load can be better scaled for a scaled trusted execution environment. The scaled trusted execution environment can be horizontally scaled to multiple different suitable load balancing mechanism implementations that operate in front of or in combination with the routing enclave layer.

[0029] The network 150 may include a wired network (e.g., via optical fiber or copper wire, telephone lines, etc.) or a wireless network (e.g., a cellular network, a radio frequency (RF) network, Wi-Fi, Bluetooth, etc.). The client device 110 may be any one of a mobile device, a laptop, a desktop, a tablet (e.g., palm or pad) device, a television, a display device, etc. The client device 110 may be controlled by a user to request services, such as through mechanisms described herein. For example, the client device 110 may use API calls to request services for transaction processing, consensus, smart contracts, and key storage. A smart contract may refer to a self-executing computer program, application, or agreement for performing transactions, such as financial transactions involving cryptocurrency. The API calls may include public requests, such as Hypertext Transfer Protocol (HTTP) Internet-based request methods, for communicating between the client device 110 and the server 130. For example, the publishing request may include GET, POST, PUT, HEAD, DELETE, PATCH, OPTIONS, CONNECT, TRACE, etc., to request a service or microservice provided by the trusted execution environment platform via the server 130. Multiple client devices 110 may access the trusted execution environment platform hosted by the server 130 via online or offline connections, such as wireless, wired, ad hoc, mobile, or satellite connections. Each of the servers 130 may be a computing device, such as one or more desktop computers or part of a cloud computing server, including a panel mounted on a rack, etc. The panel may include processing boards as well as switchboards, routers, and other network devices.

[0030] FIG. 2 is a block diagram of an example computing network 200 of an example blockchain-based platform for providing a scaled trusted execution environment for application information and code security, according to certain aspects of the present disclosure. The computing network 200 may represent a web application for services handled in the scaled trusted execution environment. The web application may provide web services to one or more client devices 110 via one or more servers 130. Services may be requested via public requests to the API layer 215, which may be associated with different levels of confidentiality for different requests. As an example, an API POST request that sends information from one or more client devices 110 to one or more servers 130 may be treated differently from an API GET request that requests non-confidential information from the server 130. Confidential or sensitive information indicated in or corresponding to a particular API request may benefit from memory-based encryption via the scaled trusted execution environment, which may prevent operators of the server 130, the environment, or some other actor involved in the environment from accessing the confidential information. As discussed herein, memory-based encryption may be based on Intel Software Guard Extensions (SGX), available from Intel Corporation of Santa Clara, California.

[0031] In particular, any encrypted or sensitive information in a public API request may not be decrypted or may be visible to unauthorized actors until an application enclave (e.g., implementing memory-based encryption) processes or handles the received public API request. That is, public requests to API layer 215 may not be visible from the encrypted and / or secured enclave environment. To manage traffic or bottlenecks associated with large volumes of public requests transmitted from one or more client devices 110 through one or more servers 130 for services provided by a web application, multiple load balancers may be provided. The multiple load balancers may be configured to determine which requests are sent to which of multiple backend attested application enclaves. Alternatively, a particular load balancer may pass through public API requests without terminating TLS, such that an enclave routing layer (e.g., including multiple routing / networking enclaves) can not only securely terminate the TLS connection but also parse and route public API requests to multiple backend attested application enclaves.

[0032] Attestation of application enclaves can be performed by one or more client devices 110 or via multiple load balancers. As an example, one or more client devices 110 can perform remote attestation of multiple load balancers and / or their constituent load balancer enclaves. As an example, a load balancer enclave can perform attestation of a backend application enclave, thereby eliminating the need for one or more client devices 110 to attest to the backend application enclave. When participating in a scaled trusted execution environment or when one or both parties using a web application are running within a secure enclave, remote attestation can be performed as a mechanism to establish trust between applications (e.g., corresponding to a backend application enclave). Specifically, the establishment can be used to enable secure termination of a TLS connection within the routing or networking layer rather than termination at multiple backend attested application enclaves. This architecture may improve the throughput and / or efficiency of scaled trusted execution environments and / or web applications, such as by avoiding slowdowns or other restrictive sequential execution requirements of application logic corresponding to multiple backend attested application enclaves.

[0033] The load balancer enclave can perform proxy attestation for one or more client devices 110. The load balancer enclave can also (e.g., once) determine a hash (e.g., value, algorithm, etc.) of a requested service or application running on a backend application enclave, thereby ensuring security by routing each request made to a web application using an appropriate level of encryption, taking into account the sensitivity / confidentiality level of the corresponding request. Furthermore, multiple load balancers and one or more (backend) servers 130 can perform mutual attestation so that a combination of a balancer and a server can perform all functions that the web application is responsible for performing. The multiple load balancers can consider different levels of encryption depending on the different sensitivity levels of different public requests for computational efficiency, so that computing resources are used efficiently. For example, multiple load balancers can forward encrypted information to an application enclave using encryption required for the sensitivity of the request, thereby reducing computing processing costs, thereby reducing the total computing cost required for encryption by applying selective encryption. Thus, one or more client devices 110 may attest the identities of multiple load balancers to verify that they do not contain services / applications run by application enclaves. For example, an attested load balancer can be attested to determine that it is the intended load balancer to forward packets (e.g., data packets, API requests, etc.) from a given client device 110 to a specified backend application enclave while maintaining confidentiality. Information for performing various attestations as described herein may be stored in attestation information / data database 226.

[0034] Each of the one or more client devices 110 and one or more servers 130 may access each other and other devices within the network 150 via corresponding communications modules 210a-210b. A load balancer may perform front-end activities, such as user input sanitization, for one or more client devices 110. Each of the communications modules 210a-210b may include wireless hardware and software, such as an RF antenna, analog circuitry, digital-to-analog conversion circuitry, and digital signal processing circuitry. Each of the client devices 110 and servers 130 depicted in FIGS. 1-2 may include a processor 205a-205b and memory 220a-220b. The processor 205a of the client device 110 may be used to operate the client device 110, such as to execute applications and their functions rendered on the client device 110 and to send requests for services, such as blockchain operations, runtime application functions, and cryptocurrency-based transactions, to the API layer 215. Requests to API layer 215 may include, consist of, or correspond to application information located in application 222 and data files 224. For example, data stored in application 222 may be used for data related to client applications and web applications of a trusted application execution environment, such as a client digital wallet for managing and conducting transactions with cryptocurrency. Processor 205b may be used to implement hardware-based cryptography, such as isolated or siloed memory-based processing of requests to API layer 215.

[0035] For example, processor 205b may implement an application enclave in a portion of computer memory for secure or confidential execution of computer operations, such as for processing API requests. Processor 205b may communicate with database 228 containing encryption and enclave information (e.g., including software development kit information) to facilitate secure code execution and request and data isolation within the application enclave of the trusted execution environment platform. For example, processor 205b may communicate with database 228 to generate encryption keys for securely storing and retrieving sensitive or confidential information being transmitted or received externally to the corresponding application enclave. As an example, the application enclave may be located or implemented as a trusted component of memory for a web application, such as memory of a trusted execution environment platform that may at least partially include memory 220b. Server 130 may be configured to scale memory-based encryption for executing code, handling API requests, and storing sensitive data for one or more client devices 110 that may transmit large volumes of requests. In this manner, the trusted execution environment may use scaled, isolated memory enclaves to ensure secure, confidential communications between one or more client devices 110, server 130, and one or more other actors for secure communications, payments, transactions, etc. associated with services provided by web applications (e.g., cryptocurrency and smart contract-based services). Memories 220a and 220b and processors 205a and 205b are hereinafter collectively referred to as "memory 220" and "processor 205."

[0036] Generally, client device 110 and server 130 comprise computing devices including at least a memory 220 that stores instructions and a processor 205 configured to execute the instructions to at least partially perform one or more steps described in the methods disclosed herein. For example, memory 220a of client device 110 may be used to access a browser, service, or application component 222 that is part of a trusted execution environment platform hosted by server 130.

[0037] For example, client device 110 makes requests to API layer 215 while executing application 222. Sensitivity level module 216 within server 130 identifies and determines sensitivity / confidentiality levels for different types of requests to API layer 215 within the trusted execution environment. These sensitivity levels may be integrated into data files 224 provided to client device 110 and associated with application 222. In some embodiments, sensitivity level module 216 may assign different sensitivity levels to one or more requests within the same application 222.

[0038] The input device 230b can be used by the server 130 to define what types of services and requests are supported by the application 222 and the API layer 215. Sensitivity levels can be defined via user / operator input, such as via the input device 230a. Data files 224 stored in memory 220a can include application settings, files, and data specific to an associated user of the client device 110. The client device 110 can be used by a user to conduct cryptocurrency transactions or request other services offered by web applications, such as via a graphical user interface (GUI) screen rendered on the client device 110. For example, the client device 110 can be coupled to at least one input device 230a and an output device 232 accessible by the user (e.g., for user input and output perceptible by the user). The input device 230a can include a mouse, keyboard, pointer, stylus, touchscreen display, microphone, voice recognition software, a graphical user interface (GUI), etc. The output device 232 may include a display (eg, a touchscreen display similar to the input device), a speaker, an alarm, and the like.

[0039] Although the above description describes certain functions being performed by processor 205a of client device 110 and certain other functions being performed by processor 205b of server 130 (hereinafter collectively referred to as "processor 205"), all of the functions described herein may be performed by client device 110 and / or server 130 in some other alternative distribution of roles. That is, processor 205 may perform more or fewer functions than those described above. In some embodiments, some or part of client device 110 may be co-located with server 130. That is, server 130 may be located remotely from client device 110, or both client device 110 and server 130 may be part of the same larger computing system, network, or architecture.

[0040] The techniques described herein may be implemented as methods performed by a physical computing device, as one or more non-transitory computer-readable storage media that store instructions that, when executed by a computing device, cause the method to be performed, or as a physical computing device specially configured with a combination of hardware and software that causes the method to be performed.

[0041] FIG. 3 is a schematic, illustrative diagram of a trusted execution environment 300 according to some embodiments. The environment 300 includes an application request 301-1 and an application request 301-2 (collectively referred to hereinafter as "API request 301") from a client device 310 in a front-end 305A to a network server 330-1. The client device 310 may be a mobile device in the hand of a user running a network application, or a resource node in a network or an administrator / operator of a remote platform providing services to the application. The network server 330-1 is configured to handle the trusted execution environment 300 for multiple application services. Accordingly, based on the application request 301, the network server 330-1 routes the request 301 to a designated enclave server 330-2 in a back-end 305B. The enclave server 330-2 hosts the specific application for the service request 301. The enclave server 330-2 may provide services involving encrypted communications, such as executing cryptocurrency orders for purchase or sale transactions. Network server 330-1 and enclave server 330-2 are hereinafter collectively referred to as "server 330."

[0042] The API request 301 may include a request 301-1 (e.g., GET) to receive data and / or information in the client device 310 from an external resource or service running on the server 330. The request 301-1 may serve only to assure the client device 310 that the response is being authentically received from the enclave server 330-2. Thus, the request 301-1 may not be encrypted when forwarded to the enclave server 330-2. For example, the response may be authenticated via a hash-based message authentication code (HMAC) signature from a verified application enclave, based on a cryptographic signature, a token, a hash, or a private key 318-1, etc. The private key 318-1 may be shared by the client device 310 and the server 330-1. Once authenticated, the server 330-1 forwards the request 301-1 to the enclave server 330-2 without encryption. Additionally, in some embodiments, private key 318-1 may be used to establish trust for scaling or to shift responsibility for terminating TLS connections for client device 310.

[0043] API request 301-2 may include sensitive (e.g., confidential) data (e.g., POST, PUT) from client device 310 to enclave server 330-2. As an example, a POST or PUT request may send sensitive data from client device 310 to server 330-1 to create or update a resource. Thus, API request 301-2 may be encrypted by network server 330-1 using encryption key 318-2 before being received by enclave server 330-2 to hide the sensitive information (e.g., cryptocurrency orders) from components of environment 300 external to enclave server 330-2. Other requests 301 may include commands such as HEAD for writing or displaying a string of a preselected size at the beginning of a file, DELETE for erasing a portion of a file, PATCH for applying edit instructions to a file, OPTIONS for listing option or parameter values ​​within a given command, CONNECT for connecting with enclave server 330-2, and TRACE for determining the travel time of a data packet between client device 310 and enclave server 330-2. Encryption key 318-2 may be a shared secret between a particular load balancer in server 330-1 and enclave server 330-2. Therefore, other actors or operators in environment 300 may not be able to access sensitive information before API request 301-2 is executed / handled by enclave server 330-2. Encryption keys 318-1 and 318-2 are collectively referred to as "encryption keys 318" and are stored in database 328.

[0044] Each of requests 301 may have a different sensitivity level for privacy and security, as assessed by sensitivity level module 316. For example, CONNECT request 301 to create a secure connection to enclave server 330-2 may include a less robust sensitivity level than POST or PUT request 301-2. In such a case, network server 330-1 may encrypt request 301 using encryption key 318 that is less strict (e.g., has fewer bits) than encryption key 318-2 but more robust (e.g., has more bits) than encryption key 318-1.

[0045] Generally, API requests 301 such as HEAD, OPTIONS, CONNECT, and TRACE are used to manage / view HTTP connection settings / options (although they may be rarely used). API requests 301 such as GET, POST, PUT, DELETE, and PATCH may be used with different sensitivity levels. Thus, the sensitivity level is not necessarily tied to the HTTP method. For example, a GET request to view public information (e.g., the latest BTC / USD price, the current server time, etc.) may be associated with a low sensitivity level. However, a GET request to view sensitive information (e.g., one's account balance / transaction history, etc.) may be associated with a high sensitivity level. The enclave server 330-2 will know the sensitivity level of the request based on both the HTTP method and the URL path. For example, "GET / price" may be low sensitivity, while "GET / account / balance" may be high sensitivity.

[0046] Network server 330-1 provides multi-service environment 300 with enhanced data security and high computational efficiency. For example, encryption key 318-2 only allows access to request 301-2 (e.g., requesting a cryptocurrency transaction) to enclave server 330-2. Furthermore, networking in backend 305B between the load balancer and different enclave servers 330-2 can be performed externally to each of enclave servers 330-2. This reduces the processing cost and time for enclave server 330-2 to process request 301-2 because the networking overhead is handled by network server 330-1. Therefore, enclave server 330-2 uses encryption with different levels of complexity only when desired, as determined by sensitivity level module 316 in API layer 315. This gradual security complexity reduces computational and encryption costs. Thus, sensitivity level module 316 facilitates horizontal scaling of environment 300 based on the services supported by enclave server 330-2.

[0047] FIG. 4 is a block diagram illustrating an exemplary computer system 400 in which aspects of the subject technology can be implemented. The system 400 can be configured to provide a scaled trusted execution environment in accordance with certain aspects of the present disclosure. In some implementations, the system 400 can include one or more computing platforms 402. The computing platform 402 can correspond to a server component of a trusted execution environment platform as disclosed herein (see server 130 and client 110). The computing platform 402 can be configured to provide a horizontally scaling architecture for trusted execution environment-based web services to provide services (e.g., microservices, web2 services, web4 services, etc.) in response to requests (e.g., public API requests from remote platform 404), such as services for blockchain or cryptocurrency accounts. In particular, the computing platform 402 can provide security guarantees that are applied at various levels of security depending on the sensitivity level of the request being received and routed to an application enclave for handling / executing data and code in a secured, isolated portion of computer memory.

[0048] Computing platform 402 may be configured to communicate with one or more remote platforms 404 according to a client / server architecture, a peer-to-peer architecture, and / or other architectures. Remote platform 404 may be configured to communicate with other remote platforms via computing platform 402 and / or according to a client / server architecture, a peer-to-peer architecture, and / or other architectures. Because an unscaled trusted execution environment may handle only a limited amount of requests, computing platform 402 of a horizontally scaled trusted execution environment may address this limitation by providing more throughput to handle a larger volume of requests. That is, system 400 may provide a networking solution for providing web services or microservices within an enclave execution environment. In this manner, remote platform 404 may interact with computing platform 402 to request and receive internet-based services. As an example, client devices of remote platform 404 may submit API requests requiring different levels of security, and the computing platform may provide the security, confidentiality, and tamper-proofing guarantees necessary for trusted execution of the API requests according to their corresponding security or sensitivity levels. Client devices of remote platform 404 may select different enclave-encrypted load balancers from DNS records of offered web services, thereby maintaining a distributed load across the load balancers. DNS records naming the set of enclave-encrypted load balancers may be stored in storage of external resource 424. Computing platform 402, external resource 424, and remote platform 404 may communicate and / or be accessible to each other via network 150.

[0049] The computing platform 402 may be configured with machine-readable instructions 406. The machine-readable instructions 406 may be executed by the computing platform to implement one or more instruction modules. The instruction modules may include computer program modules. The implemented instruction modules may include one or more of an application enclave module 408, a load balancer module 410, an attestation module 412, an API layer 415 including a sensitivity level module 416, an encryption module 418, and / or other instruction modules.

[0050] The application enclave module 408 can implement a trusted enclave environment, such as a secure application enclave, for data and / or computer code transmitted or executed for a delivered web service. As used herein, a web service may include user interface and backend services such as fulfilling orders (e.g., payments and transactions), maintaining inventory or accounts, checking user or transaction data (e.g., related to cryptocurrency accounts), consensus, smart contracts, and cryptographic information storage. An application enclave may constitute a trusted environment as a private enclave isolated by a central processing unit (CPU) residing in a portion of the computing platform's 402 memory. When sensitive data or code resides (or is running or being handled) within a particular enclave, such data or code cannot be accessed. That is, the contents of an application enclave implemented by the application enclave module 408 are not erasable, modifiable, or otherwise accessible to external actors. In this manner, the application enclave module 408 can provide code confidentiality and authentication.

[0051] For example, the application enclave module 408 and the attestation module 412 can perform attestation, which can be remote. As an example, a remote party may receive cryptographic proof that a particular application enclave of the application enclave module 408 with which the remote party is communicating is a valid enclave, signed by a particular identity running a particular version of source code. In this way, the application enclave of the application enclave module 408 can be attested or verified as proof that the application enclave is a valid enclave running a particular version. This link of trust can be based on a cryptographic secret shared via the attestation. For example, the result of the remote attestation can be the generation of a shared secret known only to the requesting party of the remote platform 404 and the application enclave communicating with the requesting party. This allows the requesting party and the application enclave to use the shared secret to encrypt further messages or communications. As an example, the shared secret can be generated via a Diffie-Hellman key exchange. The cryptographic keys can be securely stored in the electronic storage 426 and in memory of the remote platform 404, respectively.

[0052] The application enclave module 408 may initialize each application enclave as a backend component of a web application configured to provide a web service. Such initialized application enclaves may not be publicly accessible, but rather may be accessible only to the load balancer host of the load balancer module 410. The initialized application enclaves may be configured to handle data / requests or execute instructions for public requests to a particular web service from various client devices of the remote platform 404. Advantageously, only selected application enclaves among the initialized application enclaves for each public request may have access to sensitive information indicated in or associated with the corresponding public request. For example, only selected application enclaves executing cryptocurrency transactions may have access to otherwise encrypted / sensitive order information for the transaction. The application enclaves of the application enclave module 408 may be used to securely provide web services, such as the order matching execution sequence logic of a web application used to trade cryptocurrency for a given workbook pair. For example, an application enclave may be a contest administrator or manage other types of web services presented online by a web application.

[0053] The load balancer module 410 may route requests to various application enclaves in the application enclave module 408 based on the sensitivity level of the public request, which may be indicated by the sensitivity level module 416. The load balancers in the load balancer module 410 may be managed by a web application or an application in the scaled trusted execution environment of the system 400. The load balancer application may function as a thin tier that handles public requests from various client devices in the remote platform 404. The load balancer application may be a stateless application so that it can be horizontally scaled. That is, the load balancer tier may have multiple applications, components, and / or load balancers with encryption keys for encrypting information for transmission on corresponding application enclaves rather than reading from or writing to a database. The application may facilitate DNS records from an external resource 424 that name a set of various enclave-encrypted load balancers for selection by various client devices, which may help maintain a generally fair load distribution across the various enclave-encrypted load balancers. As described herein, the load balancer module 410 may also implement a pass-through load balancer at a fixed IP address that connects to a routing layer in front of the application enclaves controlled by the application enclave module 408.

[0054] The load balancer routes public requests to attested backend application enclaves of the application enclave module 408 according to the load of the application enclave so as not to overload the application enclave instances. As an example, a client device sends public requests to an API of the load balancer application via an SSL connection that terminates within the load balancer enclave of the enclave-encrypted load balancer / load balancer application. In this manner, confidentiality of the public requests can be improved according to the associated sensitivity level. The load balancer enclave can validate and sanitize the public requests being received. The load balancer enclave can determine to which backend application enclave the enclave-encrypted load balancer should route or forward the public request. This routing can be based on the respective sensitivity level of the public request. As an example, the load balancer enclave can encrypt sensitive request information of the public request according to the respective sensitivity level using a shared secret from electronic storage 426 shared with each destination backend application enclave of the application enclave module 408.

[0055] After encryption via the shared secret, the load balancer enclave may externally transmit the encrypted public request to the load balancer enclave for forwarding to a back-end application server. For example, untrusted code outside the trusted execution environment may forward the encrypted request information by the load balancer enclave to a particular back-end application server (e.g., a networked virtual machine) that manages a particular application enclave of the application enclave module 408. After executing or handling the encrypted request (e.g., including decryption by the particular application enclave via the shared secret), the resulting response from the particular application enclave is forwarded by the back-end application server back to the routing load balancer, which can verify the resulting response as authentic and return the response to the client device of the remote platform 404 that originally generated the request. The load balancer and other components of the load balancer module 410 can advantageously determine which requests need to pass through which application enclaves at what level of encryption, which can improve computational efficiency and resource usage for the operation of web applications and horizontally scaled trusted execution environments. That is, application enclaves can perform the minimum operations necessary to achieve a scaled trusted environment.

[0056] The attestation module 412 may be used to perform attestation and / or generate attestation reports. As an example, a client device of the remote platform 404 may perform attestation of a load balancer enclave and / or an application. Attestation performed by the client device may trigger the generation of an attestation report indicating, for each backend application enclave to which the client device is connected, a response received from the corresponding load balancer enclave. Furthermore, the attestation report from the client device may include proof that the corresponding application enclave securely holds (e.g., in electronic storage 426) the associated SSL key for the certificate used for the client's API (e.g., HTTPS API). This allows the client device to verify that the scaled trusted encryption environment is functioning properly. The attestation module 412 may also be used by a load balancer of the load balancer module 410 to attest an application enclave of the application enclave module 408 that is located "behind" the load balancer for a web application. The attestation performed by the attestation module 412 may also be remote attestation to establish trust between applications, so that the TLS connection to the client device of the remote platform 404 can terminate before the application enclave of the application enclave module 408 in the secure routing / networking layer, which may improve the computational scalability, efficiency, and / or processing power of the scaled trusted execution environment.

[0057] The attestation module 412 obtains a shared cryptographic secret for encrypting messages, data, and / or requests forwarded by the load balancer module 410. The attestation module 412 facilitates attestation by the load balancer of each backend application enclave and stores the results of the attestation. The attestation module 412 generates a resulting cryptographic secret, which can be stored in electronic storage 426. The resulting cryptographic secret can be shared between the load balancer and the application enclave and can be used to encrypt and authenticate any future requests from the application's load balancer module 410 and the application enclave machine layer. The attestation module 412 can also facilitate attestation of the load balancer enclave by the application enclave. In such a scenario, the backend application server of the application enclave can delegate certain checks, such as data sanitization, to the load balancer node.

[0058] To provide the correct level of security assurance within the scaled trusted execution environment, the sensitivity level module 416 can define a sensitivity level for each type of request to the API layer 415. The sensitivity level module 416 determines whether a particular API request should be visible to the server operator for the application or should be encrypted.

[0059] As discussed herein, the encryption module 418 can encrypt and provide an appropriate level of confidentiality depending on which request is generated by the client device of the remote platform 404 and which service is requested. Different levels of encryption can be based on different techniques, such as symmetric encryption, hashing, security or access tokens, asymmetric encryption, or other cryptographic methods, which can be applied according to a defined level of sensitivity. The encryption module 418 can determine the level and robustness of the encryption keys, shared secrets, hash functions, encryption algorithms, and / or digital signatures used. The encryption module 418 can provide security assurances that actors or components do not access sensitive or confidential information during processing in the backend of the web application. For example, the encryption module 418 can cause the successful execution of a cryptocurrency transaction on a blockchain-based exchange without anyone having access to the encryption keys, funds, or other personal sensitive information of the user of the client device being used for the web application's services. For example, the encryption module 418 and the application enclave module 408 can be used to implement a trustless exchange so that a server operator or other actor involved with the computing platform 402 cannot access data or code within the application enclave.

[0060] In some implementations, the computing platform 402, the remote platform 404, and / or the external resources 424 may be operatively linked via one or more electronic communication links. For example, such electronic communication links may be established, at least in part, via the network 150, such as the Internet and / or other networks. This is not intended to be limiting, and it will be understood that the scope of the present disclosure includes implementations in which the computing platform 402, the remote platform 404, and / or the external resources 424 may be operatively linked via some other communication medium.

[0061] A given remote platform 404 may include client computing devices, each of which may include one or more processors configured to execute computer program modules. The computer program modules may be configured to enable professionals or users associated with the given remote platform 404 to interface with the system 400 and / or external resources 424 and / or to provide the remote platform 404 with other functionality attributed herein. By way of non-limiting example, a given remote platform 404 and / or a given computing platform 402 may include one or more of a server, a desktop computer, a laptop computer, a handheld computer, a tablet computing platform, a netbook, a smartphone, a game console, and / or other computing platforms. The external resources 424 may include information sources external to the system 400, external entities participating in the system 400, and / or other resources. For example, the external resources 424 may include externally designed blockchain elements and / or applications designed by a third party. In some implementations, some or all of the functionality attributed herein to the external resources 424 may be provided by resources included in the system 400.

[0062] Computing platform 402 may include electronic storage 426, a processor (see processor 205), and / or other components. Computing platform 402 may include communication lines or ports that enable the exchange of information with a network and / or other computing platforms. The illustration of computing platform 402 is not intended to be limiting. Computing platform 402 may include multiple hardware, software, and / or firmware components that work together to provide the functionality attributed to computing platform 402 herein. For example, computing platform 402 may be implemented by a cloud of computing platforms that work together as computing platform 402.

[0063] Electronic storage 426 may include non-transitory storage media that electronically store information. The electronic storage media of electronic storage 426 may include one or both of system storage provided integrally (i.e., substantially non-removably) with computing platform 402 and / or removable storage that is removably connectable to computing platform 402 via, for example, a port (e.g., a USB port, a Firewire port, etc.) or a drive (e.g., a disk drive, etc.). Electronic storage 426 may include one or more of optically readable storage media (e.g., optical disks, etc.), magnetically readable storage media (e.g., magnetic tape, magnetic hard drives, floppy drives, etc.), charge-based storage media (e.g., EEPROM, RAM, etc.), solid-state storage media (e.g., flash drives, etc.), and / or other electronically readable storage media. Electronic storage 426 may include one or more virtual storage resources (e.g., cloud storage, virtual private networks, and / or other virtual storage resources). The electronic storage 426 may store software algorithms, cryptographic information, information determined by the processors 205a-205b, information received from the computing platform 402, information received from the remote platform 404, and / or other information that enables the computing platform 402 to function as described herein.

[0064] A processor may be configured to provide information processing capabilities in the computing platform 402. As such, the processors 205a-205b may include one or more of a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and / or other mechanisms for electronically processing information. Although the processors 205a-205b are depicted in FIG. 1 as a single entity, this is for illustrative purposes only. In some implementations, a processor may include multiple processing units. These processing units may be located within the same physical device, or the processors 205a-205b may represent the processing functions of multiple devices acting in concert. The processor may be configured to execute the modules 408, 410, 412, 416, 418, and / or other modules by software; hardware; firmware; some combination of software, hardware, and / or firmware; and / or other mechanisms for configuring processing capabilities on the processors 205a-205b. As used herein, the term "module" may refer to any component or set of components that implements the functionality attributed to the module, which may include one or more physical processors during execution of processor-readable instructions, circuitry, hardware, storage media, or any other component.

[0065] Although modules 408, 410, 412, 416, and / or 418 are illustrated as being implemented within a single processing unit, it should be understood that in implementations in which a processor includes multiple processing units, one or more of modules 408, 410, 412, 416, and / or 418 may be implemented remotely from the other modules. The description of functionality provided by different modules 408, 410, 412, 416, and / or 418 described herein is for purposes of illustration and not intended to be limiting, and any of modules 408, 410, 412, 416, and / or 418 may provide more or less functionality than described. For example, one or more of modules 408, 410, 412, 416, and / or 418 may be eliminated, and some or all of its functionality may be provided by other of modules 408, 410, 412, 416, and / or 418. As another example, processors 205a-205b may be configured to execute one or more additional modules that may perform some or all of the following functions attributed to one of modules 408, 410, 412, 416, and / or 418:

[0066] The techniques described herein may be implemented as methods performed by a physical computing device, as one or more non-transitory computer-readable storage media that store instructions that, when executed by a computing device, cause the method to be performed, or as a physical computing device specially configured with a combination of hardware and software that causes the method to be performed.

[0067] 5 is a block diagram illustrating an example application trusted execution environment 500 according to certain aspects of the present disclosure. The application trusted execution environment 500 may include a client device 501, at least one secured environment load balancer 502, and network virtual machines (VMs) 506a-506n, each including a respective application enclave 508a-508n. The at least one secured environment load balancer 502 may include a load balancer enclave 504. Although only one load balancer 502 is shown, there may be more than one load balancer 502, depending, for example, on the degree of scaling required to handle requests from the client device 501. The secured environmental load balancer 502 may be a stateless application, which allows the secured environmental load balancer 502 to scale horizontally according to the load represented by the volume of published requests, such that the load of requests from the client devices 501 may be evenly distributed across the secured environmental load balancer 502 and forwarded to the networked VMs 506 a- 506 n containing application enclaves 508 a- 508 n, where n may be any integer greater than or equal to 3. The number of VMs n may be as large as desired, depending on the degree of scaling desired to handle the forwarded requests from the client devices 501 and the load balancer 502.

[0068] The requests can be public API requests for services provided by web applications implementing the application trusted execution environment 500. For example, an API request from a client device 501 can be sent to (e.g., received by) the load balancing enclave component 504 of one secured environment load balancer 502 via SSL end-to-end encryption, such that the SSL connection for the API request can terminate at the load balancing enclave component 504. Before sending the request, the client device 501 can perform attestation of the load balancing enclave component 504 and the secured environment load balancer 502, and the application enclaves 508a-508n can perform attestation of each other, such as to generate shared secrets for encryption. For each request from each sending client device 501, the load balancer enclave component 504 can route or forward each request to an application enclave 508a-508n using a level of encryption corresponding to the level of confidentiality / sensitivity required for each request.

[0069] As an example, the load balancer enclave component 504 may re-encrypt an API request from a particular client device 501 that contained sensitive information, such as cryptographic order information, for a new order API request to a web application in the application trusted execution environment 500. That is, the original SSL encryption terminated at the load balancer enclave component 504 may cause the sensitive order information to be visible to the load balancer enclave component 504, which can re-encrypt the sensitive order information using a shared secret (e.g., a shared cryptographic secret key such as an HMAC secret key) shared with the particular VM and application enclave in the VMs 506 a-506 n and application enclaves 508 a-508 n. By using the shared secret for encryption, the load balancer enclave component 504 can act as an enclave server and route the re-encrypted new order API request from the secured environment load balancer 502 to the particular application enclave selected (e.g., via the sensitivity level of the new order API request).

[0070] The re-encrypted request can be forwarded by the load balancer enclave server 504 through an untrusted networking layer (e.g., distinguished by the trusted execution environment of the application / memory enclave). Because the re-encryption is symmetric, the specific application enclave can decrypt the re-encryption using a shared secret and handle the new order API request. Other types of API requests from a specific client device 501 can be encrypted differently or not at all according to the confidentiality and sensitivity of the specific type of API request, as indicated by the corresponding sensitivity level. As an example, a type of non-confidential API request to retrieve order information for the client device 501 at a specific time, such as yesterday or some other time in the past. As an example, if the body of a non-confidential API request is not encrypted, authentication, partial encryption, or other security guarantees can be provided. For example, in response to a non-confidential API request, a specific application enclave can provide an HMAC on the response body as assurance (e.g., to the specific client device 501) that the untrusted party has not tampered with the results of the non-confidential API request. Such an HMAC may prevent tampering or unauthorized modification of the result, even though the result may be visible.

[0071] In this manner, the load balancer enclave server 504 can apply a corresponding type of re-encryption or no encryption (e.g., simply authenticating the application enclave response rather than encrypting the API request). The load balancer enclave server 504 can validate and sanitize API requests from a particular client device 501 and determine to which application enclave 508a-508n an API request of a particular type should be forwarded. Routing by the secure environment load balancer 502 and / or the load balancer enclave server 504 can be based on the level of encryption or security required for a given type of API request. For example, the sensitivity level of a given type of API request can be used to determine to which application enclave 508a-508n an API request of a given type should be routed. The sensitivity level can be determined by an operator of the application trusted execution environment 500 or can be received as input from a particular client device 501. For example, a particular client device 501 may send sensitivity level information in a configuration file along with an API request for the secure environment load balancer 502 and / or load balancer enclave server 504 to determine the sensitivity level.

[0072] Alternatively, the load balancer enclave server 504 can function as any suitable type of load balancing mechanism. For example, the load balancer enclave server 504 may function as a single load balancer application at a fixed IP address that acts as a pass-through to a routing / networking enclave layer (e.g., including multiple routing / networking enclaves). In such an implementation, the secure environment load balancer 502 may instead operate outside the secure enclave, given that the secure enclave would not terminate a particular client device's 501 TLS connection to the routing / networking enclave layer. The pass-through load balancer 502 may simply function as an entry for forwarding connections to the routing / networking enclave layer. Because the pass-through load balancer 502 functions as a single application at a fixed IP address, this configuration can beneficially prevent a particular client device 501 from spamming a single routing enclave instance by using the same IP address and bypassing DNS round-robin resolution. Thus, the efficiency and throughput of the load balancing mechanism and / or the application trusted execution environment 500 may be improved.

[0073] The pass-through load balancer 502 may perform multiple functions, such as rate limiting and round-robin routing to routing / networking enclaves in the routing / networking enclave layer. Such rate limiting may occur outside of the secure enclaves because TLS connection termination (and corresponding visibility of public API requests from a particular client device 501) does not occur until the request reaches a routing / networking enclave (e.g., is routed to a particular routing / networking enclave). Once a public API request is routed to a corresponding particular routing / networking enclave, the corresponding enclave may terminate the TLS connection. The corresponding routing / networking enclave may also parse and route the request to an application enclave 508a-508n (e.g., a particular corresponding instance of an application enclave 508a-508n). In this configuration, public requests to the API layer are routed to the corresponding application enclave 508a-508n, which receives requests from the corresponding routing / networking enclave and handles the corresponding application logic.

[0074] Regardless of which suitable load balancer mechanism is implemented, the load balancer 502 may determine which of the application enclaves 508a-508n to route which API requests to by considering the volume of applications in the application enclaves 508a-508n behind the load balancer 502. For example, various application enclaves 508a-508n may perform different roles, such as application enclave 508a being a cryptocurrency order book while application enclave 508b being a platform for a different cryptocurrency exchange. Instances of application enclaves 508a-508n may also be arbitrarily generalized applications that handle specific types of requests from specific client devices 501. Thus, the secure environment load balancer 502 and / or the load balancer enclave server 504 may route requests to the API layer based on their corresponding request types. For example, a specific application enclave 508a-508n may support a specific type of order book. As an example, the secure environment load balancer 502 and / or the load balancer enclave server 504 can route requests to an API layer for a particular currency pair according to which of the application enclaves 508a-508n handles or supports the order book corresponding to the particular currency pair.

[0075] In this manner, load traffic can be more evenly distributed across the application enclaves 508a-508n, which can beneficially facilitate the implementation of a horizontally scaled application trusted execution environment 500 to split request traffic while maintaining the security of the trusted execution environment required for various requests. As discussed herein, the scaled secure computing of the application trusted execution environment 500 can advantageously prevent unwanted actions by malicious actors, such as frontloading a request to the API layer for a matched / executed sell order to execute the same cryptocurrency sale. The horizontally scaled application trusted execution environment 500 can be part of any web application requiring scaled secure computing in a networked environment. In particular, the horizontally scaled application trusted execution environment 500 can be useful for microservices architectures providing application enclave execution to protect operators and / or order matching of a microservices architecture for a cryptocurrency exchange from front-running cryptocurrency orders received via requests to the API layer.

[0076] Thus, the application trusted execution environment 500 can provide a user of a particular client device 501 with security assurance that requests to the API layer for cryptocurrency order execution are executed correctly without unauthorized access to the user's cryptocurrency funds or confidential / sensitive information. The security assurance can be based on encryption of sensitive information as it is passed externally to a valid application enclave running a particular source code version and verifying / authenticating that the valid application enclave is operating correctly. Attestation can provide cryptographic proof of communication with a valid application enclave running a particular source code version, such as via a remote attestation that results in a shared cryptographic secret (e.g., a Diffie-Hellman key exchange) for encrypting future messages.

[0077] 6 illustrates an example flow diagram (e.g., process 600) for providing an application trusted execution environment, such as via a computing platform, according to certain aspects of the present disclosure. For purposes of explanation, the example process 600 is described herein with reference to one or more of the figures described above. Further, for purposes of explanation, the blocks of the example process 600 are described herein as occurring sequentially or linearly. However, multiple instances of the example process 600 may occur in parallel, overlap in time, occur approximately simultaneously, or occur in an order different from that illustrated in the process 600. Additionally, the blocks of the example process 600 need not be performed in the order shown, and / or one or more of the blocks of the example process 600 may not be performed.

[0078] At step 602, attestation of each application enclave of the plurality of application enclaves for the plurality of applications may be performed. According to one aspect, performing attestation of each application enclave includes determining, by the load balancer and for each application enclave, cryptographic information including at least one of a shared cryptographic key, cryptographic credentials, or hashed authentication of an application configured to be executed by the plurality of application enclaves. According to one aspect, performing attestation of each application enclave includes verifying the validity or authenticity of each of the application enclaves based on the cryptographic information. At step 604, a request may be received from a client. According to one aspect, receiving the request includes receiving an API request type corresponding to the request.

[0079] At step 606, a load balancer of the plurality of load balancers may be selected to forward the request to the plurality of application enclaves. According to one aspect, selecting a load balancer includes initializing each of the plurality of load balancers as a stateless application. According to one aspect, selecting a load balancer includes determining the plurality of load balancers based on Domain Name System (DNS) records. At step 608, the request from the load balancer may be routed by the load balancer's enclave server to an application enclave of the plurality of application enclaves according to a sensitivity level for execution of the application of the plurality of applications in the application trusted execution environment. According to one aspect, routing the request from the load balancer to the application enclave includes determining visibility of client information associated with the request according to a sensitivity level of the request based on secured environment parameters.

[0080] According to one aspect, process 600 may further include performing, by the client, another attestation of the load balancer based on the attestation report. According to one aspect, process 600 may further include performing, by the load balancer, user input sanitization. According to one aspect, process 600 may further include encrypting information associated with the request via an encryption mechanism shared with at least one of the plurality of application enclaves based on a sensitivity level and before sending the request to at least one of the plurality of application enclaves. According to one aspect, process 600 may further include selecting an application enclave based on a sensitivity level or an application. According to one aspect, process 600 may further include verifying a response from the application enclave as authentic before returning the response to the client.

[0081] According to one aspect, process 600 may further include determining, by an issuer of the non-transferable credential, an expiration date for the non-transferable credential. According to one aspect, process 600 may further include determining, by an issuer of the non-transferable credential, to enforce revocation of the key set of the non-transferable credential. According to one aspect, process 600 may further include determining a sensitivity level of the request associated with the secured environment parameters. According to one aspect, determining a sensitivity level of the request includes determining, based on the secured environment parameters, whether the request or information associated with the request requires encryption (e.g., depending on whether encryption is required).

[0082] 7 is a flowchart illustrating steps in a method 700 for identifying and assigning a sensitivity level to a service request from a user in a trusted execution environment, according to certain aspects of the present disclosure. For purposes of explanation, method 700 is described herein with reference to one or more of the figures described above. Further, for purposes of explanation, the blocks of method 700 are described herein as occurring sequentially or linearly. However, multiple instances of method 700 may occur in parallel, overlap in time, occur approximately simultaneously, or occur in an order different from the order illustrated in method 700. Additionally, the blocks of method 700 need not be performed in the order shown, and / or one or more of the blocks of method 700 need not be performed.

[0083] Step 702 involves receiving a request from a client device having a user to perform a service for an application running on the client device.

[0084] Step 704 includes identifying a sensitivity level in the request based on a desired accessibility to the requested information. In some embodiments, step 704 includes identifying one of private information of the user or a geolocation of the client device and a privacy setting selected by the user in an application running on the client device. In some embodiments, step 704 includes receiving the sensitivity level from the client device.

[0085] Step 706 includes determining a degree of encryption for transmitting the request to a first dedicated server hosting the application running on the client device. In some embodiments, step 706 includes selecting a bit length of an encryption key. In some embodiments, step 706 includes encrypting the request based on the degree of encryption by generating an encryption key and providing the encryption key to the first dedicated server. In some embodiments, step 706 includes encrypting the request based on the degree of encryption, including using a shared secret between the network server and the first dedicated server.

[0086] Step 708 includes routing the request to a first dedicated server for processing. In some embodiments, step 708 includes determining that a return time for a request response from the first dedicated server is less than a preselected threshold. In some embodiments, step 708 includes routing the request to a second dedicated server hosting an application running on the client device when the return time of the request response from the second dedicated server is less than the return time of the first dedicated server. In some embodiments, step 708 includes authenticating the client device using a shared secret between the client device and the network server. In some embodiments, step 708 includes returning a response to the request from the first dedicated server to a client device having the user.

[0087] Hardware Overview 8 is a block diagram illustrating an example computer system 800 in which aspects of the subject technology may be implemented. In certain aspects, computer system 800 may be implemented using hardware or a combination of software and hardware, whether in a dedicated server, integrated in another entity, or distributed across multiple entities.

[0088] Computer system 800 (e.g., a server and / or client) includes a bus 808 or other communication mechanism for communicating information and a processor 802 coupled with bus 808 for processing information. By way of example, computer system 800 may be implemented with one or more processors 802. Each of the one or more processors 802 may be a general-purpose microprocessor, a microcontroller, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a programmable logic device (PLD), a controller, a state machine, gated logic, a discrete hardware component, or any other suitable entity capable of performing computations or other manipulations of information.

[0089] Computer system 800 may include, in addition to hardware, code that creates an execution environment for computer programs in question, e.g., code constituting processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of these, stored in associated memory 804, such as random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable PROM (EPROM), registers, a hard disk, a removable disk, a CD-ROM, a DVD, or any other suitable storage device coupled to bus 808 for storing information and instructions executed by processor 802. Processor 802 and memory 804 may be supplemented by, or incorporated in, special purpose logic circuitry.

[0090] The instructions may be stored in memory 804 and implemented in one or more computer program products, i.e., encoded on a computer-readable medium for execution by computer system 800, or in one or more modules of computer program instructions encoded on a computer-readable medium for controlling the operation of computer system 800, according to any manner known to those skilled in the art, including, but not limited to, computer languages ​​such as data-oriented languages ​​(e.g., SQL, dBase), system languages ​​(e.g., C, Objective-C, C++, Assembly), architecture languages ​​(e.g., Java, .NET), and application languages ​​(e.g., PHP, Ruby, Perl, Python). The instructions may also be implemented in a computer language such as an array language, an aspect-oriented language, an assembly language, an authoring language, a command line interface language, a compiled language, a concurrent language, a brace language, a dataflow language, a data structure language, a declarative language, an esoteric language, an extension language, a fourth generation language, a functional language, an interactive mode language, an interpreted language, an iterative language, a list-based language, a little language, a logic-based language, a machine language, a macro language, a metaprogramming language, a multi-paradigm language, numerical analysis, a non-English-based language, an object-oriented class-based language, an object-oriented prototype-based language, an offside rules language, a procedural language, a reflective language, a rule-based language, a scripting language, a stack-based language, a synchronization language, a syntax processing language, a visual language, a worth language, and an xml-based language. The memory 804 may also be used for storing temporary variables or other intermediate information during execution of instructions by the processor 802.

[0091] A computer program as discussed herein does not necessarily correspond to a file in a file system. A program can be stored as part of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, subprograms, or portions of code). A computer program can be deployed to run on one computer or on multiple computers located at one site or distributed across multiple sites and interconnected by a communications network. The processes and logic flows described herein can be implemented by one or more programmable processors executing one or more computer programs to perform functions by manipulating input data and generating output.

[0092] Computer system 800 further includes a data storage device 806, such as a magnetic or optical disk, coupled to bus 808 for storing information and instructions. Computer system 800 may be coupled to various devices via input / output module 810. Input / output module 810 may be any input / output module. An exemplary input / output module 810 includes a data port, such as a USB port. Input / output module 810 is configured to connect to a communications module 812. An exemplary communications module 812 includes a networking interface card, such as an Ethernet card and a modem. In certain aspects, input / output module 810 is configured to connect to multiple devices, such as input devices 814 and / or output devices 816. Exemplary input devices 814 include a keyboard and a pointing device, such as a mouse or trackball, by which a user can provide input to computer system 800. Other types of input devices may also be used to provide interaction with a user, such as a tactile input device, a visual input device, a voice input device, or a brain-computer interface device. For example, feedback provided to the user may be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback, and input from the user may be received in any form, including acoustic, speech, tactile, or electroencephalographic input. Exemplary output devices 816 include display devices, such as LCD (liquid crystal display) monitors, for displaying information to the user.

[0093] According to one aspect of the present disclosure, the system described above may be implemented using computer system 800 in response to processor 802 executing one or more sequences of one or more instructions contained in memory 804. Such instructions may be read into memory 804 from another machine-readable medium, such as data storage device 806. Execution of the sequences of instructions contained in main memory 804 causes processor 802 to perform the process steps described herein. One or more processors in a multi-processing configuration may also be employed to execute the sequences of instructions contained in memory 804. In alternative aspects, hard-wired circuitry may be used in place of or in combination with software instructions to implement various aspects of the present disclosure. Thus, aspects of the present disclosure are not limited to any specific combination of hardware circuitry and software.

[0094] Various aspects of the subject matter described herein may be implemented in a computing system that includes a back-end component, such as a data server, a middleware component, such as an application server, or a front-end component, such as a client computer having a graphical user interface or a web browser, through which a user can interact with an implementation of the subject matter described herein, or any combination of one or more such back-end, middleware, or front-end components. The components of the system may be interconnected by any form or medium of digital data communication, such as a communications network. The communications network may include, for example, any one or more of a LAN, a WAN, the Internet, etc. Furthermore, the communications network may include, for example, any one or more of the following network topologies, including, but not limited to, a bus network, a star network, a ring network, a mesh network, a star-bus network, a tree or hierarchical network, etc. The communications module may be, for example, a modem or an Ethernet card.

[0095] Computer system 800 may include clients and servers. Clients and servers are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. Computer system 800 may be, for example, without limitation, a desktop computer, a laptop computer, or a tablet computer. Computer system 800 may also be embedded in another device, for example, without limitation, a mobile phone, a PDA, a mobile audio player, a global positioning system (GPS) receiver, a video game console, and / or a television set-top box.

[0096] The terms "machine-readable storage medium" or "computer-readable medium," as used herein, refer to any medium or media that participate in providing instructions to processor 802 for execution. Such media may take many forms, including, but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical or magnetic disks, such as data storage device(s) 806. Volatile media include dynamic memory, such as memory 804. Transmission media include coaxial cables, copper wire, and fiber optics, including the wires that comprise bus 808. Common forms of machine-readable media include, for example, floppy disks, flexible disks, hard disks, magnetic tape, any other magnetic media, CD-ROMs, DVDs, any other optical media, punch cards, paper tape, any other physical media with a pattern of holes, RAM, PROM, EPROM, FLASH EPROM, any other memory chip or cartridge, or any other medium from which a computer can read. The machine-readable storage medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter that affects a machine-readable propagated signal, or a combination of one or more of these.

[0097] The techniques described herein may be implemented as methods performed by a physical computing device, as one or more non-transitory computer-readable storage media that store instructions that, when executed by a computing device, cause the method to be performed, or as a physical computing device specially configured with a combination of hardware and software that causes the method to be performed.

[0098] As used herein, the phrase "at least one of" preceding a list of items with the term "and" or "or" separating any of the items modifies the list as a whole, not each member (i.e., each item) of the list. The phrase "at least one of" does not require the selection of at least one item; rather, the phrase allows for the inclusion of at least one of any one of the items, and / or at least one of any combination of the items, and / or at least one of each of the items. By way of example, the phrases "at least one of A, B, or C" or "at least one of A, B, or C" refer to A only, B only, or C only, any combination of A, B, and C, and / or at least one of each of A, B, and C, respectively.

[0099] To the extent that terms like "include," "have," and the like are used in the description or claims, such terms are intended to be inclusive in the same manner as the word "comprise" is interpreted as "comprise" when employed as a transitional term in a claim. The word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments.

[0100] Reference to an element in the singular is not intended to mean "one and only one," but rather "one or more," unless specifically stated otherwise. All structural and functional equivalents to the elements of the various configurations described throughout this disclosure that are known, or that later become known, to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the subject art. Furthermore, nothing disclosed herein is intended to be dedicated to the public, regardless of whether such disclosure is expressly set forth in the description above.

[0101] While this specification contains many details, these should not be construed as limitations on the scope that may be claimed, but rather as descriptions of particular implementations of the subject matter. Certain features described herein in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented separately in multiple embodiments or in any suitable subcombination. Furthermore, although features may be described above as acting in a particular combination and initially claimed as such, in some cases one or more features from a claimed combination may be deleted from the combination, rendering the claimed combination the subject of a subcombination or a variation of the subcombination.

[0102] Although the subject matter herein has been described in terms of particular aspects, other aspects may be implemented and are within the scope of the following claims. For example, while operations are depicted in the figures in a particular order, this should not be understood as requiring such operations to be performed in the particular order or sequence shown, or that all illustrated operations must be performed to achieve desirable results. Acts recited in the claims may be performed in a different order and still achieve desirable results. As an example, the processes depicted in the accompanying figures do not necessarily require the particular order or sequence shown to achieve desirable results. In certain situations, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system components in the above-described aspects should not be understood as requiring such separation in all aspects, and it should be understood that the described program components and systems may generally be integrated in a single software product or packaged in multiple software products. Other variations are within the scope of the following claims.

Claims

1. 1. A computer-implemented method for providing an application trusted execution environment, the method comprising: performing attestation of a first application enclave from a plurality of application enclaves for a plurality of applications to gain trust in the execution of the application enclave for the plurality of applications; receiving a request from a client; selecting a first load balancer from a plurality of load balancers to forward the request to the application enclave; and routing, by an enclave server of the load balancer, the request from the load balancer to an application enclave among the application enclaves for execution of an application among the plurality of applications in the application trusted execution environment.

2. 2. The computer-implemented method of claim 1, wherein the request from the client includes storing public data, further comprising: assigning a low sensitivity level to the request; storing the public data in a database; and enabling a server operator in the database to read and modify the public data.

3. 2. The computer-implemented method of claim 1, wherein the request from the client includes an account balance, further comprising: assigning a high sensitivity level to the request; and storing the account balance in an encrypted Merkle tree accessible to authorized application enclaves.

4. performing the attestation of a first application enclave; determining, by the first load balancer and for each application enclave, cryptographic information including at least one of a shared cryptographic key, cryptographic credentials, or hashed authentication of an application configured to be executed by the application enclave; and verifying the validity or authenticity of each of the application enclaves based on the cryptographic information.

5. The computer-implemented method of claim 1 , wherein receiving the request comprises receiving an application layer request type corresponding to the request.

6. Selecting the first load balancer comprises: initializing each of the load balancers as a stateless application; and determining the load balancer based on a Domain Name System (DNS) record.

7. 10. The computer-implemented method of claim 1, further comprising determining a sensitivity level of the request based on a trusted environment parameter depending on whether the request or information associated with the request requires encryption.

8. 7. The computer-implemented method of claim 6, wherein routing the request from the first load balancer to the first application enclave includes determining visibility of client information associated with the request according to a sensitivity level of the request based on trusted environment parameters.

9. encrypting, by the first load balancer, a request body of the request at the application layer based on corresponding shared cryptographic information with each of the application enclaves; performing, by the client, another attestation of the first load balancer based on the attestation report; The computer-implemented method of claim 1 , further comprising: performing, by the first load balancer, user input sanitization.

10. encrypting information associated with the request via an encryption mechanism shared with the at least one of the application enclaves based on a sensitivity level and before sending the request to the at least one of the application enclaves; selecting the first application enclave based on the sensitivity level or type of application; verifying a response from the first application enclave as authentic; The computer-implemented method of claim 1 , further comprising: encrypting the response before returning the response to the client.

11. 1. A system for providing an application trusted execution environment, comprising: one or more processors; and a memory storing instructions that, when executed by the one or more processors, cause the one or more processors to: performing attestation of each application enclave of a plurality of application enclaves for a plurality of applications; receiving a request from a client; selecting a load balancer from a plurality of load balancers to forward the request to the plurality of application enclaves; encrypting information associated with the request via an encryption mechanism shared with the at least one of the plurality of application enclaves before sending the request to the at least one of the plurality of application enclaves; and routing, by an enclave server, the request from the load balancer to an application enclave among the plurality of application enclaves for execution of the application among the plurality of applications in the application trusted execution environment.

12. 12. The system of claim 11, wherein the instructions causing the one or more processors to perform the attestation of each application enclave cause the one or more processors to determine, by the load balancer and for each application enclave, a shared encryption key for encrypting and authenticating requests from each application enclave.

13. 12. The system of claim 11, wherein the one or more processors further execute instructions to verify that hash authentication of applications configured to be executed by the multiple application enclaves matches an expected version.

14. 12. The system of claim 11, wherein the instructions causing the one or more processors to receive the request cause the one or more processors to receive a corresponding application programming interface (API) request type.

15. 12. The system of claim 11, further comprising a stored sequence of instructions that, when executed by the one or more processors, cause the one or more processors to determine a sensitivity level of the request based on trusted environment parameters as a function of whether the request or information associated with the request requires encryption.

16. The instructions for causing the one or more processors to perform the selecting of the load balancer may include causing the one or more processors to: initializing each of the plurality of load balancers as a stateless application; determining the plurality of load balancers based on Domain Name System records; 12. The system of claim 11, wherein routing the request from the load balancer to the application enclave includes determining visibility of client information associated with the request according to a sensitivity level of the request based on trusted environment parameters.

17. 12. The system of claim 11, further comprising a stored sequence of instructions that, when executed by the one or more processors, cause the one or more processors to perform encrypting, by the load balancer, a request body of a request to an application layer based on corresponding shared cryptographic information with each of the plurality of application enclaves.

18. a sequence of instructions stored therein, the instructions, when executed by the one or more processors, causing the one or more processors to: performing, by the client, another attestation of the load balancer based on the attestation report; The system of claim 11 , further comprising: causing the load balancer to perform user input sanitization.

19. a sequence of instructions stored therein, the instructions, when executed by the one or more processors, causing the one or more processors to: selecting the application enclave based on a sensitivity level or type of application; and verifying the response from the application enclave as authentic before returning the response to the client.

20. 1. A non-transitory computer-readable storage medium comprising stored instructions that, when executed by one or more processors, cause the one or more processors to perform operations for providing an application trusted execution environment, the operations comprising: performing attestation of each application enclave of a plurality of application enclaves for a plurality of applications; receiving a request from a client; selecting a load balancer from a plurality of load balancers to forward the request to the plurality of application enclaves; encrypting information associated with the request via an encryption mechanism shared with the at least one of the plurality of application enclaves before sending the request to the at least one of the plurality of application enclaves; selecting an application enclave from the plurality of application enclaves based on the application; routing, by an enclave server, the request from the load balancer to the application enclave for execution of an application of the plurality of applications in the application trusted execution environment; and verifying the response from the application enclave as authentic before returning the response to the client.

Images