Sealed, certified cloud storage and key management service primitives

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 into this specification.

[0002] This 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 disclosure. The work of the inventors specified in this specification is not admitted as prior art to this disclosure, either expressly or implicitly, including in the aspects of the description that may not be eligible as prior art at the time of filing and within the scope described in this background art section.

[0004] Cloud computing is a network-based computing technique in which large groups of servers, typically housed in data centers or "server farms," ​​provide computing resources and data storage to remote end users. As the number of workflows utilizing first-party (1P) data in the cloud increases, new paradigms of trust, privacy, and security are being considered to improve the guarantees given to data owners. These include the use of Trusted Execution Environments (TEEs), such as enclaves, confidential computing, and secure Multi-Party Computation (MPC). Traditionally, TEEs were created to support standalone computers and mobile devices to provide secure execution in isolated, trusted firmware-based environments. However, traditional TEE technologies are insufficient in public clouds.

[0005] Currently, cloud-based TEE architectures maintain their security and privacy characteristics both technologically and with trusted parties, such as account owners who hold the decryption keys. One approach enhances trust by distributing secure information among multiple parties, requiring several stakeholders to collude to extract data they are not authorized to access, thus violating their terms of service. The security of such architectures is based on the audit-attestation model. The technical mechanisms that enable this security are the infrastructure of enclave attestation and conditional cryptographic behavior, for example, ensuring that a particular key can only be used from a TEE with a specific known hash.

[0006] However, even when customers use TEE and Key Management Service (KMS) enclave attribution, the security aspects of these approaches, such as differential privacy budgets and cryptographic key management, are still somewhat exposed to others. In particular, someone needs to own an account that holds sensitive information during serialization, and that owner inevitably has access to data, keys, etc. While it is possible to seal the execution environment, it is not possible to seal the entire system, including the serialization state. With currently available cloud technologies, sensitive information such as metadata, credentials, serialization state, and cryptographic keys is only accessible to the code running in the TEE, and is not made opaque to everyone else, including the owner of the TEE deployment.

[0007] One available solution involves introducing the concept of a "trusted party" or "coordinator" as an external entity holding the sensitive state, allowing any human operator to partially access some obfuscated sensitive information, and requiring multiple parties to collude to retrieve the data in an authorized manner. However, even this approach still requires trusting at least one operator. In addition to the difficulty in finding a trusted party, such approaches increase the complexity of the system. [Overview of the Initiative]

[0008] An exemplary embodiment of these technologies is an access control method implemented on a cloud computing platform. The method includes, in response to a first call, creating a sealed primitive on the cloud computing platform owned by a client system accessing the cloud computing platform via a computer network, and, in response to a second call from a process running in an attested enclave implemented within a trusted execution environment (TEE) of the cloud computing execution, performing restricted actions with respect to the sealed primitive, wherein the restricted actions are not directly available to the client system.

[0009] Another exemplary embodiment of these technologies is a cloud computing platform that includes a set of servers and is configured to implement the methods described above. [Brief explanation of the drawing]

[0010] [Figure 1] This is a block diagram of an exemplary computing environment in which a cloud platform manages SASOs (sealed attested storage objects) of client systems using the technology disclosed herein. [Figure 2] This is a block diagram of an exemplary computing environment in which a cloud platform manages sealed Key Management Service (KSM) keys (SKKs) of client systems using the technology disclosed herein. [Figure 3A] This is a flowchart illustrating an exemplary method for creating and setting a sealed primitive in response to an atomic call from the primitive's owner, which can be implemented in the computing environment shown in Figure 1 or Figure 2. [Figure 3B] This is a flowchart illustrating an exemplary method for creating and configuring sealed primitives in response to calls from within a sensitive container (CC) running in a TEE, which can be implemented in the computing environment of Figure 1 or Figure 2. [Figure 4] This is a flowchart illustrating an exemplary method for creating a SASO or SKK, which can be implemented in the computing environment shown in Figure 1 or Figure 2. [Figure 5] This is a flowchart for handling read / write / delete operations on sealed, proven primitives, which can be implemented in the computing environment shown in Figure 1 or Figure 2. [Modes for carrying out the invention]

[0011] As will be discussed in more detail below, cloud computing platforms provide primitives such as storage objects or KMS keys, so that the owner of a primitive can perform only a limited set of operations on the primitive, but does not have access to the primitive's internal state and lacks the privileges to perform restricted operations such as modification and destruction. Cloud computing platforms enable restricted operations to be initiated from within an attested enclave and / or by authorized hashes. These primitives may be referred to as "sealed attested primitives." Storage primitives may be referred to as SASOs (sealed attested storage objects), and key primitives may be referred to as sealed KMS keys (SSKs).

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

[0013] If an enclave with auditing and attribution is available (and therefore the user trusts that the secure service operates as requested by the cloud platform operator), and if an appropriate authentication mechanism allows the client to verify that the data request is from the correct secure service, the technology of this disclosure addresses the remaining security concerns of storing credentials in a way that is inaccessible to any party associated with the cloud computing platform.

[0014] According to the SASO approach discussed with reference to Figure 1, 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 secure service uses the SASO as secure storage.

[0015] According to the SKK approach discussed with reference to Figure 2, a cloud computing platform operator can have a KMS account and hold a storage encryption SKK that can only be used by Secure Services. Secure Services can then securely encrypt the credentials and store them in cloud storage for later use without the risk of exfiltration.

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

[0017] The client system 110 may include a local network or multiple devices or servers forming a single device such as a portable device (e.g., a smartphone, tablet computer), a laptop computer, a desktop computer, or a wearable device. The client system 110 may include 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 the account associated with the client data 112 and the primitive 120. The client database 112 can be controlled by the client system 110 and can be implemented in any suitable way, for example, as a database accessible from the cloud computing platform 102 using API calls.

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

[0019] Primitive 120 may be referred to as a “Sealed Assured Storage Object” or SASO, and can generally be any cloud storage object (e.g., a blob) that restricts access to and control of data from an image with a specific hash to a process running in a secure container, such as processes 145 and 146. For simplicity, some of the following examples refer specifically to blobs, but the techniques of this 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 "owner," creates SASO120 using an atomic call 150, i.e., without access to SASO120 from other tasks until the call 150 is completed. Alternatively, the client system 110 may authorize the secure service 130 to create SASO120. As part of the object creation call, the client system 110 may set up the allowed hash, set the SASO's TTL (Time-To-Live), and set the maximum allowed size of SASO120. The call 150 may also include one or more options, such as (i) a list of object metadata (e.g., name, size), (ii) granting other users the same access control list (ACL) that the owner has on SASO120, (iii) revoking ACLs granted to other users on SASO120, (iv) adding a hash to the SASO access list 126, and (v) removing a hash from the SASO access list 126. The TTL, maximum allowable size, and one or more optional 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 proven 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 storage. In some embodiments, the cloud platform 102 also caps 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 proven 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 create call 150 by the SASO owner (e.g., if the SASO owner has assigned privileges to itself to revoke access, the configured and proven 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 trusted 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 the use case for secure logs, the trusted enclave (e.g., trusted enclave 140) can write logs to the trusted storage (e.g., SASO 120). The cloud platform 102 ensures that no party outside the trusted 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 trusted enclave. In some embodiments, break glass access requires permissions (and visibility) from multiple parties.

[0026] In another use case, the cloud platform 102 provides cleanroom service state serialization. In this case, client system 110 operates a secure stateful service that requires a guarantee that its operator (i.e., client system 100) will not tamper with the service status. The secure stateful service may use as-certified storage (e.g., SASO 120) to persist its state between reboots or maintain a consistent (but not externally visible) state. As a more specific example, a transactional service may store log-first writes in as-certified storage.

[0027] Another example of a use case relates to blind credential management. In this scenario, a specific operator controls a cloud platform 102 and a service 130 running on 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 could 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, for example, receive new data from the CRM account daily.

[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 of TEE142, or that they cannot be trusted by any party. While it is possible to send the credentials to the operator on cloud platform 102 for secure storage on TEE142, there may also be reasons to store these credentials in a way that does not require the external user to enter the credentials every time cloud platform 102 receives data. Serializing the credentials within a SASO object 120 created by either the operator or the external user is secure because this approach ensures that only business logic within TEE142 (e.g., authorized process 145) can access the credentials. Furthermore, if the operator on cloud platform 102 is also the owner of the SASO object 120, this approach not only provides the additional benefit of eliminating the need for the external user to create a cloud account associated with cloud platform 102, but also benefits from all the advantages of secure credential management.

[0029] Further examples illustrate that the use case relates to differential privacy (DP) in data processing, where DP is a mechanism for limiting the processing / aggregation of raw data so that no insights about the raw data can be gained from the aggregated results. In most cases, data processing / aggregation involves multiple steps, and each step of aggregation can consume a portion of the budget (e.g., pre-aggregation, then ML training). SASO120 can track the budget and provide a technical guarantee that neither the operator nor the customer can tamper with the budget and gain any insights from the raw data.

[0030] In yet another example of the case concerning storing machine learning (ML) models for future inference, the data used to train the ML model is the product of combined operations performed on datasets from the operator controlling the cloud platform 102 and datasets from customers. Generally speaking, ML models trained on such data are desirable to be protected because repeated interference poses a risk that someone may gain insights into the training data. SASO120 can provide the necessary protection for the ML model without relying on managed cryptographic keys, while still allowing the model to be reloaded into TEE142 for inference.

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

[0032] Unlike primitive 120, primitive 221 is a sealed KMS key (SKK). In this exemplary configuration, client system 210 owns SKK221 but can only (i) create SKK221 using atomic call 251. As part of the creation call, the caller can set up an allowed hash and configure the SKK TLL in this exemplary embodiment. Furthermore, client system 210 can execute call 252 to delegate the authority to create SKK221 to a sensitive compute instance (e.g., processes 145, 146) with a specific hash, or to remove such authority. Also, client system 210 can execute call 253 to list key metadata (e.g., how many keys exist and which hashes are authorized to use them).

[0033] A client system 210 supporting an account that owns an SKK221 cannot (i) retrieve the SKK221 from the KMS, (ii) use the SKK221 to execute any encryption / decryption commands, or (iii) delete the SKK221. In some embodiments, the client system 210 determines whether to apply restriction (iii) when creating an SKK221 via call 251 by setting certain parameters. Deletion of an SKK221 can be achieved either by issuing an API call from the proven enclave 240 or by garbage collecting the SKK221. In an exemplary embodiment, the cloud platform 202 may garbage collect an SKK221 if there are no instances of authorized hashes that have been active for longer than the TTL set at creation.

[0034] On the other hand, the KMS service 231 running within the proven enclave 240 may, if the hash is correct, (i) perform any operation supported by KMS on SKK221, including encryption, decryption, and retrieval; (ii) add or remove hashes from the list 226 authorized by KMS for use by this SKK221; or (iii) delete SKK221.

[0035] In most cases, the use case examples described above, with reference to Figure 1, also apply to Figure 2. However, it should be noted that no one, not even the account owner, can access SASO120 except for the logic within the proven enclave 240. Data in storage can be made inaccessible to anyone by encrypting it with an inaccessible key using SKK221.

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

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

[0038] Next, Figures 3A and 3B illustrate an exemplary method 300 for creating and setting up a sealed primitive in response to an atomic call from the primitive's owner, which can be implemented in a cloud platform 102 or 202. In block 302 of Figure 3A, the cloud platform 102 or 202 creates a primitive (e.g., SASO or SKK) in response to an atomic call from its owner, for example, from a client computing system. However, in block 303 of Figure 3B, the cloud platform 102 or 202 creates the primitive in response to a call from within a confidential container (CC) running in a TEE, such as TEE 142 or 242. In either case, the flow proceeds to block 304, where the cloud platform 102 or 202 performs restricted actions related to the primitive in response to a call from within an as-certified enclave. As described above, the primitive's owner cannot make this call directly. Therefore, the cloud platform 102 or 202 prevents the primitive owner from performing such operations as reading, writing, and deleting, but allows the owner to create primitives directly.

[0039] Referring to Figure 4, the cloud computing platform can implement method 400 for creating a sealed, certified primitive such as SASO120 or SKK221. The cloud computing platform can invoke method 400 in block 302 or 303 above. In block 402, the cloud computing platform sets up one or more acceptable hashes required for an authorized process of the TEE to perform a read / write or encryption / decryption operation, in accordance with a create function call from the owner of the sealed, certified primitive (e.g., call 150, call 251). In block 404, the cloud computing platform sets the TTL parameter of the sealed, certified primitive in accordance with a create function call. Next, in block 406, the cloud computing platform sets optional parameters in accordance with a create function call.

[0040] Finally, referring to Figure 5, the cloud computing platform can implement method 500 for performing restricted operations on sealed, proven primitives such as SASO120 or SKK221. The cloud computing platform can invoke method 500 in block 304 described above, for example, referring to Figures 3A and 3B.

[0041] Method 500 begins in block 502, where the cloud computing platform receives a request to perform a restricted operation on a sealed, attributable primitive. In block 504, the cloud computing platform determines whether the restricted operation (e.g., read / write / delete SASO, encrypt / decrypt / delete SKK) occurred within an attributable enclave (e.g., attributable enclave 140 or 240). If so, the flow proceeds to block 506; otherwise, the flow proceeds to block 510. In block 508, the cloud computing platform determines whether the call requesting the restricted operation was associated with an acceptable hash (e.g., whether process 145 specified a hash included in access list 126, or whether sensitive computing instance 245 specified a hash included in access list 226). If so, the flow proceeds to block 508, where the cloud computing platform allows the execution of the restricted function. Otherwise, the flow proceeds to block 510, where the cloud computing platform blocks the execution of the restricted function. As mentioned above, the cloud computing platform here blocks restricted behavior even when the call originates from the owner of a sealed, authenticated primitive.

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

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

[0044] A user device (e.g., UE102) that can implement the technology of this disclosure may be any suitable wirelessly communicating device, such as a smartphone, tablet computer, laptop computer, mobile game console, point-of-sale (POS) terminal, health management device, drone, camera, media streaming dongle or other personal media device, wearable device such as a smartwatch, wireless hotspot, femtocell, or broadband router. Furthermore, the user device may be embedded in an electronic system such as a vehicle head unit or advanced driver-assistance system (ADAS). Moreover, the user device may operate 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, computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0045] Certain embodiments described in this disclosure include logic, or several components or modules. A module may be a software module (e.g., code stored in a non-temporary machine-readable medium) or a hardware module. A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in certain ways. A hardware module may include dedicated circuitry or logic that is permanently configured (e.g., as a field-programmable gate array (FPGA) or an application-specific processor such as an application-specific integrated circuit (ASIC)) to perform certain operations. A hardware module may also include programmable logic or circuitry that is temporarily configured by software (e.g., contained within a general-purpose processor or other programmable processor) 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 depend on cost and time considerations.

[0046] When implemented in software, the technique may be provided as part of an operating system, a library used by multiple applications, or a specific software application. The software can run on one or more general-purpose processors or one or more special-purpose processors.

[0047] As used herein, “comprises,” “comprising,” “includes,” “including,” “has,” “having,” or any other variation thereof are intended to encompass non-exclusive inclusion. For example, a process, method, item, or apparatus that includes a list of elements is not necessarily limited to these elements alone, and may include other elements not expressly enumerated or inherent in such process, method, item, or apparatus. Furthermore, unless expressly stated otherwise, “or” refers to an inclusive or not an exclusive or. For example, condition A or B is satisfied by any one of the following: A is true (or exists) and B is false (or does not exist), A is false (does not exist) and B is true (or exists), and both A and B are true (or exist).

Claims

1. An access control method implemented in a cloud computing platform, In response to a first call, create a primitive on the cloud computing platform owned by a client system accessing the cloud computing platform via a computer network, wherein the primitive is a sealed attested storage object (SASO) containing data associated with the client system. In response to a second call from a process running in an attributed enclave implemented within the trusted execution environment (TEE) of the cloud computing platform, the restricted operation with respect to the primitive is performed, wherein the restricted operation is not directly available to the client system. A method including the first call including a set of permissions.

2. The method according to claim 1, wherein performing the restricted operation further responds to determining that the second call contains an acceptable hash.

3. The method of claim 2, wherein the first call further comprises a list of hashes containing the acceptable hashes.

4. The method according to claim 1, wherein the first call is an atomic call from the client system.

5. The method according to claim 1, wherein the first call is from the process performed in the constituted enclave.

6. The method according to claim 1, wherein the first call further includes a TTL (time-to-live) parameter of the primitive.

7. The method according to claim 6, further comprising automatically deleting the primitive based on the TTL parameter.

8. The method according to claim 1, wherein the first call further includes a maximum allowable size parameter for the primitive.

9. The aforementioned set of permissions is (i) Listing the metadata of the primitives, (ii) Granting an access control list (ACL) of the client system that owns the primitive to another system, (iii) Revoke the ACL granted to a system other than the client system that owns the primitive, (iv) Deleting the primitives, (v) Adding a first hash which allows the second call, (vi) removing the second hash which allows the second call, The method according to claim 1, comprising at least one of the following.

10. The aforementioned restricted operation is (i) Read command, (ii) Write command, or (iii) Delete command, The method according to claim 1, which is one of the methods.

11. An access control method implemented in a cloud computing platform, In response to a first call, create a primitive on the cloud computing platform owned by a client system accessing the cloud computing platform via a computer network, wherein the primitive is a sealed Key Management Service (KMS) key (SKK) for use by encryption and / or decryption. In response to a second call from a process running in an attributed enclave implemented within the trusted execution environment (TEE) of the cloud computing platform, the restricted operation with respect to the primitive is performed, wherein the restricted operation is not directly available to the client system. Receiving a request from the client system that owns the primitive to delegate authority regarding the SKK, Methods that include...

12. An access control method implemented in a cloud computing platform, In response to a first call, create a primitive on the cloud computing platform owned by a client system accessing the cloud computing platform via a computer network, wherein the primitive is a sealed Key Management Service (KMS) key (SKK) for use by encryption and / or decryption. In response to a second call from a process running in an attributed enclave implemented within the trusted execution environment (TEE) of the cloud computing platform, the restricted operation with respect to the primitive is performed, wherein the restricted operation is not directly available to the client system. Receiving the removal of the prior delegation of authority regarding the SKK from the client system that owns the primitive, Methods that include...

13. An access control method implemented in a cloud computing platform, In response to a first call, create a primitive on the cloud computing platform owned by a client system accessing the cloud computing platform via a computer network, wherein the primitive is a sealed Key Management Service (KMS) key (SKK) for use by encryption and / or decryption. In response to a second call from a process running in an attributed enclave implemented within the trusted execution environment (TEE) of the cloud computing platform, the restricted operation with respect to the primitive is performed, wherein the restricted operation is not directly available to the client system. To provide metadata of the SKK in response to a request from the client system that owns the SKK, Methods that include...

14. The aforementioned restricted operation is (i) Encryption command, (ii) Decryption command, or (iii) Delete command, The method according to claim 11, which is one of the methods.

15. The restricted operation is: (i) Encryption command, (ii) Decryption command, or (iii) Delete command, The method according to claim 12, which is one of the methods.

16. The restricted operation is: (i) Encryption command, (ii) Decryption command, or (iii) Delete command, The method according to claim 13, which is one of the methods.

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

Images