SECURE ENVIRONMENT FOR OPERATIONS ON PRIVATE DATA

The techniques disclosed herein provide a secure control plane (SCP), which in turn provides an isolated secure execution environment for a data plane (DP). Any arbitrary business logic can execute within the DP, and all sensitive data traversing the SCP and entering the DP is encrypted. Split keys generated outside the DP are assembled within, and only within, the DP, where they are used to decrypt sensitive data, enabling the business logic to perform computations using the sensitive data within the secure execution environment. The DP also provides attestation for the business logic executing within the DP, enabling outside parties to verify that the deployed business logic matches published logic. In the event of proprietary logic that is not published, techniques are also disclosed herein that enable verification that proprietary business logic deployed on the DP adheres to security policies.

FIELD OF THE DISCLOSURE

This disclosure relates to a secure computing environment and, more particularly, to techniques for improving the security and privacy of using Trusted Execution Environments (TEEs) for operations on private and/or sensitive data, implemented in a cloud or another suitable environment.

BACKGROUND

As the number and complexity of tasks executing in cloud computing environments increases, so do concerns regarding security and protection of privacy, particularly when multiple parties are involved in a shared task. For example, several parties that do not trust each other can jointly process data where one party controls one subset of the data, and another party controls another part of the data. It is desirable for the computing environment to protect sensitive information from extraction by any one party, protect the code that operates on the data from tampering, etc.

SUMMARY

The techniques disclosed herein provide a secure control plane (SCP), which in turn provides an isolated secure execution environment for a data plane (DP). Any arbitrary business logic can execute within the DP, and all sensitive data traversing the SCP and entering the DP is encrypted. Split keys generated outside the DP are assembled within, and only within, the DP, where they are used to decrypt sensitive data, enabling the business logic to perform computations using the sensitive data within the secure execution environment. The DP also provides attestation for the business logic executing within the DP, enabling outside parties to verify that the deployed business logic matches published logic. In the event of proprietary logic that is not published, techniques are also disclosed herein that enable verification that proprietary business logic deployed on the DP adheres to security policies.

DETAILED DESCRIPTION OF THE DRAWINGS

As the number of workflows utilizing first-party (1P) data in the cloud grows, new trust, privacy, and security paradigms are being considered to advance the guarantees given to data owners. These include using Trusted Execution Environments (TEEs), such as enclaves, confidential computing, and Secure Multi-Party Computation (MPC). The techniques discussed below improve data security in TEEs running implemented in the cloud or another suitable computing environment.

Further, techniques are also disclosed for enabling privacy and security guarantees concerning proprietary business logic code, i.e., code that cannot be audited by a third party, to be given within a TEE implemented on a cloud service, even without disclosing the actual business logic.

The secure control plane (sometimes referred to herein as “SCP”), described herein provides a non-observable secure execution environment where a service can be deployed. In particular, arbitrary business logic (e.g., code for an application) providing the service can be executed within the secure execution environment in order to provide the security and privacy guarantees needed by the workflow, with no computation at runtime observable by any party. The state of the environment is opaque even to the administrator of the service, and the service can be deployed on any supported cloud.

As one example, two clients producing data, client 1 and client 2, may wish to combine the data streams they receive from their respective customers, such that the clients can generate quantitative metrics related to these customers, where the quantitative metrics cannot be derived from their individual datasets. As a more particular example, client 1 can be a retailer that has data indicative of customer transactions, and client 2 can be an analytics engine capable of measuring the effectiveness of advertisement campaigns for products offered by the retailer, for example.

Client 2 may provide a service with algorithms that client 2 claims will perform data analysis securely. However, the client 1 may not wish to expose its customer data to client 2 in a manner that would potentially allow the data to be exfiltrated or used in a manner that does not adhere to privacy and security guarantees of client 1. Client 1 therefore would like to ensure that (1) its customer data cannot be exfiltrated by client 2 or any other party, and (2) the logic being used to analyze the customer data adheres to the security requirements of client 2. The techniques disclosed herein provide a secure execution environment in which the business logic executes, such that sensitive data analyzed by the business logic remains encrypted everywhere except within the secure execution environment, and provide attestation such that any party can ensure that the logic running within the secure execution environment performs as guaranteed.

Generally speaking, the service performing the computation (i.e., processing an event or request using business logic) is split between a data plane (DP) and a secure control plane (SCP). The business logic specific for the computation is hosted within the DP, where the DP is within a TEE, also referred to herein as an enclave. The business logic may be provided to the DP as a container, where a container is a software package containing all of the necessary elements to run the business logic in any environment. The container may, for example, be provided to the SCP by the business logic owner. Functionally, the SCP provides a secure execution environment and facilities to deploy and operate the DP at scale, including managing cryptographic keys, buffering requests, keeping track of the privacy budget, accessing storage, orchestrating a policy-based horizontal autoscaling, and more. The SCP execution environment isolates the DP from the specifics of the cloud environment, allowing for the service to be deployed on any supported cloud vendor without changes on the DP. Both DP and SCP work together by communicating through an Input/Output (I/O) Application Programming Interface (API), also referred to herein as a Control Plane I/O API, or CPIO API.

In an example implementation, all data traversing the SCP is always encrypted, and only the DP has access to the decryption keys. For example, the SCP can facilitate a trusted data exchange, in which data from multiple parties, which may not trust each other, can be joined, but where none of these multiple parties has access to the keys for decrypting this data. Further, the decryption keys, when outside the DP, may be bit-split, such that only the DP can assemble the decryption keys within the TEE. Depending on the desired application, the output from the DP can be redacted or aggregated in such a way that the output can be shared and no individual user's data can be identified or exfiltrated.

The SCP provides several privacy, trust, and security guarantees. With regard to privacy, services using the SCP can provide guarantees that no stakeholder (e.g., a device operated by a client, the cloud platform, a third party) can act alone to access or exfiltrate cleartext (i.e., non-encrypted), sensitive information, including the administrator of the SCP deployment. Further, with regard to trust, the DP is running in a secure execution environment with a trusted state at the time the enclave is started. For example, the SCP may be implemented using technologies to guarantee process isolation in hardware either, including memory encryption and or memory address space segmentation, and a chain of trust from boot, using a Trusted Platform Module (TPM) or Virtual Trusted Platform Module (vTPM), in accordance with Secure Boot standards, and/or using a trusted and/or certified operating system (OS). Starting from an audited codebase and a reproducible build, cryptographic attestation is used to prove the DP binary identity and provenance at runtime (as will be discussed in more detail below) to a key management service (KMS) which is configured to release cryptographic keys only to verified enclaves. As a result, any tampering of the DP image results in a system that is unable to decrypt any data. The cloud provider is implicitly trusted given the strong incentives the cloud provider has to guarantee its Terms of Service (ToS) guarantees. With regard to security, the secure execution environment is non-observable. The memory of the secure execution environment is encrypted or otherwise hardware-protected from access from other processes. Core dumps are not possible in an example implementation. All data is encrypted in transit and at rest, and all I/O from/to the DP is encrypted. No human has access to the private keys in cleartext (e.g., KMS is locked-down, keys are split, and keys are only available within the DP, which is within the secure execution environment.

The SCP distributes trust in a way that three stakeholders need to cooperate in order to exfiltrate cleartext user event data. The SCP also uses the distributed trust model to guarantee that two stakeholders need to cooperate to tamper with the privacy budget service. Distributed trust is used for both event decryption and a privacy budget service. Regarding event decryption, the private key needed to decrypt events received at the SCP is generated in a secure environment and bit-split between at least two KMSs, each under the control of an independent Trusted Party. Each Trusted Party, for example, can further encrypt their respective key split with a KMS key owned by the Trusted Party in the cloud provider's KMS. The KMSs are configured to only release key material to a DP that matches a specific hash. If the DP is tampered with, the key splits will not be released. In such a scenario, the service can be launched but will not be able to decrypt any event. Similarly, the privacy budget service may be distributed between two independent Trusted Parties and may use transactional semantics to guarantee that both Trusted Parties' budgets match, which allows for the detection of budget tampering.

The SCP, as will be discussed with reference toFIG.2B, also provides mechanisms for attesting that any business logic running on the DP corresponds to the publicly released code, allowing other parties to verify the business logic being used to analyze sensitive data. The full codebase for the business logic (with the exception of scenarios described with reference toFIG.5involving proprietary business logic) is available to all stakeholders to examine and audit. Builds are reproducible, and any stakeholder can build the DP container. Building the DP container generates a set of cryptographic hashes (e.g., Platform Configuration Registers (PCRs)). All parties can therefore verify that the deployed products match the published codebase by comparing the hashes. The Trusted Parties publish the hashes to parties requesting to verify the built logic. KMSs, for example, are configured to only release key material to images matching the hashes generated from building the published logic. This guarantees that the private keys to decrypt sensitive information are only available to the images that correspond to a specific commit of a specific repository.

Turning to an example computing system that can implement the SCP of this disclosure,FIG.1illustrates an example computing system100. The computing system100includes a client computing device102(also referred to herein as the client device102), coupled to a cloud platform122(also referred to herein as the cloud122) via a network120. The network120in general can include one or more wired and/or wireless communication links and may include, for example, a wide area network (WAN) such as the Internet, a local area network (LAN), a cellular telephone network, or another suitable type of network or combination of networks. While the examples of this disclosure primarily refer to a cloud-implemented architecture, it should be understood that the techniques disclosed herein, including techniques for providing a secure execution environment in which to process sensitive data, for generating, splitting, and distributing keys, and for providing a mechanism by which to verify proprietary business logic, can be applied in non-cloud systems as well.

The client device102may be a portable device such as a smart phone or a tablet computer, for example. The client device102may also be a laptop computer, a desktop computer, a personal digital assistant (PDA), a wearable device such as a smart glasses, or other suitable computing device. The client device102may include a memory106, one or more processors (CPUs)104, a network interface114, a user interface116, and an input/output (I/O) interface118. The client device102may also include components not shown inFIG.1, such as a graphics processing unit (GPU). The client device102may be associated with a service user, who is an end user of the service provided by the SCP, discussed below. The end user operates the client device102(or, more specifically, the browser or application on the client device102) that transmits requests/events to the service. To send a request or event to the service, the client device102encrypts the request/event using a public key, which the client device102can retrieve from a public key repository (e.g., a public key repository server178). The client device102is exemplary only. As discussed below, the cloud platform122may receive incoming events and/or requests from the client device102, from a browser/application/client process executing on the client device102, or from another computing device issuing requests on behalf of the client device102or forwarding requests from the client device102. Further, while only one client device is illustrated inFIG.1, the computing system100may include multiple client devices capable of communicating with the cloud platform122.

The network interface114may include one or more communication interfaces such as hardware, software, and/or firmware for enabling communications via a cellular network, a WiFi network, or any other suitable network such as the network120. The user interface116may be configured to provide information, such as responses to requests/events received from the cloud platform122to the user. The I/O interface118may include various I/O components (e.g., ports, capacitive or resistive touch sensitive input panels, keys, buttons, lights, LEDs). For example, the I/O interface118may be a touch screen.

The memory106may be a non-transitory memory and may include one or several suitable memory modules, such as random access memory (RAM), read-only memory (ROM), flash memory, other types of persistent memory, etc. The memory106may store machine-readable instructions executable on the one or more processors104and/or special processing units of the client device102. The memory106also stores an operating system (OS)110, which can be any suitable mobile or general-purpose OS. In addition, the memory106can store one or more applications that communicate data with the cloud platform122via the network120. Communicating data can include transmitting data, receiving data, or both. For example, the memory106may store instructions for implementing a browser, online service, or application that requests data from/transmits data to an application (i.e., business logic) implemented on the DP of a secure execution environment on the cloud platform122, discussed below.

The cloud platform122may include a plurality of servers associated with a cloud provider to provide cloud services via the network120. The cloud provider is an owner of the cloud platform122where an SCP126is deployed. While only one cloud platform is illustrated inFIG.1, the SCP126may be deployed on multiple cloud platforms, even if those cloud platforms are operated by different cloud providers. The servers providing the cloud platform122may be distributed across a plurality of sites for improved reliability and reduced latency. Individual servers or groups of servers within the cloud platform122may communicate with the client device102and with each other via the network120. Example servers that may be included in the cloud platform122are discussed in further detail below. While not illustrated for each server inFIG.1, each server included in the cloud platform122may include one or more processors, similar to the processor(s)104, adapted and configured to execute various software stored in one or more memories, similar to the memory106. The servers may further include databases, which may be local databases stored in memory of a particular server or network databases stored in network-connected memory (e.g., in a storage area network). The servers also may include network interfaces and I/O interfaces, similar to the interfaces114and118, respectively. Further, it should be understood that while certain components are described as an individual server, generally speaking, the term “server” may refer to one or more servers. Moreover, while functions are generally described as being performed by separate servers, some functions described herein may performed by the same server.

The cloud platform122includes the SCP126, which includes a TEE124. The TEE124is a secure execution environment where the DP128is isolated. A TEE, such as the TEE124, is an environment that provides execution isolation and offers a higher level of security than a regular system. The TEE124may utilize hardware to enforce the isolation (referred to as confidential computing). The cloud provider is considered the root of trust of the SCP126, abiding by the Terms of Service (ToS) agreement of the cloud platform122. The hardware manufacturer of the servers providing the TEE124also have ToS guarantees, and therefore also provide additional layers of trust. The SCP126also utilizes techniques to guarantee that the state at boot time is safe, including using a minimalistic OS image recommended by the cloud provider, and using a TPM/vTPM-based secure boot sequence into that OS image.

One or more servers of the cloud platform122perform control plane (CP) functions (i.e., to support the SCP126), and one or more servers perform data plane (DP) functions. For example, CP functions including key management and privacy budgeting services can be distributed across more than one Trusted Party. All functions of the DP128are carried out by processes within the TEE124. Depending on the implementation, there may be more than one TEE per DP server. The TEE124may be deployed and operated by an administrator. The administrator can audit the logic to be implemented on the DP128and verify against a hash of the binary image to deploy the logic142. On the CP, there may be a front end server or process134that receives external requests/event indications (e.g., from the client device102), buffers requests/events until they can be processed by the DP128, and forwards received requests to the DP128. Generally speaking, as used herein, a request may also refer to an event, or may include one or more events, unless otherwise noted. In some implementations, there is a third party server136between the client device102and the SCP126. The third party server136(which may include one or more servers, and might or might not be hosted on the cloud platform122) may be responsible for receiving requests (which are encrypted by the client device102) from the client device102and later dispatching the encrypted requests to the SCP126. In some cases, the third party is the administrator of the service. The third party server136does not have keys with which to decrypt the requests. The third party server136may, for example, aggregate requests into batches and store the batches (e.g., on cloud storage160). The third party server136or cloud storage server160may notify the front end server134that requests are ready to be processed, and/or the front end server134may subscribe to notifications that are pushed to the front end server134when batches are added to the cloud storage160.

The DP128includes a server (which may include one or more servers), which includes one or more processors138(similar to the processor(s)104), and one or more memories140(similar to the memory106). The memory140includes business logic142(also referred to as the logic142), which may be executed by the processor138. The business logic142is for implementing whichever application or service is being deployed on the TEE124. The memory140also may store a key cache146, which stores cryptographic keys for encrypting and decrypting communications. Further, the memory140includes a CPIO API144, which includes a library of functions for communicating with other elements of the cloud platform122, including components on the CP of the SCP126. The CPIO API144can be configured to interface with any cloud platform provided by cloud provider. For example, in a first deployment, the SCP126may be deployed to a first cloud platform provided by a first cloud provider. The DP128hosts the particular business logic142, and the CPIO API144facilitates communications between the logic142and the first cloud platform. In a second deployment, the SCP126may be deployed to a second cloud platform provided by a second cloud provider. The DP128can host the same business logic142as the first deployment, and the CPIO API144is configured to facilitate communications between the logic142and the second cloud platform. Thus, the SCP126can be deployed to different cloud platforms without editing the underlying business logic142, and only configuring the CPIO API144to interface with the particular cloud platform.

There may be additional CP-level services provided by servers of the cloud platform122that support the SCP126. For example, a verifier server148may provide a verifier module capable of verifying whether the business logic142conforms to a security policy, as will be discussed below with reference toFIG.5. While not explicitly illustrated inFIG.1, the verifier module can operate within the TEE124. As another example, a privacy budget service server152may implement a privacy budget service that verifies whether the privacy budget for a user or device has been exhausted. One or more privacy budget services, additionally or alternatively, may be implemented by Trusted Parties, as discussed with reference toFIG.2B.

Additionally, the cloud platform122may include other servers and databases in communication with the SCP126, as described in the following paragraphs. These servers may facilitate the CP functions of the SCP126. In particular, CP functions may be distributed across several servers, as will be discussed below. Processes of the DP128, however, remain within the TEE124and are not distributed outside of the TEE124.

Cloud storage160may store encrypted batches of requests, as mentioned above, before the encrypted batches are received by the front end server134. The cloud storage160may also be used to store responses, after the DP128has processed a received request, or to perform storage functions of other components of the cloud platform122. Queue162may be used by the front end server134to store pending requests before they can be analyzed by the DP128. For example, after receiving a request from the client device102, the front end server134can receive the request and temporarily store the pending request in the queue162until the DP128is ready to process the request. As another example, after receiving a notification that a batch of requests from the third party server136is stored within the cloud storage160, the front end134can retrieve the batch and place the batch in the queue162where the batch awaits analysis by the DP128.

The KMS service164provides a KMS, which generates, deletes, distributes, replaces, rotates, and otherwise manages cryptographic keys. The functions of the KMS164may be executed by one or more servers. Thus, the KMS164may be a cloud KMS. The Trusted Party 1 server166and the Trusted Party 2 server172are servers associated with a Trusted Party 1 and a Trusted Party 2, respectively, that provide the functionality of each Trusted Party. WhileFIG.1illustrates only two Trusted Parties, the cloud platform122may include multiple Trusted Parties. Each Trusted Party may manage the privacy budget, and can also audit the logic142implemented on the DP128to verify the build product against the hash of the published logic. Trusted Parties own the creation and management of the asymmetric keys used for encryption and decryption of user data. The Trusted Parties may securely generate keys and publish public keys to the world. Private keys, as will be discussed in detail with reference toFIG.4, can be bit-split into two parts (one split under the control of each Trusted Party, although any number of N-splits can also be supported, e.g., in the case where there are N Trusted Parties). An envelope-encryption technique may be used in which each Trusted Party encrypts its split for each key with a KMS's symmetric key and saves the encrypted split in their repository. Envelope encryption allows for rotation of the envelope without necessarily rotating the key within the envelope. Public keys may be stored and managed by a public key repository server178. Additionally or alternatively, the KMS server164may manage public keys.

The computing system100may also include public security policy storage180, which may be located on or off the cloud platform122. The public security policy storage180stores security policies such that the security policies are accessible by the public (e.g., by the client device102, by components of the cloud platform122). A security policy (also referred to herein as a policy) describes what actions or fields are allowed in order to compose the output of a service. A policy can also be described as a machine-readable and machine-enforceable Privacy Design Document (PDD). Policies will further be described with reference toFIG.5.

Referring next toFIG.2A, an example architecture200A is illustrating depicting connections between components and software elements of the computing system100. The client device102can retrieve public keys (e.g., from the public key repository server178) in order to address requests to the service being implemented on the DP128(i.e., by the business logic142). For example, the client device102may initiate a request to access content provided by the service, or may issue an event including user behavior data.

Encrypted requests from the client device102are received first by a front end module234(i.e., a module implemented by the front end server134) of the SCP126. In some implementations, the requests are first received by a third party that batches the requests before notifying the front end234(or causing the front end234to be notified). The notification to the front end234may contain the location within the cloud storage160(e.g., the location of a cloud storage bucket) where the encrypted requests reside, and may contain an indication of where output from the DP128should be outputted (e.g., by including metadata indicating such information). In such cases, the front end234may retrieve the encrypted requests from the cloud storage160. In any event, the front end234passes encrypted requests to the DP128using functions defined by the CPIO API144. The front end234may store encrypted requests in the queue162until the DP128is ready to process the requests and retrieves the requests from the queue162. The DP128decrypts the requests and processes the requests in accordance with the business logic142. Decrypting the requests may include communicating with the KMS164(e.g., a cloud KMS implemented by distributed servers) to retrieve and assemble private keys for decrypting the requests, and/or with Trusted Parties, as inFIG.2B. These are examples of integration of cloud native services with the SCP126, but the idea extends to other cloud infrastructure and services, with the SCP126mediating between these services and the business logic142by using the CPIO API144for translating the semantics to make the business logic142agnostic of the specific cloud environment.

Processing the requests may include communicating with a privacy budget service252(e.g., implemented by the privacy budget service server152), using the CPIO API144functions, to check the privacy budget and ensure compliance with the privacy budget. The privacy budget keeps track of requests and events that have been processed. There may be a maximum number of requests originating from a specific user, for example, that can be processed during a particular computation or period. Ensuring compliance with a privacy budget prevents parties analyzing the output from the DP128from extracting information regarding a specific user. By checking compliance with the privacy budget, the DP128provides a differentially private output.

The results from processing the requests can be encrypted by the DP128, and can be redacted and/or aggregated such that the output does not reveal information concerning specific users. The DP128can store the results in, for example, the cloud storage160, where the results can be retrieved by parties having the decryption key for the results. As one example, if processing results for the third party server136, the DP128can encrypt the results using a key that the third party server136can decrypt.

Turning toFIG.2B, an architecture200B is similar to the architecture200A, except that additional details are illustrated regarding key management and privacy budget. In comparison toFIG.2A,FIG.2Balso illustrates the Trusted Party 1 server166(referred to herein as Trusted Party 1166for brevity), the Trusted Party 2 server172(referred to herein as Trusted Party 2172for brevity), and the public key distribution service278. The public key distribution service278provides public keys to the client device102, which the client device102can use to address requests to the DP128, front end234, or third party server136that aggregates requests (not shown inFIG.2B). The public key distribution service278may be operated by the public key repository server178, or by the KMS server164. The Trusted Party 1166includes a key cache268containing encrypted split-1 keys (i.e., an encrypted first portion of a private key), whereas the Trusted Party 2172includes a key cache274containing encrypted split-2 keys (i.e., an encrypted second portion of the private key). Each of the Trusted Parties166,172may also provide a privacy budget service270,276, and may each manage an instance of the privacy budget. Distributing management of the privacy budget to two Trusted Parties helps to ensure that no one Trusted Party can tamper with the privacy budget. Both privacy budget services270,276should enforce the same privacy budget; thus, if the two services return different outputs, the SCP126can recognize that one of the Trusted Parties166,172has tampered with the privacy budget. The architecture illustrated inFIG.2Bprevents any one Trusted Party from having total control over private decryption keys or the privacy budget. A single Trusted Party cannot act alone to provide unlimited budget to any user, and therefore a single Trusted Party cannot aggregate the same batch of data repeatedly.

The elements illustrated in the architecture200B can implement the actions illustrated inFIG.3.

During an example scenario300, illustrated inFIG.3, the client device102retrieves302public keys from a public key distribution service278(which may be implemented by the public key repository server178, or may be provided by the KMS164). The client device102encrypts304a request for the service implemented on the TEE124using a public key associated with the service. The client device102then sends306the encrypted request to the front end server134. As explained previously, in some implementations, the third party server136receives the encrypted request before the request reaches the front end server134, and stores the encrypted request in the cloud storage160, where the encrypted request can be retrieved by the front end server134. The front end server134passes308the encrypted request to the DP128. The business logic142retrieves the encrypted request for processing, and attempts to retrieve the decryption key from the key cache146. If the business logic142retrieves the decryption key, the scenario continues from event308to event320.

If the decryption key is not present in the key cache146, the business logic142requests, using the CPIO API144, the decryption key. More particularly, the DP128sends310a request for key split 1 to the Trusted Party 1166, and sends312a request for key split 2 to the Trusted Party 2172. In response, the Trusted Party 1166sends314the key split 1 to the DP128, and the Trusted Party 2172sends316the key split 2 to the DP128. The key splits 1 and 2 may be encrypted when received314,316by the DP128with symmetric keys generated by the Trusted Party 1166and the Trusted Party 2172, respectively. Accordingly, the DP128may also need to request decryption of the key splits by, for example, the KMS164(i.e., a cloud KMS), which may store the symmetric keys operated by the Trusted Parties166,172.

Before sending314and316the key splits to the DP128, the Trusted Parties166,172may first verify that the business logic142corresponds to the code publicly released on a commit of a code repository. This can be accomplished through attestation. The codebase of the business logic142is available to all stakeholders (the client device102, the Trusted Parties166,172, the cloud platform122, the administrator, third parties, etc.) to examine and audit. As discussed above, any stakeholder can build the DP container including the business logic142and generate PCRs for the published logic. Thus, any party can verify that the business logic142built and deployed on the DP128matches the published codebase by comparing PCRs of the deployed business logic142against PCRs of the published codebase. The CPIO API144can communicate PCRs of the deployed business logic142to other parties (i.e., to the client device102, to other components of the cloud platform122or the computing system100) to attest that the deployed business logic142corresponds to the released codebase and has not been altered.

Thus, in the requests310,312that the DP128transmits, the business logic142can include, using the CPIO API144, the PCRs for the deployed business logic142. Alternatively or in addition, the Trusted Parties166,172can request the PCRs. The Trusted Parties166,172can then confirm that the deployed images match the PCRs of the published codebase. After performing this verification process, the Trusted Parties166,172can release314,316the key splits to the DP128. Likewise, the KMS164can also verify that the binary image deployed on the DP128is attested, and release symmetric decryption keys only to attested DP binaries running in the TEE124.

The business logic142then assembles318the private decryption key from the key splits, and can store the assembled private key in the key cache146. Assembly of the private key occurs only in the TEE124, and the CPIO API144utilizes a secure channel and authentication when communicating with the Trusted Parties166,172. Since each Trusted Party166,172contains only part of each key, whole private keys only exist within the secure TEE124after the key splits are combined. Thus, this prevents any single party from exfiltrating cleartext data or private keys. The business logic142retrieves320the private key from the key cache146and uses the private key to decrypt the request. Before processing the request, the business logic142may verify322that there is privacy budget available to process the request. The business logic142may perform such verifications by communicating with the privacy budget service270,272, and/or154, in accordance with the CPIO API144. The business logic142can then process324the request. Before storing326the result of the processing, the business logic142in some cases checks again whether privacy budget is still available. The business logic142can then 326 encrypt and store the result for later retrieval. For encryption, the business logic142can either use a system-provided or a Customer-Managed Encryption Key (CMEK) for encryption at rest. The result is then ready for retrieval and consumption by any party possessing the CMEK key (e.g., the administrator, the client device102, the third party server136, etc.).

Turning toFIG.4, a scenario400depicts additional details regarding the split key architecture discussed above. In particular, the scheme discloses herein utilizes envelope encryption and distributed bit-split private keys to protect the private keys used for securing sensitive data from being collected by malicious parties. The sequence illustrated inFIG.4illustrates how split keys can be generated and distributed. The symmetric key pairs used for encryption and decryption of sensitive data are generated within trusted servers/enclaves (e.g., the Trusted Parties166,172, a Key Generation Enclave402, described below). The public keys for each pair are distributed openly, but each private key is bit-split between N Trusted Parties in a secure way. The SCP126uses remote attestation of binaries and secure communication channels to guarantee the integrity of this process. Bit-splitting each private key between all of the Trusted Parties ensures that no Trusted Party can get access to any whole private keys by acting alone. The most common configuration, as illustrated inFIGS.2B and3, utilizes N=2, such that there are two Trusted Parties (i.e., the Trusted Parties166and172). However, it should be understood that the techniques described herein can be extended to key splits among N Trusted Parties.

Assuming N=2, the Trusted Party 1166deploys the attested binary which includes the logic for creating/rotating the asymmetric keys to a secure enclave (e.g., the Key Generation Enclave402). The Trusted Party 2172configures the KMS164to only allow this attested binary to encrypt the split. Once the Trusted Party 2172receives the encrypted split, it decrypts the encrypted split and re-encrypts the split with a new symmetric key unknown to any other stakeholder. If the attested binary does not match, the key generation enclave will not be able to decrypt the symmetric key of Trusted Party 2172, which is needed to encrypt the split key. The encrypted key split for Trusted Party 2172is now stored in a datastore accessible to Trusted Party 2172. The key split corresponding to Trusted Party 1166is simply encrypted and stored by Trusted Party 1166. At this point, the private key required to decrypt incoming request payloads is bit-split among the Trusted Parties, and each split is encrypted and stored in a way that only the DP binary can decrypt, combine, and use. An example of this process is illustrated inFIG.4.

In the scenario400, Trusted Party 1166generates404a symmetric key ke_1 and stores the symmetric key ke_1 in the KMS164. Similarly, Trusted Party 2172generates406a symmetric key ke_2 and stores the symmetric ke_2 in the KMS164. The KMS164is configured such that decryption using the keys ke_1 and ke_2 is only allowed by attested DP binaries. Trusted Party 2172generates408a symmetric key k_2, and generates410a cloud KMS symmetric key k_kms (i.e., generates410k_kms on the cloud KMS164). The Trusted Party 2172encrypts the symmetric key k_2 with the KMS164symmetric key, k_kms. The key k_2 will be released to the attested binary running in a Key Generation Enclave402for encrypting the key split for the Trusted Party 2172. Events404,406,408, and410collectively define an initial setup procedure.

The Key Generation Enclave402is another TEE (i.e., a different TEE from the TEE124) that generates and splits keys, and may be operated on servers on or off the cloud platform122. Similar to the DP128, the Key Generation Enclave402has an attested image that can be verified by other parties. Both Trusted Parties166,172agree upon the image binary that will be used by the Key Generation Enclave402to create keys. One of the Trusted Parties166,172can be the administrator of the Key Generation Enclave402. However, if the party running the binary makes any changes to the code, it will not be able to send the split share to the other trusted party. This is because the Key Generation Enclave402cannot decrypt the encrypted symmetric key sent by the other party if the image hash changes.

The Key Generation Enclave402generates keys within a secure execution environment, such that no entity outside the Key Generation Enclave402can see how the keys are generated. The Key Generation Enclave402generates412an asymmetric key pair including a public key and a private key, p. The Key Generation Enclave402publishes the public key (e.g., to the Public Key Distribution Service278), and bit-splits414the private key into key fragments p_1 and p_2. The Key Generation Enclave402then requests416an encrypted symmetric key from the Trusted Party 2172. The Trusted Party 2172can request418the KMS164to encrypt k_2 with k_kms, and receives420k_kms(k_2) (i.e., k_2 encrypted with k_kms) from the KMS164. The Trusted Party 2172provides422the encrypted symmetric key k_kms(k_2) to the Key Generation Enclave402. Only the attested binary running in the Key Generation Enclave402can decrypt this encrypted key by making a request to the KMS164. Accordingly, the Key Generation Enclave402requests424the KMS164to decrypt k_kms(k_2), and receives426the decrypted symmetric key k_2 from the KMS164.

The Key Generation Enclave402can then encrypt428the Trusted Party 2172split private key p_2 using the symmetric key k_2, and provide430the encrypted key split k_2 (p_2) to the Trusted Party 2172. Note that the encryption operation428occurs within the Key Generation Enclave402and is not observable by Trusted Party 1166, or any other stakeholder. The Key Generation Enclave402also sends432the key split p_1 to the Trusted Party 1166, either unencrypted or encrypted. The Trusted Party 2172decrypts434k_2 (p_2) with k_2, and re-encrypts436p_2 with the symmetric key ke_2 (e.g., the Trusted Party 2172requests436the KMS164to encrypt p_2 with ke_2, and receives438ke_2 (p_2) from the KMS164). The KMS164is configured such that decryption using ke_2 can only be done by the attested DP binary. Similarly, the Trusted Party 1166encrypts440the key split p_1 using ke_1 (e.g., the Trusted Party 1166requests440the KMS164to encrypt p_1 with ke_1, and receives442ke_1 (p_1) from the KMS164. The KMS164is configured such that decryption using ke_1 can only be done by the attested DP binary. At this point, the private key p required to decrypt incoming requests at the DP binary is bit-split among the Trusted Parties and each split is encrypted and stored in a way that only the DP binary can decrypt and combine.

Referring next toFIG.5,FIG.5illustrates an architecture500in which the techniques of this disclosure for providing privacy and security guarantees to parties when proprietary business logic cannot be audited can be performed. As discussed above, the SCP126enables other parties to audit the logic142deployed on the DP128. However, attestation of the logic142requires other parties to be able to build the code and generate the cryptographic hashes discussed above. In some workflows, the logic142is proprietary, and therefore the business logic codebase is not available for auditing and attestation. Other parties, however, still desire safeguards that privacy and security guarantees are being maintained.

An alternative to attestation of the logic142is to automatically perform a formal verification of the behavior of the logic142without human intervention. The mechanism to perform the formal verification, which may all or in part be performed by a verifier module548implemented within the TEE124, can itself be audited and attested. The verifier module548can check that dangerous behaviors (i.e., behaviors that violate security policies) are not possible at runtime of the logic142, regardless of the details of the algorithm in the logic142.

In particular, there are two aspects regarding the logic142that must be verified. First, input/output (I/O) must be marshalled, so that the binary running the business logic does not, for example, open a remote network connection to dump sensitive data to another server. Second, the provenance of data must be traced for all output, so that sensitive data present in the input cannot be combined, encrypted, or disguised into an apparently safe output (e.g., using steganography to exfiltrate data). The first aspect, marshaling of the logic142I/O can be implemented by the CPIO API144or lower-level layers of the SCP126. These SCP layers can be audited and attested. Provenance of data is more complex, as it requires some degree of introspection in the business logic and understanding of the potential behaviors of the system.

Turning toFIG.5, the architecture500provides one solution to the issue of making privacy and security guarantees when the business logic142is proprietary. The architecture500uses an automatic verifier (i.e., the verifier module548) and policies to define which behaviors are forbidden. Instead of arbitrarily-defined operations, the architecture500may use a choice of Domain-Specific Languages (DSL) to express the business logic142(e.g., Structured Query Language (SQL)). In an example implementation, the payload of the business logic142is written in a language that the verifier module548can analyze (e.g., be written as an SQL query).

An owner502of the business logic142provides the business logic142to the SCP126. When the SCP126instance is launched, the business logic142is run through the verifier module548. The verifier module548runs within the TEE124. The business logic142executes on the DP128within a DSL runtime510. The verifier module548checks the business logic142against one or more policies, such as the security policy580. The verifier module548can retrieve the security policy580from the public security policy storage180, for example. Taking the example mentioned above, the payload of the business logic142may be written as an SQL query. The security policy580may specify that certain columns may be joined on, but not output. The verifier module548can check whether business logic142complies with this requirement. Those skilled in the art will recognize that the business logic142may be specified in a variety of domain specific languages other than SQL, such that business logic142specified in such a language can be automatically checked for policy compliance. More generally, the verifier module548can trace and verify output data provenance and processing according to the security policy580. The verifier module548can check that no malicious operations can be expressed, such as “open a network connection and send data to an unknown server.”

The payload of the business logic142, i.e., the algorithm, is kept secret. Thus, all other elements of the architecture500can be audited and attested, including the verifier module548. The security policy580describes which actions and/or fields are allowed in order to compose the output of the business logic142. The security policy580is public, and is essentially a machine-readable and machine-enforceable PDD. If the verifier module548successfully determines that the payload of the logic142is safe according to the security policy580, execution of the logic142progresses. Otherwise, execution is not allowed for that payload. The verifier module548and the architecture500can be combined with the architectures200A and200B described previously.

As one example of proprietary business logic, a first party (e.g., the owner502) may offer a matching service, and deploy this matching service to the SCP126. The matching service takes 1P data from a second party as input, matches personal identifiable information (PII) (e.g., phone number, email address, social security number) in that 1P data to PII provided by the second party, and outputs a matching table that maps a customer ID space for the second party to a customer ID space for the first party. The second party seeks a guarantee that the first party cannot learn any new PII from the ingested IP data, and the first party seeks a guarantee that the exact matching algorithm is not disclosed.

The deployed service may include a matching engine and a matching policy, where the matching policy is the portion of the matching engine that is not disclosed, and provides the algorithm for how the matching is performed (e.g., first match by phone number, second match by email address). Thus, the matching policy may correspond to the business logic142. The security policy (e.g., the security policy580) is publicly disclosed and describes what fields from the input can be used for matching and what fields of the input cannot participate to generate an output. The verifier module548can check whether the matching policy violates this security policy, and stop execution of the matching policy if there is a violation, thereby ensuring the second party's guarantees to their users without disclosing the matching policy.

Below, several ownership considerations are discussed that are applicable to the foregoing discussion.

Because the DP source code (i.e., the business logic142) is audited by the relevant stakeholders, and the code running within the enclaves is attested, the DP (i.e., the DP container) can be written by any party without effect on the security or privacy properties of the system. However, there are considerations depending on who is the administrator of the service, who manages the keys and KMS configuration, and who writes and operates the privacy budget service. Some of the valid secure setups, assuming a two-way key split is used, are discussed in Table 1 below.

TABLE 1Notes on Ownership ModelsAdministrator(DP enclaveKeyKeyData breach is possibleowner)Split 1Split 2Setup notesif there is a:Third partyTrustedTrustedThe third party can audit3-way collusion: BothbetweenParty 1Party 2the business logic 142.TPs cooperate (orthe clientBoth the author of the“collude”) with the thirddevice 102business logic 142 and theparty to share the splitand thethird party trust at least onekeys. The third partyTEE 124of the Trusted Partiescombines key splits and(TPs). The author can thendecrypts the encryptedtrust that the third partybatches of requests.can only process requests ifthe DP has not beentampered with. The thirdparty can trust that theauthor has no access toencrypted data, and boththe third party and theauthor can trust that neitherparty has access todecryption keys orcleartext data.Author ofAuthor ofTrustedThis is a minimal number2-way collusion (can bethe DPthe DPParty 1of stakeholders setup thatenhanced to 3-way):businessbusinessguarantees that the authorAuthor of the DPlogic 142logic 142of the business logicbusiness logic 142 andcannot see unprocessedTP 1 cooperate to deploy(e.g., per-event) data ina crafted DP. TP1 andcleartext. TP 1 can alsothe author configureaudit the codebase in theKMSs to release keyDP to provide a highermaterial to this new DPdegree of trust.hash, and the authorsends the encryptedbatches for processing. Asecond TP can be usedinstead of the author toenhance security to 3-way collusion.ThirdThirdAuthor ofAnother minimal number2-way collusion (can bepartypartytheof stakeholders setup thatenhanced to 3-way):businessguarantees that neither theAuthor and third partylogic 142author nor the third partycooperate to deploy acan see unprocessed (e.g.,crafted DP. Third partyper-event) data in cleartext.and author configureBoth the third party and theKMSs to release keyauthor can audit thematerial to this new DPcodebase.hash, and third partysends the encryptedbatches for processing. ATP can be used instead ofthe third party to enhancesecurity to 3-waycollusion

There are also multi-party computation (MPC) considerations applicable to the foregoing discussion. MPC provides security by delocalizing data and computation. Breaching MPC systems can be possible by capturing the internal state (e.g., memory dump) of all participant instances and combining that information, or if a party were able to collect keys to decrypt the input data from both MPC servers. As a technology, MPC is orthogonal to the TEE/enclave approach described herein. Depending on the desired security and operational cost properties of the system, both technologies could be used independently or in combination. For a malicious actor, capturing the internal state of a couple of related processes is harder if the processes are deployed in different environments (i.e., different clouds), and if there are security measures in the hardware preventing other processes from accessing the MPC processes' memory space.

The SCP (e.g., the SCP126) provides both of these protections, by having the ability to deploy instances of the same business logic in different cloud providers, and by protecting the memory of the process running within the enclave by using hardware (confidential computing) to either lock-out the address space of the sensitive processes or to encrypt it.

Layering both MPC and TEE technologies adds additional security which helps prevent malicious external and internal actors from modifying the execution or policy engine.

Additional Considerations

The following additional considerations apply to the foregoing discussion.

A client device in which the techniques of this disclosure can be implemented (e.g., the client device102) can be any suitable device capable of wireless communications such as a smartphone, a tablet computer, a laptop computer, a desktop computer, a mobile gaming console, a point-of-sale (POS) terminal, a health monitoring device, a drone, a camera, a media-streaming dongle or another personal media device, a wearable device such as a smartwatch, a wireless hotspot, a femtocell, or a broadband router. Further, the client device in some cases may be embedded in an electronic system such as the head unit of a vehicle or an advanced driver assistance system (ADAS). Still further, the client device can operate as an internet-of-things (IoT) device or a mobile-internet device (MID). Depending on the type, the client device can include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

Certain embodiments are described in this disclosure as including logic or a number of components or modules. Modules may be software modules (e.g., code stored on non-transitory machine-readable medium) or hardware modules. A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. A hardware module can comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. A hardware module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. The decision to implement a hardware module in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

When implemented in software, the techniques can be provided as part of the operating system, a library used by multiple applications, a particular software application, etc. The software can be executed by one or more general-purpose processors or one or more special-purpose processors.