Sealed authentication cloud storage and key management service primitives

Abstract

An access control method is implemented in a cloud computing platform. The method comprises creating (302) primitives owned by a client system on the cloud computing platform in response to a first call, the client system accessing the cloud computing platform via a computer network; and in response to a second call from a process executing in an authenticated enclave implemented in a trusted execution environment (TEE) of the cloud computing platform, performing (304) a restricted operation related to the primitive, where the restricted operation is not directly available to the client system.

Description

Cross-references to applications

[0001] This application claims the benefit of priority and filing date of Provisional U.S. Patent Application No. 63 / 465,551, entitled “Sealed Attested Cloud Storage and Key Management Service Primitives,” filed on May 11, 2023. The entire contents of that provisional application are hereby expressly incorporated herein by reference. Technical Field

[0002] The present disclosure relates to secure computing environments, and more particularly, to techniques implemented in the cloud or another suitable environment for improving the security and privacy of operations on private and / or sensitive data using a trusted execution environment (TEE). Background Art

[0003] This background description is provided for the purpose of generally presenting the context of the present disclosure. The work of the presently named inventors (to the extent that it is described in this background section) and aspects of this description that might not be identified as prior art at the time of filing are neither explicitly nor implicitly admitted to be prior art to the present disclosure.

[0004] Cloud computing is a network-based computing technology in which large groups of servers, typically located in data centers or "server farms," ​​provide computing resources and data storage to remote end users. As the number of workflows that utilize first-party (1P) data in the cloud grows, new trust, privacy, and security paradigms are being considered to advance assurances for data owners. These include the use of trusted execution environments (TEEs), such as enclaves, confidential computing, and secure multi-party computing (MPC). Traditionally, TEEs were created to support standalone computers and mobile devices to provide secure execution in an isolated environment based on trusted firmware. However, in public clouds, traditional TEE technology is not sufficient.

[0005] Today, cloud-based TEE architectures anchor their security and privacy features on technology and trusted individuals, such as account owners, who hold decryption keys. According to one example approach, trust is increased by distributing security information among multiple parties, such that multiple stakeholders would need to violate their terms of service and collude to extract data they do not have access to. The security of such an architecture is based on an audit-certification model. The technical mechanisms to achieve this security are infrastructure for enclave authentication and conditional cryptographic operations, where, for example, certain keys can only be used from a TEE with a specific known hash value.

[0006] However, even if customers use TEE and Key Management Service (KMS)-enclave authentication, such security aspects of these approaches (e.g., differential privacy budgets and cryptographic key management) still provide a certain degree of human risk. Specifically, someone must own the account that holds sensitive information when serialized, and the owner must have access to the data, keys, etc. While the execution environment can be sealed, it is not possible to seal the entire system including the serialized state. Currently available cloud technologies do not allow sensitive information such as metadata, credentials, serialized state, and cryptographic keys to be accessible only to the code running in the TEE while being opaque to everyone else (including the owner of the TEE deployment).

[0007] One available solution introduces the concept of a "trusted party" or "coordinator" as an external entity that holds sensitive state in a way that any human operator can only partially access obfuscated portions of sensitive information, and multiple parties need to collude in an authorized manner to retrieve the data. It is worth noting that this approach still requires trusting at least one human operator. In addition to the difficulty in finding a trusted party, such an approach also increases system complexity. Summary of the invention

[0008] An example embodiment of these techniques is an access control method implemented in a cloud computing platform. The method includes creating a sealing primitive owned by a client system on the cloud computing platform in response to a first call, the client system accessing the cloud computing platform via a computer network; and in response to a second call from a process executed in an authentication enclave implemented in a trusted execution environment (TEE) of the cloud computing platform, performing a restricted operation associated with the sealing primitive, wherein the restricted operation is not directly available to the client system.

[0009] Another example embodiment of these techniques is a cloud computing platform including a group of servers and configured to implement the above method. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 is a block diagram of an example computing environment in which a cloud platform manages sealed authentication storage objects (SASOs) for client systems in accordance with the techniques of this disclosure;

[0011] Figure 2 is a block diagram of an example computing environment in which a cloud platform manages sealed key management service (KSM) keys (SKK) for client systems according to the techniques of this disclosure;

[0012] Figure 3A Yes, you can Figure 1 or Figure 2 A flowchart of an example method for creating and configuring a sealed primitive in response to an atomic call from a primitive owner implemented in a computing environment of;

[0013] Figure 3B Yes, you can Figure 1 or Figure 2 A flowchart of an example method for creating and configuring a sealing primitive in response to a call within a confidentiality container (CC) executed in a TEE implemented in a computing environment of;

[0014] Figure 4 Yes, you can Figure 1 or Figure 2 A flowchart of an example method for creating a SASO or SKK implemented in a computing environment of FIG. 1 ; and

[0015] Figure 5 Yes, you can Figure 1 or Figure 2 A flowchart for processing read / write / delete operations on a sealed authentication primitive implemented in a computing environment of FIG. DETAILED DESCRIPTION

[0016] As discussed in more detail below, the cloud computing platform provides primitives such as storage objects or KMS keys so that the owner of the primitive can only perform a limited set of operations on the primitive, without access to the internal state of the primitive, and lacks the authority to perform such limited operations as modification and destruction. The cloud computing platform allows limited operations to originate from within the authentication enclave and / or the allowed hash. These primitives may be referred to as "sealed authentication primitives". Storage primitives may be referred to as sealed authentication storage objects (SASOs), and key primitives may be referred to as sealed KMS keys (SSKs).

[0017] According to an example setting, a security service of a cloud service owned by an operator of a cloud computing platform periodically extracts client data from an external system. The owner of the client data is willing to share the credentials only if there is a provable technical guarantee that the credentials used to access the client data will never be shared with personnel associated with the operator of the cloud computing platform (e.g., engineers who build and / or operate the cloud computing platform) or any other person, and that the credentials cannot be used for any other purpose.

[0018] When audited and certified enclaves are available (so that users trust the security service to operate as required by the operator of the cloud platform), and when appropriate authentication mechanisms allow clients to verify that data requests are coming from the correct security service, the techniques of this disclosure solve the remaining security issues of storing credentials in a manner that is not accessible to personnel associated with the cloud computing platform.

[0019] According to reference Figure 1Considering the SASO approach, the operator of the cloud computing platform can own the SASO, and the enclave uses the SASO to store relevant credentials. In this way, the operator of the cloud computing platform creates the SASO, and the security service uses the SASO as a secure storage.

[0020] According to reference Figure 2 Considering the SKK approach, the operator of the cloud computing platform can have a KMS account and hold a storage encryption SKK that only the security service can use. The security service can then securely encrypt the credentials and store them in cloud storage for later use without the risk of leakage.

[0021] refer to Figure 1 , the example computing environment 100 includes a cloud platform 102 (also referred to herein as cloud 102). Cloud platform 102 may include any suitable number of servers 103 and storage devices (or simply "storage") 104 associated with a cloud provider to provide cloud computing and storage services to client systems (such as client system 110) via a computer network. Although to avoid confusion in Figure 1 Although not shown, the network may generally 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. The servers 103 and storage 104 associated with the cloud platform 102 may be distributed across multiple sites to improve reliability and reduce latency. Figure 1 Although not shown in the figure, each server 103 included in the cloud platform 102 may include one or more processors adapted and configured to execute various software stored in one or more memories. Therefore, the cloud platform 102 may include a computing component and a storage component.

[0022] The client system 110 may include multiple devices or servers forming a local network, or a single device, such as a portable device (e.g., a smartphone, a tablet computer), a laptop computer, a desktop computer, a wearable device, etc. The client system 110 may include a computer-readable memory and one or more processors that execute code stored in the computer-readable memory. The client system 110 may 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 the primitives 120. The client system 110 may control a client database 112, which may be implemented in any suitable manner, for example, as a database accessible from the cloud computing platform 102 using an API call.

[0023] exist Figure 1 In the example of , primitive 120 is a storage object for encrypted data 122 (e.g., logs, persistent state records, credentials, etc.). Storage object 120 further includes attributes 124 and access list 126. Although client system 110 is associated with the owner of primitive 120, cloud platform 102 restricts access to primitive 120, and even to client system 110, other than through security service 130 and according to a limited set of functions. Security service 130 runs in an authentication enclave 140 implemented in a trusted execution environment (TEE) 142. Any suitable number of authorized processes (such as, processes 145 and 146) can also execute within TEE 142.

[0024] Primitive 120 may be referred to as a "sealed authenticated storage object," or SASO, and may generally be any cloud storage object (e.g., a binary large object) that limits access and control of data to processes running in a secure container in an image with a specific hash, such as processes 145 and 146. For simplicity, some of the examples below specifically mention binary large objects, but the techniques of the present disclosure may also be applied to other more advanced storage types, such as tables, files, or databases.

[0025] In operation, the client system 110 or "owner" creates the SASO 120 using an atomic call 150, i.e., no other tasks can access the SASO 120 until the call 150 is completed. Alternatively, the client system 110 can authorize the security service 130 to create the SASO 120. As part of the object creation call, the client system 110 can set the allowed hashes, set the SASO life time (TTL), and set the maximum allowed size of the SASO 120. The call 150 can also include one or more options, such as (i) listing object metadata (e.g., name, size), (ii) granting other users the same access control list (ACL) that the owner has on the SASO 120, (iii) revoking the ACL granted to other users on the SASO 120, (iv) adding hashes to the SASO access list 126, and (v) removing hashes from the SASO access list 126. The TTL, maximum allowed size, and one or more optional parameters can be stored as parameters 124.

[0026] The client system 110 has the SASO 120, but cannot read, write, or delete the SASO 120. The security service 130 can perform data extraction 156 on the client data 112. The security service 130 can perform read, write, or delete operations 155 on the SASO 120. In order to delete the SASO 120, the client system 110 can issue an API call 152 via the storage API 132 and via the authentication enclave 140, or the cloud platform 102 can garbage collect the SASO 120. The cloud platform 102 can also garbage collect the SASO 120 when no instance of the authorization hash is active for a longer time than the TTL set when the SASO 120 was created. In this way, if the SASO 120 is not used, the cloud platform 102 eventually automatically deletes the SASO 120 according to the terms agreed to by the account that pays the storage fee. In some implementations, the cloud platform 102 similarly limits the size of the SASO 120 to limit operating costs.

[0027] When authorization processes 145 and 146 have authorized the corresponding hashes (i.e., the hashes included in access list 126), security service 130 running in attestation enclave 140 can (i) read, write, or delete SASO 120, (ii) add, remove, or modify hash list 126 that grants permissions to SASO 120, (iii) obtain the permission list assigned to itself by the SASO owner through create call 150 (e.g., if the SASO owner assigns itself the privilege to revoke access rights, then attestation enclave 140 may choose not to use SASO 120), and (iv) read the TTL of SASO 120.

[0028] The cloud platform 102 may encrypt all stored content (e.g., data 122), and may encrypt API calls in transit (e.g., in Hypertext Transfer Protocol Secure (HTTPS) messages). In addition, the decryption key 148 is not available to any user, including the account that owns the object. Instead, the decryption key 148 is used by the authentication enclave 140 as needed.

[0029] Next, we briefly consider the Figure 1 Several example use cases implemented in the environment of or similar environments.

[0030] Depending on the use case involving secure logs, an authenticated enclave (e.g., authenticated enclave 140) may write logs to authenticated storage (e.g., SASO 120). Cloud platform 102 ensures that these logs cannot be accessed or modified by any party outside of the authenticated enclave. If desired, the owner of the logs may configure cloud platform 102 to provide a mechanism to "break glass" (i.e., bypass security mechanisms) and access the logs within the authenticated enclave. In some implementations, breaking glass access requires permission (and visibility) from multiple parties.

[0031] According to another use case, cloud platform 102 provides clean room service state serialization. In this case, client system 110 runs a secure state service that needs to guarantee that its operator (i.e., client system 100) does not tamper with the service state. The secure state service can use certified storage (e.g., SASO 120) to maintain state between restarts, or maintain a consistent (but externally invisible) state. As a more specific example, a transaction-based service can store a write-ahead log in an certified storage.

[0032] Another example use case involves blind credential management. In this scenario, a specific operator controls the cloud platform 102 and services 130 running in the TEE 142. The operator is delegated external user credentials that can be used to periodically access sensitive information owned by the user. For example, this data can be a user identifier and password for a customer relationship management (CRM) account hosted outside the operator's system. For example, the cloud platform 102 can receive new data from the CRM account every day.

[0033] In this scenario, both the operator and the external user are interested in ensuring that these credentials cannot be used for any purpose outside of the TEE 142 or cannot be trusted by anyone. Although the credentials can be sent to the operator of the cloud platform 102 for secure storage in the TEE 142, there may also be reasons to store these credentials in a way that the external user does not have to enter the credentials every time the cloud platform 102 receives data. Serializing the credentials in the SASO object 120 created by the operator or external user is safe because this approach ensures that only the business logic in the TEE 142 (e.g., the authorization process 145) can access the credentials. In addition, when the operator of the cloud platform 102 is also the owner of the SASO object 120, this approach provides the additional advantage of not requiring the external user to create a cloud account associated with the cloud platform 102, but still benefiting from all the advantages of secure credential management.

[0034] According to another example, the use case is related to differential privacy (DP) in data processing, which is a mechanism for limiting the processing / aggregation of raw data to prevent any insights into the raw data from the aggregated results. In most cases, data processing / aggregation involves multiple steps, and each aggregation step consumes a portion of the budget (e.g., pre-aggregation, then ML training). SASO 120 can track the budget, providing technical guarantees that neither the operator nor the customer can tamper with the budget nor gain any insights from the raw data.

[0035] In another example case involving storage of a machine learning (ML) model for future reasoning, the data used to train the ML model is the product of a joint operation performed on a data set from an operator of the control cloud platform 102 and a data set from a customer. Generally speaking, it is desirable to protect ML models trained on such data because there is a risk that someone could gain insight into the training data by interfering with the iterations. SASO 120 can provide the required protection for the ML model without relying on managing encryption keys, while allowing the model to be loaded into TEE 142 again for reasoning.

[0036] Reference now Figure 2 , the example computing environment 200 is generally similar to the reference Figure 1 Discussion environment 100. Figure 1 Elements with reference numbers having the same two least significant digits as the elements in the example (e.g., elements 102 and 202, or 110 and 210) may be implemented in a manner similar to that discussed above and are not discussed below for simplicity. Figure 1 and Figure 2 The difference between.

[0037] Unlike primitive 120, primitive 221 is a sealed KMS key (SKK). Client system 210 in this example configuration owns SKK 221, but can only (i) create SKK 221 using atomic call 251. In an example implementation, as part of the create call, the caller can set the allowed hashes and set the SKK TLL. In addition, client system 210 can execute call 252 to delegate the authority to create SKK 221 to a confidential computing instance with a specific hash (e.g., process 145, 146), or remove such authority. Further, client system 210 can execute call 253 to list key metadata (e.g., to see how many keys exist and which hashes are authorized to use the key).

[0038] A client system 210 supporting an account that owns SKK 221 cannot (i) retrieve SKK 221 from the KMS, (ii) perform any encryption / decryption commands using SKK 221, or (iii) delete SKK 221. In some implementations, the client system 210 determines whether restriction (iii) applies when creating SKK 221 via call 251 by setting specific parameters. SKK 221 can be deleted by issuing an API call from the authentication enclave 240, or by garbage collecting SKK 221. In one example implementation, the cloud platform 202 can garbage collect SKK 221 when no instance of the authorization hash is active for a longer time than the TTL set at creation.

[0039] On the other hand, when the hash is correct, the KMS service 231 executing within the authentication enclave 240 can (i) perform any operation supported on the SKK 221 using the KMS, including encryption, decryption, and retrieval; (ii) add or remove the hash from the authorization list 226 for use with this SKK 221 on the KMS, or (iii) delete the SKK 221.

[0040] Reference above Figure 1 Most of the example use cases discussed also apply to Figure 2 However, it should be noted that SASO 120 is not accessible to anyone, not even the account owner, except for the logic within the authentication enclave 240. SKK 221 can be used to make stored data inaccessible to anyone by encrypting the data with an inaccessible key.

[0041] Additionally, as mentioned above, the account owner cannot delete SASO 120. However, the account owner can delete storage protected by SKK221.

[0042] Next, several example methods are discussed that may be implemented in the cloud computing platform 102 or 202. Each of these methods may be implemented as a set of instructions stored on a non-transitory computer-readable medium and executed by one or more processors.

[0043] Next, Figure 3A and Figure 3B An example method 300 is shown that can be implemented in the cloud platform 102 or 202 to create and configure a sealed primitive in response to an atomic call from a primitive owner. Figure 3A At block 302 of , the cloud platform 102 or 202 creates a primitive (e.g., SASO or SKK) in response to an atomic call from the owner of the primitive (e.g., from a client computing system). Figure 3BAt block 303 of , the cloud platform 102 or 202 creates the primitive in response to a call from within a confidential container (CC) executing in a TEE, such as TEE 142 or 242. In either case, flow proceeds to block 304, where the cloud platform 102 or 202 performs restricted operations associated with the primitive in response to a call from within an authenticated enclave. As discussed above, the owner of the primitive cannot make this call directly. Therefore, the cloud platform 102 or 202 prevents the owner of the primitive from performing operations such as read, write, and delete, but allows the owner to create primitives directly.

[0044] refer to Figure 4 , the cloud computing platform can implement method 400 to create a sealed authentication primitive, such as SASO 120 or SKK221. The cloud computing platform can call method 400 at box 302 or 303 discussed above. At box 402, the cloud computing platform sets one or more allowed hashes based on a create function call (e.g., call 150, call 251) from the owner of the sealed authentication primitive, which will be required for the authorized process in the TEE to perform read / write or encryption / decryption operations. At box 404, the cloud computing platform sets the TTL parameter of the sealed authentication primitive based on the create function call. Next, at box 406, the cloud computing platform sets optional parameters based on the create function call.

[0045] Finally, reference Figure 5 , the cloud computing platform can implement method 500 to perform restricted operations on a sealed authentication primitive such as SASO 120 or SKK 221. For example, the cloud computing platform can refer to Figure 3A and Figure 3B The method 500 is invoked at block 304 of discussion.

[0046] Method 500 begins at block 502, where the cloud computing platform receives a request to perform a restricted operation on a sealed authentication primitive. At block 504, the cloud computing platform determines whether the restricted operation (e.g., read / write / delete of SASO, encrypt / decrypt / delete of SKK) originates from within an authentication enclave (e.g., authentication 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 allowed hash (e.g., whether process 145 specifies a hash included in access list 126, or whether confidential computing instance 245 specifies a hash included in access list 226). If so, the flow proceeds to block 508, where the cloud computing platform allows the restricted function to be executed. Otherwise, the flow proceeds to block 510, where the cloud computing platform blocks the restricted function from being executed. As described above, the cloud computing platform here blocks the restricted operation even if the call originates from the owner of the sealed authentication primitive.

[0047] The following additional considerations apply to the foregoing discussion.

[0048] In some implementations, the paging message may be replaced with a paging record. In other implementations, the paging message may include one or more paging records, each of which pages a specific UE. For example, the paging message may include a paging record for UE 102.

[0049] The user device (e.g., UE 102) in which the technology of the present disclosure can be implemented can be any suitable device capable of wireless communication, such as a smart phone, a tablet computer, a laptop computer, a mobile game 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 smart watch), a wireless hotspot, a femtocell or a broadband router. In addition, in some cases, the user device can be embedded in an electronic system such as a head unit of a vehicle or an advanced driver assistance system (ADAS). Further, the user device can be operated as an Internet of Things (IoT) device or a mobile Internet device (MID). Depending on the type, the user device may include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0050] Certain embodiments are described in the present disclosure as including logic or multiple components or modules. A module may be a software module (e.g., code stored on a non-transitory machine-readable medium) or a hardware module. A hardware module is a tangible unit that is capable of performing certain operations and may be configured or arranged in a particular manner. A hardware module may include a dedicated circuit system or logic that is permanently configured (e.g., as a dedicated 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 include programmable logic or circuit systems (e.g., contained within a general-purpose processor or other programmable processor) that are temporarily configured by software to perform certain operations. The decision to implement a hardware module in a dedicated and permanently configured circuit system or in a temporarily configured circuit system (e.g., configured by software) may be driven by cost and time considerations.

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

[0052] As used herein, the terms "comprises," "comprising," "includes," "including," "has," "having," or any other variation thereof, are intended to encompass non-exclusive inclusions. For example, a process, method, article, or apparatus that includes 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. In addition, unless expressly stated to the contrary, "or" refers to an inclusive or rather than an exclusive or. For example, condition A or condition B is satisfied by any of the following: A is true (or exists) and B is false (or does not exist), A is false (or does not exist) and B is true (or exists), and both A and B are true (or exists).

Claims

1. An access control method implemented in a cloud computing platform, the method comprising: creating a primitive owned by a client system on the cloud computing platform in response to a first call, the client system accessing the cloud computing platform via a computer network; as well as In response to a second call from a process executing in an authenticated enclave implemented in a trusted execution environment (TEE) of the cloud computing platform, performing a restricted operation associated with the primitive, wherein the restricted operation is not directly available to the client system. 2 . The method of claim 1 , wherein the performing the restricted operation is further responsive to determining that the second call includes an allowed hash.

3. The method of claim 2, wherein: The first call includes a hash list including the allowed hashes.

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

5. The method of any one of the preceding claims, wherein the first call is from the process executing within the authentication enclave.

6. A method as claimed in any preceding claim, wherein the first call includes a time-to-live (TLL) parameter for the primitive.

7. The method according to any one of the preceding claims, further comprising: The primitive is automatically deleted based on the TTL parameter.

8. The method of any preceding claim, wherein the primitive is a Sealed Authentication Storage Object (SASO) comprising data associated with the client system.

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

10. The method of claim 8 or 9, wherein the first call includes a set of permissions, the set of permissions including at least one of the following: (i) list the metadata of the primitive in question, (ii) granting an access control list (ACL) to said client system that possesses said primitive to another system, (iii) revoke ACLs granted to systems other than the client system that owns the primitive, (iv) delete the said primitive, (v) adding the first hash that allows the second call, and (vi) Removing the second hash that allows the second call.

11. The method of any one of claims 8 to 10, wherein the restricted operation is one of: (i) Read command, (ii) Write command, or (iii) Delete order.

12. The method according to any one of claims 1 to 7, wherein the primitive is a Sealing Key Management Service (KMS) key (SKK) for encryption and / or decryption.

13. The method of claim 12, further comprising: A request for delegation of authority to the SKK is received from the client system that owns the primitive.

14. The method of claim 12, further comprising: Removal of a previous authorization delegation with respect to the SKK is received from the client system that owns the primitive.

15. The method of any one of claims 12 to 14, further comprising: In response to a request from the client system that owns the SKK, metadata for the SKK is provided.

16. The method of any one of claims 12 to 14, wherein the restricted operation is one of: (i) Encryption Commands, (ii) a decryption order, or (iii) Delete order.

17. A cloud computing platform comprising a group of servers and configured to implement the method according to any one of the preceding claims.

Images