EP4515431A1 - Sealed attested cloud storage and key management service primitives - Google Patents

Abstract

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

Description

SEALED ATTESTED CLOUD STORAGE AND KEY MANAGEMENT SERVICE PRIMITIVES

CROSS-REFERENCE TO RELATED TO APPLICATION

[0001] This application claims priority to and the benefit of the 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 content of the provisional application is hereby expressly incorporated herein by reference.

FIELD OF THE DISCLOSURE

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

BACKGROUND

[0003] This background description is provided for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.

[0004] Cloud computing is a network-based computing technique in which typically large groups of servers housed in data centers or “server farms” provide computational resources and data storage to remote end users. As the number of workflows utilizing first-party (IP) data in the cloud grows, new trust, privacy, and security paradigms are being considered to advance the guarantees given to data owners. These include using Trusted Execution Environments (TEEs), such as enclaves, confidential computing, and Secure Multi-Party Computation (MPC). Traditionally, the TEEs were created to support stand-alone computers and mobile devices to provide secure execution in the isolated trusted firmware based environments. In a public cloud, however, the traditional TEE technologies are inadequate.

[0005] Today, cloud-based TEE architectures anchor their security and privacy properties on both technology and trusting people, such as owners of accounts that hold decryption keys. According to one example approach, trust is increased by distributing secure information among multiple parties so that multiple stakeholders would need to violate their terms of service and collude to extract data which they are not authorized to access. Security for such architectures is based on the audit-attestation model. The technical mechanisms that make this security possible are the infrastructure for enclave attestation and conditional cryptographic operations, e.g., where certain keys can only be used from TEEs having a certain known hash.

[0006] However, even when customers use TEEs and Key Management Service (KMS)- enclave attestation, such security aspects of these approaches as differential privacy budgets and cryptographic key management still provide a certain degree of human exposure. In particular, someone must own the account that holds sensitive information when serialized, and the owner necessarily has access to the data, keys, etc. Although it is possible to seal the execution environment, it is not possible to seal the overall system including the serialized state. The currently available cloud technology does not allow sensitive information such as metadata, credentials, serialized state, and cryptographic keys to be accessible only by the code running in the TEE, while being opaque to everybody else, including the owner of the TEE deployment.

[0007] One available solution introduces the concept of “trusted parties” or “coordinators” as external entities that hold sensitive state in a way that any human operator could only partially access obfuscated partial sensitive information, and multiple parties need to collude retrieve data in an authorized manner. Notably, this approach still requires trusting at least one human operator. In addition to presenting difficulties with finding trusted parties, such approaches increase system complexity.

SUMMARY

[0008] An example embodiment of these techniques is an access control method implemented in a cloud computing platform. The method comprises creating, in response to a first call and on the cloud computing platform, a sealed primitive owned by a client system that accesses the cloud computing platform via a computer network; and performing, in response to a second call from a process executing in an attested enclave implemented in a trusted execution environment (TEE) of the cloud computing perform, a restricted operation related to the sealed primitive, where the restricted operation is unavailable directly to the client system.

[0009] Another example embodiment of these techniques is cloud computing platform comprising a set of servers and configured to implement the method above.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Fig. 1 is a block diagram of an example computing environment in which a cloud platform manages a sealed attested storage object (SASO) for a client system, in accordance with the techniques of this disclosure;

[0011] Fig. 2 is a block diagram of an example computing environment in which a cloud platform manages a sealed Key Management Service (KSM) key (SKK) for a client system, in accordance with the techniques of this disclosure;

[0012] Fig. 3 A is a flow diagram of an example method of creating and configuring a sealed primitive in response to an atomic call from an owner of the primitive, which can be implemented in the computing environment of Fig. 1 or Fig. 2;

[0013] Fig. 3B is a flow diagram of an example method of creating and configuring a sealed primitive in response to a call from within a confidential container (CC) executing in a TEE, which can be implemented in the computing environment of Fig. 1 or Fig. 2;

[0014] Fig. 4 is a flow diagram of an example method for creating a SASO or an SKK, which can be implemented in the computing environment of Fig. 1 or 2; and

[0015] Fig. 5 is a flow diagram for processing read/write/delete operations on a sealed attested primitive, which can be implemented in the computing environment of Fig. 1 or 2.

DETAILED DESCRIPTION OF THE DRAWINGS

[0016] As discussed in more detail below, a cloud computing platform provides a primitive such as a storage object or a KMS key, such that the owner of the primitive can perform only a limited set of operations on the primitive but has no access to the internal state of the primitive and lacks privileges to perform such restricted operations as modification and destruction. The cloud computing platform allows the restricted operations to originate from within an attested enclave and/or with an allowed hash. These primitives can be referred as “as sealed attested primitives.” A storage primitive can be referred as a sealed attested storage object (SASO), and a key primitive can be referred to as a sealed KMS key (SSK).

[0017] According to an example 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 is comfortable sharing credentials for accessing the client data only if there are technical provable guarantees that these credentials can never be shared with human parties associated with the operator of the cloud computing platform (e.g. the engineers that build and/or operate the cloud computing platform), or any other people, and that these credentials cannot be used for any other purpose.

[0018] When an enclave with audit and attestation is available (and thus when the user trusts that the secure service operates as claimed by the operator of the cloud platform), and when a proper authentication mechanism allows the client to verify that the request for data comes from the right secure service, the techniques of this disclosure address the remaining security concern of storing the credentials in a manner that is not accessible to human parties associated with the cloud computing platform.

[0019] According to the SASO approach considered with reference to Fig. 1, the operator of the cloud computing platform can own a SASO, and an enclave uses the SASO to store the relevant credentials. In this manner, the operator of the cloud computing platform creates a SASO, and the secure service uses the SASO as a secure storage.

[0020] According to the SKK approach considered with reference to Fig. 2, the operator of the cloud computing platform can a KMS account and hold a storage encryption SKK which only the secure service can use. The secure service then can safely encrypt the credentials and store the credentials for later use in cloud storage without the risk of exfdtration.

[0021] Referring to Fig 1, an example computing environment 100 includes a cloud platform 102 (also referred to herein as the 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 to provide cloud computing and storage services to client systems, such as a client system 110, via a computer network. Although not illustrated in Fig. 1 to avoid clutter, the network in general can include one or more wired and/or wireless communication links and may include, for example, a wide area network (WAN) such as the Internet, a local area network (LAN), a cellular telephone network, or another suitable type of network or combination of networks. The servers 103 and the memory 104 associated with the cloud platform 102 can be distributed across a plurality of sites for improved reliability and reduced latency. While not illustrated 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.

[0022] The client system 1 10 can include multiple devices or servers that form a local network or a single device such as a portable device (e.g., a smart phone, a tablet computer), a laptop computer, a desktop computer, a wearable device etc. 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 service provided by the cloud platform 102. In the examples discussed below, the service user is an owner of an account associated with client data 112 and of a primitive 120. The client system 110 can control a client database 112, which can be implemented in any suitable manner, e.g., as a database accessible from the cloud computing platform 102 using API calls.

[0023] In the example of Fig. 1, the primitive 120 is a storage object that encrypted data 122 such as a log, a persistent state record, 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 even to the client system 110, other than via a secure service 130 and in accordance with a limited set of functions. The secure service 130 operates in an attested enclave 140 implemented in a Trusted Execution Environment (TEE) 142. Any suitable number of authorized processes, such as processes 145 and 146, also can execute within the TEE 142.

[0024] The primitive 120 can be referred to as “sealed attested storage object” or SASO, and in general can be any cloud storage object (e.g. a blob) that restricts access and control of data to processes running in secure containers from an image having a specific hash, such as the processes 145 and 146. For simplicity, some of the examples below refer specifically to blobs, but the techniques of this disclosure also can apply to other higher-level 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., without access to the SASO 120 from other tasks until completion of the call 150. 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 setup the allowed hashes, set the SASO Time-To-Live (TTL) and set the maximum allowable size of the SASO 120. The call 150 also can include one or more options such as (i) a list the object metadata (e.g. name, size), (ii) a grant the same access control list (ACL) the owner has on the SASO 120 to other users, (iii) a revocation of ACLs granted on the SASO 120 to other users, (iv) addition of a hash to the SASO access list 126, and (v) a removal of hash from the SASO access list 126. The TTL, the maximum allowable size, and the one or more optional parameters can be stored as the parameters 124.

[0026] The client system 110 owns the SASO 120 but cannot read, write, or delete the SASO 120. The secure service 130 can execute data pulls 156 on the client data 112. The secure service 130 can execute 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 a storage API 132 and via the attested 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 there is no instance of any of the authorized hashes active for a period longer than the TTL set at creation of the SASO 120. In this manner, if the SASO 120 is not in use, the cloud platform 102 eventually deletes the SASO 120 automatically under the terms agreed upon by the account that pays for the storage. In some implementations, the cloud platform 102 similarly caps the size of the SASO 120, to limit operational cost.

[0027] When the authorized processes 145 and 146 have authorized respective hashes (i.e., the hashes included in the access list 126), the secure service 130 operating in the 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 on the SASO 120, (iii) obtain the list of permissions that the SASO owner allocated to itself via the creation call 150 (e.g. if SASO owner allocated to itself the privilege to revoke access, the attested enclave 140 may choose not to use the SASO 120), and (iv) read the TTL of the SASO 120.

[0028] The cloud platform 102 can encrypt all the storage contents (e.g., the data 122), and the API calls can be encrypted in transit (e.g. in a Hypertext Transfer Protocol Secure (HTTPS) message). Further, decryption keys 148 are not available to any user, including the account that owns the object. Instead, the decryption keys 148 are used as need by the attested enclave 140.

[0029] Several example use cases that can be implemented in the environment of Fig. 1 or a similar environment are briefly considered next.

[0030] According to a use case that concerns secure logs, an attested enclave (e.g., the attested enclave 140) can write logs into an attested storage (e.g., the SASO 120). The cloud platform 102 ensures that these logs are not accessible or modifiable by any party outside the attested enclave. If desired, the owner of the logs can configure the cloud platform 102 to provide, within the attested enclave, a mechanism for “breaking glass” (i.e., circumventing the security mechanism) and accessing the logs. In some implementations, the break-glass access requires permissions (and visibility) from multiple parties.

[0031] According to another use case, the cloud platform 102 provides a cleanroom service state serialization. The client system 110 in this case operates a secure stateful service that requires guarantees regarding its operator (i.e., the client system 100) not tampering with the service status. The secure stateful service may use the attested storage (e.g., the SASO 120) to persist the state between restarts, or to keep a consistent (but not externally visible) state. As a more specific example, a transaction-based service can store Write Ahead Logs in the attested storage.

[0032] Another example use case concerns blind credential management. In this scenario, a certain operator controls the cloud platform 102 and the service 130 running in the TEE 142.

The operator is entrusted with external user credentials, which can be used to periodically access sensitive information that a user owns. This data can be for example a user identifier and a password for a customer relationship management (CRM) account hosted outside the system of the operator. The cloud platform 102 can receive new data from the CRM account daily, for example.

[0033] In this scenario, both the operator and the external user are interested in guarantees that these credentials cannot be used outside of the TEE 142 for any purpose, or trusted to any human party. Although it is possible to send the credential over to the operator of the cloud platform 102 for safe storage in the TEE 142, there may be reasons also 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. It is safe to serialize the credential in the SASO object 120 created by either the operator or the external user, as this approach guaranteed that only the business logic in the TEE 142 (e.g., the authorized process 145) can access the credential. Further, when the operator of the cloud platform 102 is also the owner of the SASO object 120, this approach provides the additional advantage of eliminating the need for the external user to create a cloud account associated with the cloud platform 102, but still benefit from all the advantages of secure credential management.

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

[0035] In still another example case that concerns storing a machine learning (ML) model for future inference, the data used to train the ML model is the product of a join operation performed on a dataset from the operator that controls the cloud platform 102 and a dataset from a customer. Generally speaking, it is desirable to protect ML models trained on such data because of the risk of someone gaining insights into the training data with interference iterations. The SASO 120 can provide the required protection for the ML model without relying on managed encryption keys, while allowing loading the model into TEE 142 again for inference.

[0036] Now referring to Fig. 2, an example computing environment 200 is generally similar to the environment 100 discussed with reference to Fig. 1. Elements labeled with reference numbers that have the same two least significant digits as elements in Fig. 1 (e.g., elements 102 and 202, or 110 and 210) can be implemented similar to those discussed above, and for simplicity are not discussed again below. The differences between Figs. 1 and 2 are discussed next.

[0037] Unlike the primitive 120, a primitive 221 is Sealed KMS Key (SKK). The client system 210 in this example configuration owns the SKK 221 but can only (i) create the SKK 221 using an atomic call 251. As part of the creation call, the caller can set up the allowed hashes and set the SKK TLL, in an example implementation. Further, the client system 210 can execute a call 252 to delegate the authority to create SKK 221 to confidential compute instances having a certain hash (e.g., the processes 145, 146), or remove such authority. Still further, the client system 210 can execute a call 253 to list the key metadata (e.g. see how many keys exist, what hashes are authorized to use them).

[0038] The client system 210, which supports the account that owns the SKK 221, cannot (i) retrieve the SKK 221 from the KMS, (ii) execute any encrypt/ decry pt command using the SKK 221, or (iii) delete the SKK 221. In some implementations, the client system 210 determines whether the restriction (iii) applies when creating the SKK 221 via the call 251, by setting a certain parameter. Deletion of the SKK 221 can be achieved by either issuing an API call from the attested enclave 240, or by garbage-collecting the SKK 221. The cloud platform 202 can garbage-collect the SKK 221 when there are no instances of any of the authorized hashes active for a period longer than the TTL set at creation, in an example implementation.

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

[0040] The example use cases discussed above with reference to Fig. 1 for the most part apply to Fig. 2 as well. However, it is noted that the SASO 120 is not accessible to anybody, even the account owner, other than the logic within the attested enclave 240. The SKK 221 can be used to make data in storage inaccessible to anybody by encrypting the data with an inaccessible key. [0041] Further, as discussed above, an account owner cannot delete the SASO 120. However, an account owner can delete a storage protected by the SKK 221.

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

[0043] Next, Figs. 3A and 3B illustrates an example method 300 of creating and configuring a sealed primitive in response to an atomic call from an owner of the primitive, which can be implemented in the cloud platform 102 or 202. At block 302 of Fig. 3A, the cloud platform 102 or 202 creates a primitive (e.g., a SASO or an SKK) in response to an atomic call from the owner of the primitive, e.g., from a client computing system. At block 303 of Fig. 3B, however, the cloud platform 102 or 202 creates a primitive in response to a call from within a confidential container (CC) executing in a TEE, such as the TEE 142 or 242. In either case, the flow proceeds to block 304 where the cloud platform 102 or 202 performs a restricted operation related to the primitive in response to a call from within the attested enclave. As discussed 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 such operations read, write, and delete, while allowing the owner to create the primitive directly.

[0044] Referring to Fig. 4, a cloud computing platform can implement a method 400 to create a sealed attested primitive such as the SASO 120 or the SKK 221. The cloud computing platform can invoke the method 400 at block 302 or 303 discussed above. At block 402, the cloud computing platform sets up the one or more allowable hashes, which will be required for an authorized process in a TEE to perform read/write or encrypt/decrypt operations, in accordance with a creation function call from the owner of the sealed attested primitive (e.g., the call 150, the call 251). At block 404, the cloud computing platform sets the TTL parameter of the sealed attested primitive, in accordance with the creation function call. Next, at block 406, the cloud computing platform sets optional parameters in accordance with the creation function call.

[0045] Finally, referring to Fig. 5, a cloud computing platform can implement a method 500 to perform a restricted operation on a sealed attested primitive such as the SASO 120 or the SKK 221. The cloud computing platfomi can invoke the method 500 at block 304 discussed above with reference to Figs. 3A and 3B, for example.

[0046] The method 500 begins at block 502, where the cloud computing platform receives a request to perform a restricted operation on the sealed attested primitive. At block 504, the cloud computing platform determines whether the restricted operation (e.g., read/write/delete for a SASO, encrypt/decrypt/delete for an SKK) originated within an attested enclave (e.g., the attested 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 a call requesting the restricted operation was associated with an allowable hash (e.g., whether the process 145 specified a hash included in the access list 126, or whether the confidential compute instance 245 specified a hash included in the 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 discussed above, the cloud computing platform here blocks the restricted operation even if the call originates from the owner of the sealed attested primitive.

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

[0048] In some implementations, the paging message can be replaced by a paging record. In other implementations, the paging message can include one or more paging records, where each paging record pages a particular UE. For example, the paging message can include a paging record for the UE 102.

[0049] A user device in which the techniques of this disclosure can be implemented (e.g., the UE 102) can be any suitable device capable of wireless communications such as a smartphone, a tablet computer, a laptop computer, a mobile gaming console, a point-of-sale (POS) terminal, a health monitoring device, a drone, a camera, a media-streaming dongle or another personal media device, a wearable device such as a smartwatch, a wireless hotspot, a femtocell, or a broadband router. Further, the user device in some cases may be embedded in an electronic system such as the head unit of a vehicle or an advanced driver assistance system (ADAS). Still further, the user device can operate as an intemet-of-things (loT) 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.

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

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

[0052] 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 to 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

What is claimed is:

1. An access control method implemented in a cloud computing platform, the method comprising: creating, in response to a first call and on the cloud computing platform, a primitive owned by a client system that accesses the cloud computing platform via a computer network; and performing, in response to a second call from a process executing in an attested enclave implemented in a trusted execution environment (TEE) of the cloud computing perform, a restricted operation related to the primitive, wherein the restricted operation is unavailable directly to the client system.

2. The method of claim 1, wherein the performing of the restricted operation is further in response to determining that the second call includes an allowable hash.

3. The method of claim 2, wherein: the first call incudes a listing of hashes including the allowable hash.

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

5. The method of any of the preceding claims, wherein the first call is from the process executing in the attested enclave.

6. The method of any of the preceding claims, wherein the first call incudes a time- to-live (TLL) parameter for the primitive.

7. The method of any of the preceding claims, further comprising: automatically deleting the primitive based on the TTL parameter.

8. The method of any of the preceding claims, wherein the primitive is a sealed attested storage object (SASO) that incudes data associated with the client system.

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

10. The method of claim 8 or 9, wherein the first call includes a set of permissions including at least one of:

(i) list metadata for the primitive,

(ii) grant, to another system, an access control list (ACL) of the client system that owns the primitive,

(iii) revoke an ACL granted to a system other than the client system that owns the primitive,

(iv) delete the primitive,

(v) add a first hash with which the second call is allowed, and

(vi) remove a second hash with which the second call is allowed.

11. The method of any of claims 8-10, wherein the restricted operation is one of:

(i) a read command,

(ii) a write command, or

(iii) a delete command.

12. The method of any of claims 1-7, wherein the primitive is a sealed Key Management Service (KMS) key (SKK) for use with encryption and/or decryption.

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

14. The method of claim 12, further comprising: receiving, from the client system that owns the primitive, a remove a prior delegation of authority with respect to the SKK.

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

16. The method of any of claims 12-14, wherein the restricted operation is one of:

(i) an encryption command,

(ii) a decryption command, or

(iii) a delete command.

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