Patent Description:
<CIT> relates to distributed-secure-storage systems, and processes carried out within the distributed-secure-storage systems, that provide for secure storage and retrieval of secrets within distributed computer systems, including private encryption keys used for client authentication during establishment of secure communications channels. The secret-storage systems partition an input secret into multiple secret shares and distribute the secret shares among multiple secret-share-storing node subsystems, without persistently storing the secret itself. An agent within a client device subsequently requests a secret share corresponding to a secret, or a share of data derived from the secret share, from each of the multiple secret-share-storing nodes. Each secret-share-storing node transmits the requested secret share or derived-data share to the agent, which reconstructs the secret from all or a portion of the secret shares or a data value from all or a portion of the derived-data shares transmitted to the agent.

<CIT> describes methods for managing encrypted files by storing a user password hash including a predetermined function of the user password associated with that user ID and the secret keys. Aspects also include, in response to receipt from a user computer of an input password and a user ID for a required encrypted file, communicating with authentication servers to implement a key-reconstruction protocol in which each server computes first and second hash values for the required encrypted file. The file management server uses the first hash values to compute an input password hash including the predetermined function of the input password and the secret keys, checks if the input password hash matches the user password hash for the received user ID, and reconstructs the encryption key for the required encrypted file.

<CIT> describes methods, systems, and apparatus, including computer programs encoded on a computer storage medium, for instantiating and managing systems that utilize hierarchal enclaves in a cloud environment.

<NPL> describes a design for a system of anonymous storage which resists the attempts of powerful adversaries to find or destroy any stored data. Distinct notions of anonymity for each party in the system are enumerated, and a way to classify anonymous systems based on the kinds of anonymity provided is proposed. The design ensures the availability of each document for a publisher-specified lifetime. A reputation system provides server accountability by limiting the damage caused from misbehaving servers. Attacks and defenses against anonymous storage services are also identified.

<NPL> relates to improving the security and privacy in electronic health record systems. The approach is based on an analysis of real-world incidents, namely theft and misuse of patient identity, unauthorized usage and update of electronic health records, and threats from insiders in healthcare organizations. The approach includes design and development of a user-centric monitoring agent system that works on behalf of a patient (i.e., an end user) and securely monitors usage of the patient's identity credentials as well as access to her electronic health records. Such a monitoring agent can enhance patient's awareness and control and improve accountability for health records even in a distributed, multi-domain environment, which is typical in an e-healthcare setting. This will reduce the risk and loss caused by misuse of stolen data. A secure system architecture is also proposed that can be used in healthcare organizations to enable robust auditing and management over client devices. This helps us further enhance patients' confidence in secure use of their health data.

According to some embodiments, methods and systems may be associated with a cloud computing environment. Methods and systems may be associated with a cloud computing environment. A proxy platform data store may contain node data associated with nodes of the cloud computing environment. Each node might, for example, store multi-party computation information. A proxy platform, able to access the proxy platform data store, may detect that a first node needs to access a cloud application secret key and determine, based on information in the proxy platform data store, a set of nodes associated with the secret key that the first node needs to access. The proxy platform may then use a multi-party computation algorithm and information received from the set of nodes to generate the secret key. Some embodiments comprise: means for detecting, by a proxy platform, that a first node needs to access a cloud application secret key; means for determining, based on information in a proxy platform data store, a set of nodes associated with the secret key that the first node needs to access, wherein the proxy platform data store contains node data associated with nodes of a cloud computing environment, each node storing multi-party computation information; and means for using a multi-party computation algorithm and information received from the set of nodes to generate the secret key.

Some technical advantages of some embodiments disclosed herein are improved systems and methods to facilitate protection of a cloud computing environment secret key using a multi-party computation algorithm in a secure, automatic, and efficient manner.

In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of embodiments. However, it will be understood by those of ordinary skill in the art that the embodiments may be practiced without these specific details. In other instances, well-known methods, procedures, components and circuits have not been described in detail so as not to obscure the embodiments.

Many cloud applications deployed on cloud platforms, such as cloud foundry or Kubernetes, need a way to store credentials for accessing other services (e.g., a database or third-party service such as an object store, etc.). For example, <FIG> illustrates an example <NUM> of a cloud computing node <NUM> (e.g., a Virtual Machine ("VM") or container) executing an application <NUM> and having a memory <NUM> and a disk <NUM> storing a password <NUM>. The password <NUM> or similar credentials are often stored in plain text on the disk <NUM> or in the memory <NUM> of a process. If encryption is applied to these credentials, the keys may be stored on the disk <NUM> (so that those can be fetched during runtime to decrypt the credentials). This approach can lead to a security risk because those keys are may be stored, for example, the disk <NUM> and if storage is compromised the whole system may be compromised. On the other hand, if the node <NUM> or application <NUM> is compromised, the memory or by snooping over the network, a key can be deciphered because not all internal communications may be Secure Sockets Layer ("SSL") enabled.

If the key is stored on the disk <NUM> and brought over the network completely, the system runs the risk of compromise either on storage or attacks such as SSL high jacking even if SSL is enabled. If instead of using credentials, the system uses a secure storage, then in that case the credentials to access the secure storage needs to be provisioned within the application <NUM>. Therefore, the problems remain the same. Any compromise to the application <NUM> may render the credentials either of the application <NUM> or of the secure storage open to an attacker.

To address such problems, <FIG> is a high-level block diagram of a system <NUM> in accordance with some embodiments. The system <NUM> includes a proxy platform <NUM> that accesses information in a proxy platform data store <NUM>. The proxy platform <NUM> might use this information, for example, to help determine a secret key for a cloud computing application. The process might be performed automatically or be initiated via a command from a remote operator interface device. As used herein, the term "automatically" may refer to, for example, actions that can be performed with little or no human intervention.

As used herein, devices, including those associated with the system <NUM> and any other device described herein, may exchange information via any communication network which may be one or more of a Local Area Network ("LAN"), a Metropolitan Area Network ("MAN"), a Wide Area Network ("WAN"), a proprietary network, a Public Switched Telephone Network ("PSTN"), a Wireless Application Protocol ("WAP") network, a Bluetooth network, a wireless LAN network, and/or an Internet Protocol ("IP") network such as the Internet, an intranet, or an extranet. Note that any devices described herein may communicate via one or more such communication networks.

The proxy platform <NUM> may store information into and/or retrieve information from various data stores (e.g., the proxy platform data store <NUM>), which may be locally stored or reside remote from the proxy platform <NUM>. Although a single proxy platform <NUM> and proxy platform data store <NUM> are shown in <FIG>, any number of such devices may be included. Moreover, various devices described herein might be combined according to embodiments of the present invention. For example, in some embodiments, the proxy platform data store <NUM> and the proxy platform <NUM> might comprise a single apparatus. The system <NUM> functions may be performed by a constellation of networked apparatuses, such as in a distributed processing or cloud-based architecture.

A user or administrator may access the system <NUM> via a remote device (e.g., a Personal Computer ("PC"), tablet, or smartphone) to view information about and/or manage operational information in accordance with any of the embodiments described herein. In some cases, an interactive graphical user interface display may let an operator or administrator define and/or adjust certain parameters (e.g., to define how systems interact) and/or provide or receive automatically generated recommendations or results from the system <NUM>. The proxy platform data store <NUM> may contain electronic data records <NUM> associated with a compute node (e.g., with each record containing a node identifier <NUM>, a node address <NUM>, a Multi-Party Computation ("MPC") algorithm <NUM>, etc.). As used herein, the phrase "multi-party computation) may refer to an area of cryptography having a goal of creating methods for entities to jointly compute a function using inputs while keeping those inputs private.

<FIG> is a method that might performed by some or all of the elements of the system <NUM> described with respect to <FIG>. The flow charts described herein do not imply a fixed order to the steps, and embodiments of the present invention may be practiced in any order that is practicable. Note that any of the methods described herein may be performed by hardware, software, or any combination of these approaches. For example, a computer-readable storage medium may store thereon instructions that when executed by a machine result in performance according to any of the embodiments described herein.

At S310, a proxy platform may detect that that a first node (e.g., a VM or container) needs to access a cloud application secret key (e.g., a key associated with a cloud application password). In some embodiments, the proxy platform executes on the first node. Moreover, the detection may be associated with a Transmission Control Protocol ("TCP") proxy server that communicates via local host. For example, the detection may comprise interception of an encrypted password request.

At S320, the system may determine, based on information in a proxy platform data store, a set of nodes associated with the secret key that the first node needs to access. The proxy platform data store may, for example, contain node data associated with nodes of the cloud computing environment, each node storing multi-party computation information. At S330, the system may use a multi-party computation algorithm and information received from the set of nodes to generate the secret key. According to some embodiments, the multi-party computation information is stored in a secure enclave of each node (e.g., associated with a Trusted Execution Environment ("TEE"), an INTEL® Software Guard Extension ("SGX"), an AMD® Secure Encrypted Virtualization ("SEV") or a similar enclaving technology, etc.).

Consider, for example, <FIG> is a more detailed view of a system <NUM> architecture in accordance with some embodiments. Note that a proxy platform may exist on all virtual machines and store the part credentials of MPC in the enclave of each individual VM (proxy machine <NUM> and proxy platform data store <NUM> on VM1, proxy machine <NUM> and proxy platform data store <NUM> on VM2, and proxy machine <NUM> and proxy platform data store <NUM> on VM3). At (A), VM1 may send a request for a secret password to proxy platform <NUM> including a first "portion" of information that can be used to construct the password. The proxy platform <NUM> stores the first portion and requests additional portions from VM2 and VM3 at (B) and (C) (based on node information stored in proxy platform data store <NUM>). VM2 and VM3 send second and third portions of the secret key back to proxy platform <NUM> at (D) and (E). The proxy platform <NUM> uses the three portions of information and a multi-party computation algorithm to create the secret password which is then provided to VM1 at (F).

The system may then construct a key by a function running securely by obtaining partial data from multiple VMs. Such a mechanism, known as the multi-party computation, may be applied to protect application secrets for the VM or container running the application. Embodiments may address security problems at two levels:.

<FIG> is a control plane <NUM> implementation in accordance with some embodiments. Assume there is a cloud application executing on a first VM <NUM> that needs to access a database server and must use a secret password to access the database. When the application makes a request for getting a password for a service, the provisioner of the application, such as cloud foundry or Kubernetes, generates a partial key (KEY1) for the password and keeps it on the VM <NUM> on which the application is running.

The VM <NUM> on which the container is running may execute a TCP proxy server that proxies the call to the services outside on behalf of the container. The container always accesses the TCP proxy server over localhost (meaning that the container always talks via localhost). The partial password may be stored on VM storage and then be brought into an enclave memory of the proxy during startup. Note that in an enclave, such as SGX or a similar enclaving technology, the memory is not even visible to a root user. Instead, it would only be accessible to the Central Processing Unit ("CPU") during computation.

A cloud orchestrator <NUM> also keeps part of the key on other VMs it is managing (e.g., KEY2 on a second virtual machine <NUM> and KEY3 on a third virtual machine <NUM>). This means that the password is broken into multiple parts mathematically and is distributed across a set of nodes. Each node runs a similar proxy process which has an enclaving around the partial password that node holds. The proxy running on the VM which runs the application also is injected with the IP of the other proxies that hold the partial password for the application (e.g., via a backing service <NUM>).

<FIG> is a data plane <NUM> implementation according to some embodiments. When the application running on the first VM <NUM> tries to access the DB for which it needs the password, it sends out a request to the database with the encrypted password. This request is intercepted by the TCP proxy on the VM <NUM> and since the proxy has the partial password in its enclave, it reaches out to other proxies (residing on other VMs <NUM>, <NUM>) to get the other partial keys. The system may then load all of these partial keys into the enclave alongside the partial password that it already has. The system can then use these partial keys to compute the final password (which can be used to decrypt information as required).

Note that the application generating the request may send a partial key to the proxy server. The proxy server requests a set of other cooperating proxy servers to send their partial passwords. The partial passwords are brought into a secure enclave (and even an administrator on a machine cannot see them). If someone has ability to snoop over the network, he or she will only see a set of different keys arriving.

The password computing function may then pull all of these partial parts from the enclave and compute the actual secret. The final password might be stored in enclave memory for some period and then evicted (removed from memory altogether). In this way, even if a VM is compromised there is no means to derive the password (as its either in the enclave of the VM or its completely distributed).

By distributing the password parts into multiple VMs embodiments may introduce one more security periphery. Consider, for example, an attack Points Of View ("POV"):.

First, consider an attacker who has access to the container memory. If he or she scans through the application process memory (and even if captures the dump of the memory), will not see any password of any sort.

Next, consider an attacker who is more skilled and has access to the VM and can, for example, install tools such as the GNU De-Bugger ("GDB") tool, to inspect the memory of various processes. Because the passwords are enclaved, even dumping the process memory will not show meaningful information to the attacker.

Now consider an attacker who not just gets through VM access but is also able to attack SGX or a similar enclaving mechanism on other hardware platforms such AMD®. In this case, the attacker needs to have complete knowledge of the Internet Protocol ("IP"') used to fetch the partial parts of the password and the algorithm used to compute the password from the keys. This needs greater skill and more time for the attacker to determine. This increased window may give the platform operator sufficient time to react and perhaps kill the VM to thwart the attack.

Since the applications can move across VMs, an orchestrator may do the additional work of loading a proxy with the right partial password and giving the proxy the IP address of the other proxy components that hold the partial keys. This redistribution can be done, for example, when the application is rescheduled (e.g., due to a VM failure or for some other reason). The partial passwords can be held in an object store such as a Simple Storage Service ("S3") or in an elastic file system mounted on the VMs.

Suppose the secret password needed to access a DB is "<NUM>. " A very simplistic representation of the mathematical function is provided herein for clarity but in reality it may be much more complex. In this case, the cloud application may send a "<NUM>" as the key to the proxy server along with data to be encrypted. The proxy server contacts its peers (in this case two additional nodes) to send their partial keys. The second proxy sends "<NUM>" and the third proxy sends "<NUM>. " These values may be individually loaded into a secure enclave, and the function to compute the secret (e.g., the multiplied product of the three values) may invoked. This function pulls the partial data from enclave, computes the secret, and puts it into the enclave: <MAT>.

In this way, no proxy has the complete secret and, even if compromised, will not reveal anything important. The information sent over the network also doesn't reveal anything important. So, combining enclaves with MPC makes the encryption solution much more foolproof.

<FIG> is proxy platform display <NUM> according to some embodiments. The display <NUM> includes a graphical representation <NUM> of the elements of a system in accordance with any of the embodiments described herein. Selection of an element on the display <NUM> (e.g., via a touchscreen or a computer pointer <NUM>) may result in display of a popup window containing more detailed information about that element and/or various options (e.g., to add a data element, modify a mapping, etc.). Selection of an "Edit System" icon <NUM> may let an operator or administrator change a multi-party computation algorithm, alter the number of nodes storing partial keys, etc..

Note that the embodiments described herein may also be implemented using any number of different hardware configurations. For example, <FIG> is a block diagram of an apparatus or platform <NUM> that may be, for example, associated with the systems <NUM>, <NUM>, <NUM>, <NUM> of <FIG>, <FIG> <FIG>, <FIG>, respectively (and/or any other system described herein). The platform <NUM> comprises a processor <NUM>, such as one or more commercially available Central Processing Units ("CPUs") in the form of one-chip microprocessors, coupled to a communication device <NUM> configured to communicate via a communication network (not shown in <FIG>). The communication device <NUM> may be used to communicate, for example, with one or more remote user platforms, administrator platforms, etc. The platform <NUM> further includes an input device <NUM> (e.g., a computer mouse and/or keyboard to input cloud computing information) and/an output device <NUM> (e.g., a computer monitor to render a display, transmit recommendations, and/or create reports about nodes, proxies, secret keys, etc.). According to some embodiments, a mobile device, monitoring physical system, and/or PC may be used to exchange information with the platform <NUM>.

The processor <NUM> also communicates with a storage device <NUM>. The storage device <NUM> may comprise any appropriate information storage device, including combinations of magnetic storage devices (e.g., a hard disk drive), optical storage devices, mobile telephones, and/or semiconductor memory devices. The storage device <NUM> stores a program <NUM> and/or a mapping expression engine <NUM> for controlling the processor <NUM>. The processor <NUM> performs instructions of the programs <NUM>, <NUM>, and thereby operates in accordance with any of the embodiments described herein. For example, the processor <NUM> may detect that a first node needs to access a cloud application secret key and determine, based on information in a proxy platform data store <NUM>, a set of nodes associated with the secret key that the first node needs to access. The processor <NUM> may then use a multi-party computation algorithm and information received from the set of nodes to generate the secret key.

The programs <NUM>, <NUM> may be stored in a compressed, uncompiled and/or encrypted format. The programs <NUM>, <NUM> may furthermore include other program elements, such as an operating system, clipboard application, a database management system, and/or device drivers used by the processor <NUM> to interface with peripheral devices.

As used herein, information may be "received" by or "transmitted" to, for example: (i) the platform <NUM> from another device; or (ii) a software application or module within the platform <NUM> from another software application, module, or any other source.

In some embodiments (such as the one shown in <FIG>), the storage device <NUM> further stores the proxy platform data store <NUM>. An example of a database that may be used in connection with the platform <NUM> will now be described in detail with respect to <FIG>. Note that the database described herein is only one example, and additional and/or different information may be stored therein. Moreover, various databases might be split or combined in accordance with any of the embodiments described herein.

Referring to <FIG>, a table is shown that represents the proxy platform data store <NUM> that may be stored at the platform <NUM> according to some embodiments. The table may include, for example, entries associated with secret keys that may be needed in connection with a cloud computing environment. The table may also define fields <NUM>, <NUM>, <NUM>, <NUM>, <NUM> for each of the entries. The fields <NUM>, <NUM>, <NUM>, <NUM>, <NUM> may, according to some embodiments, specify: a key identifier <NUM>, a first node identifier <NUM>, a second node identifier <NUM>, a multi-party computation algorithm <NUM>, and a status <NUM>. The proxy platform data store <NUM> may be created and updated, for example, when new keys are needed, a multi-party computation algorithm is changed, etc..

The key identifier <NUM> might be a unique alphanumeric label that is associated with a particular secret key (e.g., a password needed to decrypt information in a database application). The first node identifier <NUM> and second node identifier <NUM> may identify which nodes hold partial portion of the information that is needed to construct that secret key. The multi-party computation algorithm <NUM> may define the function that is used to compute the key to combine the partial portions and generate the key. The status <NUM> might indicate that the key has been generated and stored in a secure enclave.

<FIG> is a secure enclave implementation <NUM> according to some embodiments. In particular a node <NUM> may include an untrusted part of an application <NUM> and a trusted part of the application <NUM> (e.g., associated with a TEE). The trusted part of the application <NUM> may, for example, be safe from attacks via privileged system code <NUM> (e.g., an Operating System ("OS"), a Virtual Machine Manager ("VMM"), a Basic Input Output System ("BIOS"), a System Management Mode ("SMM"), etc.). The untrusted part of the application <NUM> may create an enclave and then call a trusted function. When the trusted function is called, the trusted part of the application <NUM> executes as appropriate and returns to the untrusted part of the application <NUM>.

Thus, embodiments may facilitate protection of a cloud computing environment secret key using a multi-party computation algorithm in a secure, automatic, and efficient manner. Since security is a huge topic for cloud deployments (where there is a huge attack vector), embodiments described herein may build multiple layers of security around the application, making the solution more robust and of substantial business and technical value.

The following illustrates various additional embodiments of the invention. These do not constitute a definition of all possible embodiments, and those skilled in the art will understand that the present invention is applicable to many other embodiments. Further, although the following embodiments are briefly described for clarity, those skilled in the art will understand how to make any changes, if necessary, to the above-described apparatus and methods to accommodate these and other embodiments and applications.

Although specific hardware and data configurations have been described herein, note that any number of other configurations may be provided in accordance with some embodiments of the present invention (e.g., some of the information associated with the databases described herein may be combined or stored in external systems). Moreover, although some embodiments are focused on particular types of secret keys, any of the embodiments described herein could be applied to other types of secret keys. Moreover, the displays shown herein are provided only as examples, and any other type of user interface could be implemented. For example, <FIG> illustrates a handheld tablet computer <NUM> showing a proxy platform display <NUM> according to some embodiments. The proxy platform display <NUM> might include user-selectable data that can be selected and/or modified by a user of the handheld computer <NUM> (e.g., via an "Edit System" icon <NUM>) to view updated information about secret keys, cloud applications, multi-party computation algorithms, computing nodes, etc..

Claim 1:
A system (<NUM>) associated with a cloud computing environment, comprising:
a plurality of nodes (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>);
a proxy platform data store (<NUM>, <NUM>, <NUM>) containing node data associated with nodes (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) of the cloud computing environment, each node (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) storing multi-party computation information; and
a proxy platform (<NUM>, <NUM>) able to access the proxy platform data store (<NUM>, <NUM>, <NUM>), including:
a computer processor (<NUM>), and
computer memory (<NUM>), coupled to the computer processor, storing instructions that, when executed by the computer processor cause the processor to:
(i) detect that a first node (<NUM>, <NUM>) of the plurality of nodes (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) needs to access a cloud application secret key,
(ii) determine, based on information in the proxy platform data store (<NUM>, <NUM>, <NUM>), a set of nodes (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) among the plurality of nodes (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) associated with the secret key that the first node (<NUM>, <NUM>) needs to access,
(iii) use a multi-party computation algorithm (<NUM>, <NUM>) and information received from the set of nodes (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) to generate the secret key, and
(iv) store the generated secret key in a secure enclave at the proxy platform for some period and then evict the generated secret key.