Sealed Configuration Proven Cloud Storage and Key Management Service Primitive

Abstract

The access control method is implemented in a cloud computing platform. The method includes creating a primitive owned by a client system that accesses the cloud platform via a computer network on the cloud computing platform in response to a first call (302), and performing a restricted operation on the primitive in response to a second call from a process executed in a configuration-proven enclave implemented within a TEE (trusted execution environment) of the cloud computing platform, such that the restricted operation is not directly available to the client system (304).

Description

Technical Field

[0001] Cross - Reference to Related Applications This application claims priority and benefit under 35 U.S.C. § 119(e) to the filing date of U.S. Provisional Patent Application No. 63 / 465,551, filed on May 11, 2023, entitled "Sealed Attested Cloud Storage and Key Management Service Primitives". The entire content of the provisional application is hereby expressly incorporated by reference herein.

[0002] The present disclosure relates to secure computing environments, and more particularly, to techniques for improving security and privacy using a TEE (Trusted Execution Environment) for operating on private and / or sensitive data implemented in a cloud or other suitable environment.

Background Art

[0003] This description of the background art is provided to generally illustrate the background of the present disclosure. The work of the inventors specified herein is not admitted as prior art to the present disclosure, either expressly or implicitly, including within the scope described in this background art section and in aspects of the description that may not qualify as prior art at the time of filing.

[0004] Cloud computing is typically a network-based computing technique in which a large group of servers housed in a data center or "server farm" provides computing resources and data storage to remote end users. As the number of workflows that utilize first-party (1P) data in the cloud increases, new trust, privacy, and security paradigms are being considered to improve the guarantees given to data owners. These include using Trusted Execution Environments (TEEs) such as enclaves, confidential computing, and secure Multi-Party Computation (MPC). Conventionally, TEEs have been created to support stand-alone computers and mobile devices to provide secure execution in an isolated trusted firmware-based environment. However, in a public cloud, conventional TEE technologies are insufficient.

[0005] Currently, cloud-based TEE architectures maintain their security and privacy characteristics both in terms of the technology and with trusted parties such as the owner of the account that holds the decryption key. According to one example of an approach, trust is enhanced by distributing secure information among multiple parties such that multiple stakeholders would need to collude to violate their terms of use and extract unauthorized data. The security of such architectures is based on an audit-attestation model. The technical mechanisms that enable this security are the infrastructure for enclave attestation and conditional encryption operations, for example, certain keys can only be used from a TEE that has a specific known hash.

[0006] However, even when customers use TEE and key management service (KMS) enclave configuration proofs, aspects of the security of these approaches, such as differential privacy jets and cryptographic key management, are still exposed to some extent to people. In particular, someone must own an account that holds sensitive information during serialization, and the owner necessarily has access to data, keys, etc. Although it is possible to seal the execution environment, it is not possible to seal the entire system including the serialized state. In currently available cloud technologies, for sensitive information such as metadata, credentials, serialized state, and cryptographic keys, only the code operating in the TEE can access it, and it is not made opaque to all other parties including the owner of the TEE deployment.

[0007] One available solution is to introduce the concept of a "trusted party" or "coordinator" as an external entity that holds the sensitive state in such a way that any human operator can only partially access some obfuscated sensitive information, and multiple parties need to collude to obtain data in an authorized way. Still, with this approach, at least one operator needs to be trusted. In addition to the difficulty of finding a trusted party, approaches like these increase the complexity of the system. Summary of the Invention

[0008] Exemplary embodiments of these techniques are access control methods implemented on a cloud computing platform. The method includes creating, in response to a first call on the cloud computing platform, a sealed primitive owned by a client system accessing the cloud computing platform via a computer network, and, in response to a second call from a process executed in an attested enclave implemented within a trusted execution environment (TEE) of the cloud computing execution, performing restricted operations on the sealed primitive, where the restricted operations are not directly available to the client system.

[0009] Other exemplary embodiments of these techniques include a set of servers and a cloud computing platform configured to implement the above method.

Brief Description of the Drawings

[0010]

Figure 1

Figure 2

Figure 3A

Figure 3B

Figure 4

Figure 5

[0011] As will be discussed in more detail below, a cloud computing platform provides primitives such as storage objects or KMS keys, such that the owner of the primitive can only perform a limited set of operations on the primitive, without having access to the internal state of the primitive and lacking the privilege to perform restricted operations such as modification and destruction. The cloud computing platform enables restricted operations to be initiated from within a configuration-attested enclave and / or by an authorized hash. These primitives can be referred to as "sealed configuration-attested primitives." A storage primitive can be referred to as a SASO (sealed attested storage object), and a key primitive can be referred to as a sealed KMS key (SSK).

[0012] According to an exemplary setup, a secure service, which is a cloud service owned by an operator of a cloud computing platform, periodically pulls client data from an external system. The owner of the client data may share credentials for accessing the client data only if there are technically provable guarantees that these credentials will never be shared with parties associated with the operator of the cloud computing platform (e.g., technicians who build and / or operate the cloud computing platform), or any other people, and that these credentials will not be used for any other purposes.

[0013] When enclaves with auditing and attestation are available (thus, when the user can trust that the secure service operates as required by the operator of the cloud platform), and when the client can verify, by means of an appropriate authentication mechanism, that the data request is from the correct secure service, the techniques of the present disclosure address the remaining security concern of storing the credentials in a way that parties associated with the cloud computing platform cannot access.

[0014] According to the SASO approach discussed with reference to FIG. 1, the operator of the cloud computing platform can own the SASO, and the enclave uses the SASO to store the relevant credentials. In this way, the operator of the cloud computing platform creates the SASO, and the secure service uses the SASO as secure storage.

[0015] According to the SKK approach considered with reference to FIG. 2, an operator of a cloud computing platform can have a KMS account and hold a storage encryption SKK that can only be used by secure services. Subsequently, the secure service can securely encrypt the credentials and store the credentials in cloud storage for later use without the risk of removal.

[0016] Referring to FIG. 1, an exemplary computing environment 100 includes a cloud platform 102 (also referred to herein as cloud 102). The cloud platform 102 can include any suitable number of servers 103 and storage devices (or simply “memory”) 104 associated with a cloud provider, and can provide cloud computing and storage services to client systems such as client system 110 via a computer network. Although not shown in FIG. 1 to avoid confusion, the network can generally include one or more wired and / or wireless communication links, for example, the Internet, a local area network (LAN), a cellular phone network, or another suitable type of network, or a wide area network (WAN) such as a combination of networks. The servers 103 and memory 104 associated with the cloud platform 102 can be distributed across multiple sites to improve reliability and reduce latency. Although not shown in FIG. 1, each server 103 included in the cloud platform 102 can include one or more processors adapted and configured to execute various software stored in one or more memories. Thus, the cloud platform 102 can include computing components and storage components.

[0017] The client system 110 can include a local network, or a single device such as a portable device (e.g., smartphone, tablet computer), laptop computer, desktop computer, wearable device, or a plurality of devices or servers forming a single device. The client system 110 can include a computer-readable memory and one or more processors that execute code stored in the computer-readable memory. The client system 110 can be associated with a service user, who is an end user of the services provided by the cloud platform 102. In the example discussed below, the service user is the owner of an account associated with the client data 112 and of the primitive 120. The client database 112 can be controlled by the client system 110 and implemented in any suitable way, for example as a database accessible from the cloud computing platform 102 using API calls.

[0018] In the example of FIG. 1, the primitive 120 is a storage object that encrypts data 122 such as logs, persistent state records, credentials, etc. The storage object 120 further includes attributes 124 and an access list 126. Although the client system 110 is associated with the owner of the primitive 120, the cloud platform 102 restricts access to the primitive 120 according to a limited set of functions, other than via the secure service 130, to the client system 110. The secure service 130 operates within a configured and proven enclave 140 implemented within a TEE (Trusted Execution Environment). Any suitable number of authorized processes, such as processes 145 and 146, can also execute within the TEE 142.

[0019] Primitive 120 can be referred to as a "sealed configuration proven storage object" or SASO, and generally can be any cloud storage object (e.g., a blob) that restricts access and control of data from an image having a specific hash, such as processes 145 and 146, to processes operating in a secure container. For simplicity, some of the following examples specifically refer to blobs, but the techniques of the present disclosure can also be applied to other higher-level storage types such as tables, files, or databases.

[0020] During operation, the client system 110, or the "owner", creates the SASO 120 using an atomic call 150, i.e., without access to the SASO 120 from other tasks until the call 150 is completed. Alternatively, the client system 110 can authorize the secure service 130 to create the SASO 120. As part of the object creation call, the client system 110 can set up an allowed hash, set the TTL (Time-To-Live) of the SASO, and set the maximum allowed size of the SASO 120. The call 150 can also include one or more options, such as (i) a list of object metadata (e.g., name, size), (ii) granting to other users of the same access control list (ACL) that the owner has on the SASO 120, (iii) revoking from other users the ACL granted on the SASO 120, (iv) adding a hash to the SASO access list 126, and (v) removing a hash from the SASO access list 126. The TTL, maximum allowed size, and one or more option parameters can be stored as parameter 124.

[0021] The client system 110 owns the SASO 120 but cannot read, write, or delete the SASO 120. The secure service 130 can execute a data pull 156 on the client data 112. The secure service 130 can perform read, write, or delete operations 155 on the SASO 120. To delete the SASO 120, the client system 110 can issue an API call 152 via the storage API 132 and via the configured and attested enclave 140, or the cloud platform 102 can garbage collect the SASO 120. Also, the cloud platform 102 can garbage collect the SASO 120 if there are no instances of any authorized hash that has been active for longer than the TTL set at the time of creation of the SASO 120. In this way, when the SASO 120 is not in use, the cloud platform 102 will eventually automatically delete the SASO 120 under the conditions agreed upon by the account that pays for the storage. In some embodiments, the cloud platform 102 similarly places an upper limit on the size of the SASO 120 to limit operating costs.

[0022] If the authorized processes 145 and 146 have their respective authorized hashes (i.e., the hashes included in the access list 126), the secure service 130 operating in the configured and attested enclave 140 can (i) read, write, or delete the SASO 120, (ii) add, remove, or modify the list 126 of hashes that grant permissions to the SASO 120, (iii) obtain the list of permissions assigned to itself by the SASO owner via the create call 150 (e.g., if the SASO owner has assigned itself privileges to revoke access, the configured and attested enclave 140 can choose not to use the SASO 120), and (iv) read the TTL of the SASO 120.

[0023] The cloud platform 102 can encrypt all storage content (e.g., data 122), and API calls can be encrypted during transit (e.g., in an HTTPS (Hypertext Transfer Protocol Secure) message). Further, the decryption key 148 cannot be accessed by any user, including the account that owns the object. Instead, the decryption key 148 is used by the attestation-enabled enclave 140 as needed.

[0024] Next, some examples of use cases that can be implemented in the environment of FIG. 1, or in a similar environment, will be briefly considered.

[0025] According to a use case related to secure logs, an attestation-enabled enclave (e.g., the attestation-enabled enclave 140) can write logs to an attestation-enabled storage (e.g., SASO 120). The cloud platform 102 ensures that no party outside the attestation-enabled enclave can access or modify these logs. If necessary, the owner of the logs can configure the cloud platform 102 to provide a mechanism to "break glass" (i.e., bypass the security mechanism) and access the logs within the attestation-enabled enclave. In some embodiments, break-glass access requires permissions (and visibility) from multiple parties.

[0026] According to other use cases, the cloud platform 102 provides clean room service state serialization. In this case, the client system 110 operates a secure stateful service that requires a guarantee that its operator (i.e., the client system 100) does not tamper with the service status. The secure stateful service may use attested storage (e.g., SASO 120) to persist the state during restart or maintain a consistent (but externally invisible) state. As a more specific example, a transaction-based service can store log-ahead writes in attested storage.

[0027] Another example of a use case relates to blind credential management. In this scenario, a particular operator controls the cloud platform 102 and the service 130 operating in the TEE 142. The operator is entrusted with external user credentials that can be used to periodically access sensitive information owned by the user. This data can be, for example, the user identifier and password of a CRM (customer relationship management) account hosted outside the operator's system. The cloud platform 102 can receive new data from the CRM account, for example, every day.

[0028] In this scenario, both the operator and the external user are interested in a guarantee that these credentials cannot be used for any purpose outside the TEE142, or a guarantee that they cannot be trusted by any party. It is possible to send the credentials to the operator of the cloud platform 102 for secure storage in the TEE142, but there may also be a reason to store these credentials in a way that does not require the external user to enter the credentials every time the cloud platform 102 receives data. Serializing the credentials within the SASO object 120 created by either the operator or the external user is secure because this approach ensures that only the business logic within the TEE142 (e.g., the authorized process 145) can access the credentials. Additionally, if the operator of the cloud platform 102 is also the owner of the SASO object 120, this approach not only provides the added benefit of eliminating the need for the external user to create a cloud account associated with the cloud platform 102, but also benefits from all the advantages of secure credential management.

[0029] According to yet another example, the use case is related to differential privacy (DP) in data processing, and DP is a mechanism for limiting the processing / aggregation of raw data so as to prevent any insight into the raw data from the aggregated results. In most cases, the processing / aggregation of data involves multiple steps, and each step of the aggregation can consume a portion of the budget (e.g., pre-aggregation, then ML training). The SASO120 can track the budget and provide a technical guarantee that neither the operator nor the customer can tamper with the budget and that no insight can be gained from the raw data.

[0030] In yet other examples of cases related to storing a machine learning (ML) model for future inference, the data used to train the ML model is the product of a combined operation performed on a dataset from an operator controlling the cloud platform 102 and a dataset from a customer. Generally speaking, an ML model trained with such data is preferably protected because there is a risk that someone may obtain insights into the training data through repeated interference. SASO 120 can provide the protection required for the ML model without relying on a managed cryptographic key while enabling the model to be reloaded into the TEE 142 for inference.

[0031] Referring now to FIG. 2, an exemplary computing environment 200 is generally similar to the environment 100 described with reference to FIG. 1. Elements labeled with reference numbers having the same two least significant digits as the elements of FIG. 1 (e.g., elements 102 and 202, or 110 and 210) can be implemented in a manner similar to those described above and will not be described again below for simplicity. The differences between FIGS. 1 and 2 are described next.

[0032] Unlike primitive 120, primitive 221 is a sealed KMS key (SKK). The client system 210 in this exemplary configuration owns the SKK 221, but (i) can only create the SKK 221 using the atomic call 251. As part of the create call, the caller can, in an exemplary embodiment, set up an allowed hash and set the SKK TLL. Further, the client system 210 can execute calls 252 to delegate the right to create the SKK 221 to a confidential computing instance (e.g., processes 145, 146) having a specific hash or to revoke such rights. Still further, the client system 210 can execute calls 253 to list the key metadata (e.g., find out how many keys exist and which hashes are authorized for their use).

[0033] The client system 210 that supports the account owning SKK221 cannot (i) obtain SKK221 from the KMS, (ii) execute any encryption / decryption commands using SKK221, or (iii) delete SKK221. In some embodiments, the client system 210 determines whether to apply restriction (iii) when creating SKK221 via call 251 by setting certain parameters. The deletion of SKK221 can be achieved either by issuing an API call from the attestation enclaves 240 or by garbage collecting SKK221. In an exemplary embodiment, the cloud platform 202 can garbage collect SKK221 if there are no instances of any authorized hash that has been active for a period longer than the TTL set at creation.

[0034] On the other hand, the KMS service 231 running within the attestation enclaves 240 can, if the hash is correct, (i) execute any operations supported by the KMS on SKK221, including encryption, decryption, and acquisition, (ii) add or remove the hash from the list 226 authorized for use by this SKK221 on the KMS, or (iii) delete SKK221.

[0035] In most cases, the example use cases described above with reference to FIG. 1 also apply to FIG. 2. However, note that no one, even the account owner, can access SASO120 except for the logic within the attestation enclaves 240. By encrypting data with a key that cannot be accessed using SKK221, the data in storage can be made inaccessible to anyone.

[0036] Furthermore, as described above, the account owner cannot delete SASO120. However, the account owner can delete the storage protected by SKK221.

[0037] Next, some examples of methods that can be implemented in the cloud computing platform 102 or 202 will be described. Each of these methods can be implemented as a set of instructions stored in a non-transitory computer-readable medium and executed by one or more processors.

[0038] Next, FIGS. 3A and 3B illustrate an exemplary method 300 for creating and configuring a sealed primitive in response to an atomic call from the owner of the primitive that can be implemented in the cloud platform 102 or 202. In block 302 of FIG. 3A, the cloud platform 102 or 202 creates a primitive (e.g., SASO or SKK) in response to an atomic call from the owner of that primitive, e.g., from a client computing system. However, in block 303 of FIG. 3B, the cloud platform 102 or 202 creates a primitive in response to a call from within a confidential container (CC) executed in a TEE, such as TEE142 or 242. In either case, the flow proceeds to block 304 where the cloud platform 102 or 202 performs restricted operations related to the primitive in response to a call from within the proven-enclave. As described above, the owner of the primitive cannot make this call directly. Thus, the cloud platform 102 or 202 prevents the owner of the primitive from performing such operations as read, write, and delete, but allows the owner to create the primitive directly.

[0039] Referring to FIG. 4, the cloud computing platform can implement a method 400 for creating sealed configuration proven primitives such as SASO120 or SKK221. The cloud computing platform can call the method 400 at block 302 or 303 above. At block 402, the cloud computing platform sets up one or more acceptable hashes required for an authorized process of the TEE to perform read / write or encryption / decryption operations according to a creation function call from the owner of the sealed configuration proven primitive (e.g., call 150, call 251). At block 404, the cloud computing platform sets the TTL parameter of the sealed configuration proven primitive according to the creation function call. Next, at block 406, the cloud computing platform sets optional parameters according to the creation function call.

[0040] Finally, referring to FIG. 5, the cloud computing platform can implement a method 500 for performing restricted operations on sealed configuration proven primitives such as SASO120 or SKK221. The cloud computing platform can call the method 500 at block 304 described above with reference to FIGS. 3A and 3B, for example.

[0041] Method 500 begins at block 502 which receives a request for a cloud computing platform to execute a restricted operation on a provenance-sealed primitive. At block 504, the cloud computing platform determines whether the restricted operation (e.g., SASO read / write / delete, SKK encrypt / decrypt / delete) occurred within a provenance-enclave (e.g., provenance-enclave 140 or 240). If so, the flow proceeds to block 506, otherwise the flow proceeds to block 510. At block 508, the cloud computing platform determines whether the call requesting the restricted operation is associated with an acceptable hash (e.g., whether process 145 specified a hash included in access list 126, or whether confidential computing instance 245 specified a hash included in access list 226). If so, the flow proceeds to block 508 which enables the cloud computing platform to execute the restricted function. Otherwise, the flow proceeds to block 510 which blocks the cloud computing platform from executing the restricted function. As described above, the cloud computing platform here blocks the restricted operation even if the call is originated from the owner of the provenance-sealed primitive.

[0042] The following additional considerations apply to the above discussion.

[0043] In some embodiments, paging messages can be replaced by paging records. In other embodiments, a paging message can include one or more paging records, each paging record paging a specific UE. For example, a paging message can include a paging record for UE 102.

[0044] A user device (e.g., UE102) capable of implementing the technology of the present disclosure can be any suitable device capable of wireless communication, such as a smartphone, a tablet computer, a laptop computer, a mobile game console, a point-of-sale (POS) terminal, a health management device, a drone, a camera, a media streaming dongle or other personal media device, a wearable device such as a smartwatch, a wireless hotspot, a femtocell, or a broadband router. Further, the user device may optionally be embedded in an electronic system such as a vehicle head unit or an advanced driver assistance system (ADAS). Still further, the user device can operate as an Internet of Things (IoT) device or a mobile Internet device (MID). Depending on the type, the user 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.

[0045] Certain embodiments are described in this disclosure as including logic, or several components or modules. A module can be a software module (e.g., code stored in a non-transitory machine-readable medium) or a hardware module. A hardware module is a tangible unit capable of performing certain operations and can be configured or arranged in a certain manner. A hardware module can include 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 can also include programmable logic or circuitry (e.g., included 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 within dedicated and permanently configured circuitry or within temporarily configured circuitry (e.g., configured by software) can be left to cost and time considerations.

[0046] When implemented in software, techniques can be provided as part of an operating system, libraries used by multiple applications, a particular software application, etc. The software is executable by one or more general-purpose processors or one or more special-purpose processors.

[0047] As used herein, the terms "comprises," "comprising," "includes," "including," "has," "having," or any other variation thereof are intended to cover a non-exclusive inclusion. For example, a process, method, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements, but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Further, unless expressly stated to the contrary, "or" refers to an inclusive or and not an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present).

Claims

1. 1. An access control method implemented in a cloud computing platform, comprising: creating, in response to a first call, on the cloud computing platform, a primitive owned by a client system accessing the cloud computing platform over a computer network; performing a restricted operation on the primitive in response to a second call from a process executing in an attested enclave implemented within a trusted execution environment (TEE) of the cloud computing platform, the restricted operation not being directly available to the client system; and A method comprising:

2. The method of claim 1 , wherein performing the restricted action is further responsive to determining that the second call includes an acceptable hash.

3. The method of claim 2 , wherein the first call includes a list of hashes that includes the acceptable hashes.

4. The method of any one of claims 1 to 3, wherein the first call is an atomic call from the client system.

5. The method of any one of claims 1 to 4, wherein the first call is from the process executing in the attested enclave.

6. The method of any one of claims 1 to 5, wherein the first call includes a time-to-live (TLL) parameter of the primitive.

7. The method of any one of claims 1 to 6, further comprising automatically deleting the primitives based on the TTL parameters.

8. The method of any one of claims 1 to 7, wherein the primitive is a sealed attested storage object (SASO) that contains data associated with the client system.

9. The method of claim 8 , wherein the first call includes a maximum allowable size parameter for the primitive.

10. The first call comprises: (i) listing metadata for said primitives; (ii) granting to other systems the access control list (ACL) of the client system that owns the primitive; (iii) revoking ACLs granted to systems other than the client system that owns the primitive; and (iv) deleting the primitive; and (v) adding a first hash for which the second call is permitted; and (vi) removing a second hash for which the second call is permitted; and The method of claim 8 or 9, further comprising a set of permissions including at least one of:

11. The restricted operation is (i) a read command; (ii) a write command, or (iii) a delete command; The method according to any one of claims 8 to 10, wherein the method is one of

12. The method of any preceding claim, wherein the primitive is a Sealed Key Management Service (KMS) Key (SKK) for use with encryption and / or decryption.

13. 13. The method of claim 12, further comprising receiving a request from the client system that owns the primitive to delegate authority over the SKK.

14. 13. The method of claim 12, further comprising receiving a removal of a prior delegation of authority for the SKK from the client system that owns the primitive.

15. The method of any one of claims 12 to 14, further comprising providing metadata of the SKK in response to a request from the client system that owns the SKK.

16. The restricted operation is (i) an encryption command; (ii) a decryption command, or (iii) a delete command; The method according to any one of claims 12 to 14, wherein the method is one of

17. A cloud computing platform comprising a set of servers and configured to carry out the method according to any one of claims 1 to 16.

Images