阅读说明：本技术 安全执行平台群集 (Secure execution platform cluster ) 是由 D.哈尼克 P.K.塔-什马 Y.温斯伯格 M.赫什科维奇 于 2018-07-05 设计创作，主要内容包括：一种计算机程序产品和系统,包括：与数据存储器连接的安全执行平台(SEP)群集,群集的每个SEP被配置得在处理数据时使用密钥来维护数据的机密性；密钥在群集的SEP之间共享,密钥由群集或其部分自动生成,并且不可用于任何非群集实体；数据存储器保留使用密钥加密的加密数据；群集的第一SEP被配置得使用密钥来加密客户端数据以获取加密的客户端数据并将加密的客户端数据存储在数据存储器中；群集的第二SEP被配置得从数据存储器中检索存储的加密数据,使用密钥来解密存储的加密数据以获取存储的加密数据。(A computer program product and system comprising: a Secure Execution Platform (SEP) cluster coupled to the data store, each SEP of the cluster configured to maintain confidentiality of the data using a key when processing the data; keys are shared among the SEPs of the cluster, the keys are automatically generated by the cluster or parts thereof, and are not available to any non-clustered entities; the data storage retains encrypted data encrypted using the key; the first SEP of the cluster is configured to encrypt the client data using the key to obtain encrypted client data and store the encrypted client data in the data store; the second SEP of the cluster is configured to retrieve the stored encrypted data from the data store, decrypt the stored encrypted data using the key to obtain the stored encrypted data.)

1. A system, comprising:

a cluster of Secure Execution Platforms (SEPs) connected to the data store, wherein each SEP of the cluster is configured to maintain confidentiality of the data using a key when processing the data;

wherein the key is shared between SPEs of the cluster, wherein the key is automatically generated by the cluster or a portion thereof and is not available to any non-clustered entity;

the data store retains encrypted data encrypted using the key;

wherein a first SEP of the cluster is configured to encrypt client data using the key to obtain encrypted client data and store the encrypted client data in the data store; and

wherein a second SEP of the cluster is configured to retrieve stored encrypted data from the data store, decrypt the stored encrypted data using the key to obtain an unencrypted form of the stored encrypted data.

2. The system of claim 1, wherein the second SEP is configured to retrieve the stored encrypted data in response to a query from a client device, wherein a non-encrypted form of the stored encrypted data is used to provide a response to the query, thereby completing the query without the client device accessing the stored data.

3. The system of claim 1, wherein the first SEP and the second SEP are the same SEP.

4. The system of claim 1, wherein a first SEP has write-only access to the data store and a second SEP has read-only access to the data store.

5. The system of claim 1, wherein a third SEP of the cluster is configured to add a new SEP to the cluster, wherein the third SEP is configured to forward the key to the new SEP over a secure communication channel.

6. The system of claim 5, wherein the third SEP is configured to use a attestation mechanism to verify the correctness of the platform and code of the new SEP before forwarding keys over the secure channel.

7. The system of claim 5, wherein the new SEP is configured to use an authentication mechanism to verify the correctness of the third SEP's code and platform before accepting a key from the third SEP.

8. The system of claim 5, wherein the third SEP is configured to observe a bulletin board before forwarding a key over a secure channel to verify whether the new SEP is allowed to receive the key.

9. The system of claim 5, wherein the bulletin board is implemented using a distributed fault tolerance scheme.

10. The system of claim 5, wherein the bulletin board is implemented using a dedicated SEP.

11. The system of claim 5, wherein the third SEP is configured to verify that the observed information in the bulletin board is signed by a plurality of administrators greater than a threshold.

12. The system of claim 4, wherein the new SEP is prohibited from forwarding the key.

13. The system of claim 4, wherein a third SEP is configured to set a predetermined lifetime for the new SEP, wherein the new SEP is configured to be removed from the cluster at the end of the predetermined lifetime.

14. The system of claim 4, wherein a third SEP is configured to add the new SEP to the cluster in response to the number of SEPs in the cluster being below a predetermined threshold.

15. The system of claim 4, wherein a third SEP is configured to add a new SEP to the cluster in response to the first SEP or the second SEP becoming an inoperable SEP, whereby the new SEP is configured to replace the inoperable SEP.

16. The system of claim 4, wherein the third SEP is the same as the first SEP or the second SEP.

17. The system of claim 1, wherein the key is generated by a third SEP of the cluster, wherein the third SEP is configured to distribute the key to other SEPs in the cluster.

18. The system of claim 1, wherein the cluster is configured to agree on the key using a consensus protocol in response to generating the key.

19. The system of claim 1, wherein an administrator of the cluster or the data store does not have the key.

20. A computer program product comprising a non-transitory computer-readable storage medium holding instructions to be executed by a Secure Execution Platform (SEP) within a computerized environment, wherein the computerized environment comprises a cluster of SEPs having connections to a data store, wherein the data store holds encrypted data encrypted using a key, wherein the key is shared between the SEPs of the cluster, wherein the key is automatically generated by the cluster or a part thereof and is not available to any non-clustered entity, wherein the cluster comprises SEPs, wherein each SEP of the cluster is configured to use the key to maintain confidentiality of the data when processing the data, wherein the instructions, when executed by a SEP, cause the SEPs to perform the steps of:

in response to receiving first client data from a first client device over a secure communication channel, encrypting the first client data using the key to obtain encrypted client data and storing the encrypted client data in a data store, whereby the first client data retained in the data store is not obtainable by any non-computerized entity;

in response to receiving an access query from a second client device that requires access to the retained data, retrieving an encrypted form of the retained data from a data store, decrypting the encrypted form using the key to obtain the second client data, and providing a response to the second client device over a secure communication channel, wherein the response is based on the second client data.

Technical Field

The present disclosure relates generally to data security and, more particularly, to secure execution platforms.

Background

Today, confidential or private data, often referred to as sensitive data, is often retained in a centralized data store. The source of such sensitive data may vary. Whether the data is received from a business entity that delegates its business secrets to the data store, private citizens that are legally required to provide biological samples, or any other source, the confidentiality of the stored data must be maintained.

The data store is accessible by the server in response to client queries, allowing for modest and limited use of sensitive data. In some cases, the server ensures that the client has the right to perform such queries, and that its mode of operation is consistent with the role of the client. The server may anonymize the information as it is processed and provide the anonymized data in return.

However, the server still handles sensitive data and has access to the raw data itself. Therefore, it may be important to ensure that there are no potential leak points within the server. In some cases, the administrator of such servers is careful to pick and strictly review before giving access to the server. An administrator has unrestricted access to the data retained in the servers and, therefore, unrestricted access to all sensitive data retained in the centralized data store.

Disclosure of Invention

One exemplary embodiment of the disclosed subject matter is a system comprising: a cluster having Secure Execution Platforms (SEPs) connected to a data store, wherein each SEP of the cluster is configured to maintain confidentiality of data using a key when processing data; wherein the key is shared between SEPs of the cluster, wherein the key is automatically generated by the cluster or a portion thereof and is unavailable to any non-clustered entities; the data store retains encrypted data encrypted using the key; wherein a first SEP of the cluster is configured to encrypt client data using the key to obtain encrypted client data and store the encrypted client data in the data store; wherein the second SEP of the cluster is configured to retrieve the stored encrypted data from the data store, decrypt the stored encrypted data using the key to obtain an unencrypted form of the stored encrypted data.

Another exemplary embodiment of the disclosed subject matter is a computer program product comprising a non-transitory computer-readable storage medium holding instructions to be executed by Secure Execution Platforms (SEPs) in a computerized environment, wherein the computerized environment comprises a cluster of SEPs connected to a data store, wherein the data store holds encrypted data encrypted using a key, wherein the key is shared between the SEPs of the cluster, wherein the key is automatically generated by the cluster or a part thereof and is not available to any non-clustered entity, wherein the cluster comprises SEPs, wherein each SEP of the cluster is configured to use the key to maintain confidentiality of the data when processing the data, wherein the instructions, when executed by the SEPs, cause the SEPs to perform the steps of: in response to receiving first client data from a first client device over a secure communication channel, encrypting the first client data using the key to obtain encrypted client data, and storing the encrypted client data in the data store such that any non-computerized entity cannot retrieve the first client data retained in the data store; in response to receiving an access query from the second client device that requires access to the retained data, retrieving an encrypted form of the retained data from the data store, decrypting the encrypted form using the key to obtain second client data, and providing a response to the second client device over the secure communication channel, wherein the response is based on the second client data.

Drawings

The subject matter of the present disclosure will be understood and appreciated more fully from the following detailed description taken in conjunction with the accompanying drawings, in which corresponding or similar numerals or characters indicate corresponding or similar components. Unless otherwise indicated, the drawings provide exemplary embodiments or aspects of the disclosure, and do not limit the scope of the disclosure. In the drawings:

fig. 1 illustrates a block diagram of a system in accordance with some exemplary embodiments of the disclosed subject matter;

2A-2D illustrate flow charts of methods according to some exemplary embodiments of the disclosed subject matter; and

fig. 3 illustrates a schematic diagram of a system in accordance with some exemplary embodiments of the disclosed subject matter.

Detailed Description

One technical problem addressed by the disclosed subject matter is maintaining confidentiality of data when processing data.

Many applications and programs may involve handling and processing sensitive data. Sensitive data should be protected from unauthorized access or modification by rogue software running at higher privilege levels. It may be desirable to preserve the confidentiality and integrity of sensitive data without destroying legitimate software or the ability of a user to utilize or manage the use of platform resources associated with sensitive data.

In some exemplary embodiments, sensitive data may be retained in a manner that legitimate software or users may access it, have the ability to add new data without affecting the confidentiality of existing data, use existing data for providing different services, and so forth. In some exemplary embodiments, it may be desirable to prevent untrusted applications and users from accessing sensitive data, whether reading or updating sensitive data.

Another technical problem addressed by the disclosed subject matter is reducing the perceived risk of vulnerable, non-computerized entities, such as human administrators or users.

Many applications and services related to sensitive data may rely on a centralized trusted party to manage and run them. In some cases, a trusted party (e.g., an administrator) may misuse or mishandle sensitive data, resulting in a security breach. As an example, a trusted party may be used to process a database of personal healthcare data that remains secure. As another example, an administrator may manage a secure biometric database. As yet another example, the data store may store financial data in situations such as where the system processes a commercial transaction issued by a brokerage firm, processes an auction, and accepts bids, etc. The disclosed subject matter can also be used in information hosting, bioinformatics data platforms, healthcare services platforms, and the like.

In some cases, hackers, rogue employees, etc. may break into privileged accounts, access sensitive data, copy or leak sensitive data, etc., thereby compromising the security of sensitive data, such as snoton leaks.

Yet another technical problem addressed by the disclosed subject matter is to provide a computerized platform that, once run, completely hides data from human users and is not subject to any human authority constraints.

Keeping data hidden from unprotected computerized entities or users is one of the most difficult problems in actual security enforcement. Typically, the execution platform is managed by a human user. Even if the execution platform encrypts the processed data using an encryption key, such key is known or obtainable by a human user, such as is the case when a server crashes, needs to be replaced by a new server, and requires the input of a key in order to decrypt sensitive data. An attacker who obtains the key can recover the original data from the encrypted data and use or spread the data maliciously. An attacker may obtain the key from a human entity that knows the key, for example by stealing, by buying, by human error, social engineering, etc. Additionally or alternatively, an attacker may obtain the key by introducing a malware agent to be executed on the execution platform. The malware agent may be provided with the administrator's permissions, for example, by using social engineering, and as a result, the malware agent may learn all the information accessible to the platform administrator.

One technical solution is to automatically generate keys by a cluster of Secure Execution Platforms (SEPs). The confidentiality of the data may be maintained with the key when processing the data. The key may only be available to the SEP of the cluster. Other computerized entities that are not members of the cluster, such as servers, SEPs, computerized devices, etc., may not have access to the key and may not be able to obtain the key. Further, agents executed by the SEP, such as those implemented in software, firmware, hardware, combinations thereof, may be restricted from accessing the keys if not considered "authorized". In some cases, the SEP may execute both authorized and unauthorized agents and allow only authorized agents following the protocol of the disclosed subject matter to access the keys. In some exemplary embodiments, only an authorized agent executed by the SEP may obtain the key, decrypt the sensitive data using the key, encrypt the sensitive data using the key, and process the decrypted data. Additionally or alternatively, only authorized agents may forward keys to other agents or SEPs.

In some example embodiments, the SEP cluster may be connected to a data store configured to retain sensitive data. The data store may retain an encrypted form of the data encrypted using the key. The data stored in the data store may be accessed by authorized agents executing by the SEPs of the cluster, which may decrypt the encryption. The data may be reconstructed using the key and based on the encrypted form of the data.

In some exemplary embodiments, the authorization agent of the SEP may also be configured to decrypt data using the key and prevent any access to the decrypted data, even if such data is used for computing. The SEP may retain the decrypted data in a secure container that is not accessible to all privileged software (e.g., kernel, virtual machine hypervisor, etc.) executed by the SEP except for the authorized agent itself, which performs the processing, and as a result, only the authorized agent can access the decrypted form of the sensitive data.

In some example embodiments, a key may be shared between SEPs of a cluster. Each SEP of the cluster may be configured to use a key to maintain the confidentiality of the data when processing the data.

In some example embodiments, the SEPs of a cluster may be configured to encrypt data using a key to obtain encrypted data. The SEP of the cluster may then store the encrypted data in a data store. The SEP of the cluster may be further configured, such as by executing an authorized agent, to retrieve the encrypted data from the data store and decrypt the stored encrypted data using the key to obtain an unencrypted form of the stored encrypted data. In some cases, the SEP may be configured to service client queries from client devices and access a data store to implement such queries.

In some example embodiments, the key may be autonomously generated by one SEP, by a combination of SEPs, and the like. The clusters may agree to the key using a consensus protocol (e.g., PAXOS, Chandra-Toueg consensus algorithm, raft (raft), etc.). In some exemplary embodiments, a consensus protocol may be used to select a leader (leader) that generates the key itself. Additionally or alternatively, several SEPs may generate random values that are combined to create a key. Keys used by the cluster may never be displayed or otherwise exported to human users and may be restricted from being distributed to any other computerized device that does not belong to the cluster, or to any unauthorized agent, even if the agent is executed by the SEP of the cluster. In this way, no human user or other unauthorized entity can know the key, and such entity (if compromised) does not compromise the security of the sensitive data.

In some exemplary embodiments, the cluster may be configured to dynamically create a copy and add a new SEP to the cluster. In some cases, if the number of SEPs in the cluster is below a predetermined threshold, new SEPs are added to the cluster and authorized agents are launched in each new SEP. A new SEP may receive a key from an SEP already present in the cluster. In some exemplary embodiments, the cluster may be kept to a minimum size to avoid potential loss of keys and the consequent loss of sensitive data.

In some exemplary embodiments, different tasks and privileges may be provided for the SEPs of a cluster. In some exemplary embodiments, some SEPs may be capable of writing data to the data store, and some SEPs may be capable of reading data from the data store. Additionally or alternatively, some SEPs may be able to add new SEPs to the cluster. In some exemplary embodiments, the created new SEP may be assigned a specific task (e.g., write, read, etc.). The new SEP may be given a predetermined lifetime, such as a day, an hour, etc. At the end of the predetermined lifetime, the new SEP may automatically exit the cluster. In some example embodiments, the new SEP may be prohibited from distributing keys to other devices, including other SEPs, thereby mitigating the potential risk of adding new SEPs to the cluster.

One technical effect of utilizing the disclosed subject matter is to prevent data leakage due to insider attacks, rogue employees, hacking of privileged user's devices, social engineering of administrators, and the like.

In some example embodiments, the cluster acts as the only active gateway for sensitive data, thereby limiting potential data leakage from the centralized data store.

In some exemplary embodiments, the disclosed subject matter provides an autonomous computerized entity that can operate without human intervention and that can maintain keys from a human-controlled system (including from a user having access to the hardware itself) and thus have root privileges to the operating system being executed.

Another technical effect may be to effectively prevent sensitive data from being lost. Using a cluster of SEPs may reduce the likelihood that all SEPs cannot run at the same time compared to a single SEP, and therefore may reduce the likelihood that keys known only to them are lost. If the key is lost, the encrypted data may become useless.

Another technical effect may be to provide autonomous data management-transferring responsibility for data from an administrator to the security hardware. Autonomous data management is not likely to be affected or examined by any external party. A key feature of autonomous data management is that it only performs the operations it is programmed to perform.

The disclosed subject matter may provide one or more technological improvements over any prior art, as well as any technology that has been instantiated or otherwise normalized in the art.

Other technical problems, solutions, and effects may be apparent to one of ordinary skill in the art in view of this disclosure.

Referring now to fig. 1, shown is a diagram of a system in accordance with some exemplary embodiments of the disclosed subject matter.

In some exemplary embodiments, system 100 may include a cluster 120 of SEPs 122, 124, 126, and 128. The cluster 120 may include any number of SEPs, and fig. 1 is merely exemplary. Each SEP may be based on a trusted hardware execution platform, such as Intel^TMSoftware Guard Extensions of^TM(SGX^TM) Server with trusted execution technology (TXT), computerized device with Trusted Platform Module (TPM), IBM^TMSecure Blue + of^TM，AMD^TMSecure entity Encryption of^TM(SME^TM) And the like.

As an example, SGX^TMMay be for Intel^TMA set of hardware/software extensions to the architecture intended to provide integrity and confidentiality guarantees for security sensitive computations performed on computers where all privileged software (e.g., kernels, hypervisors) may be malicious. The trusted hardware may establish a secure container and the remote computing service user may upload the required computations and data into the secure container. Trusted hardware may protect the confidentiality and integrity of data when computing it. SGX^TMThe product also provides proof to a user that communicates with specific software running in a secure container hosted by trusted hardware.

In some exemplary embodiments, the SEP may be a built-in secure execution platform configured to provide secure software computation and execution and to defend against software-based attacks directed to accessing sensitive data by subverting the system, basic input/output system (BIOS) code, modifying the configuration of the platform, and the like.

Each SEP of the cluster 120 may retain a key 130. The key 130 may be shared between SEPs of the cluster 120. The key 130 may be unavailable to any non-clustered entity. It will be noted that the SEPs of the cluster 120 may execute authorized and unauthorized agents. Only authorized agents executed by the SEPs of the cluster 120 may be considered cluster entities.

In some demonstrative embodiments, key 130 may be automatically generated by cluster 120, or a portion thereof. The key 130 may be forwarded to all SEPs of the cluster 120. Each SEP of the cluster 120 may be configured with a key 130 to maintain the confidentiality of the data when processing the data. The key 130 may be used by the SEP to determine the functional output of a cryptographic algorithm that encrypts the data or a representation thereof. As an example, the key 130 may specify a conversion of a plain text representation of the data to its ciphertext representation, and vice versa for a decryption algorithm. The key 130 may specify transformations in other cryptographic algorithms, such as a digital signature scheme, a message authentication code, and so on.

In some example embodiments, the key 130 may be generated as a symmetric key for encryption and decryption of data. Additionally or alternatively, the key 130 may be an asymmetric key, comprising a pair of keys, one for encryption and the other for decryption.

In some demonstrative embodiments, key 130 may be generated by a particular SEP (e.g., SEP 126) of cluster 120. SEP126 may be configured to distribute key 130 to other SEPs 122, 126, and 128. SEP126 may utilize a cryptographic system to generate key 130.

In some example embodiments, the cluster 120 may be configured to agree to the key 130 using a consensus protocol in response to generating the key 130. In some exemplary embodiments, SEP126 may act as a leader for cluster 120. The leader may be selected in advance, the leader may be determined based on a predetermined order between SEPs, the leader may be dynamically selected by cluster 120, and so on. The leader may be configured to generate the key 130 and use the key it generates. Additionally or alternatively, there may be competition between different SEPs, each of which is capable of generating the key 130. The cluster 120 may then select which of the generated keys to use as the key 130 for the cluster 120, such as using a consensus protocol. Additionally or alternatively, several SEPs may generate the key 130 together, such as by each determining a different portion of the key 130. As an example, each SEP may generate 256 bits, while the key 130 may consist of four sets of 256 bits.

In some example embodiments, the system 100 may include a data store 110. The data storage 110 may include a computer readable memory capable of retaining data. In some example embodiments, the data store 110 may be a Redundant Array of Independent Disks (RAID), Network Attached Storage (NAS), Storage Area Network (SAN), NoSQL or SQL database, object store, or the like. The data store 110 may be configured to retain encrypted data encrypted using the key 130. In some exemplary embodiments, encryption is performed by the SEP of the cluster 120, rather than by the data store 110.

For example, the data store 110 may maintain a biometric database of digital representations of fingerprints of citizens of a country. The data in the data store 110 may be used to create a biometric verifiable identification card and passport in performing government research, identifying individuals, identifying potential suspects of criminal activities, and the like.

In some example embodiments, an administrator of the data store 110 may manage the data store 110. An administrator may access the data store 110 without restriction. Additionally or alternatively, an administrator may create, retrieve, and update records in the data store 110. However, without the key 130, an administrator may not have access to the decrypted form of the sensitive data. For example, the biometric database may be administered by an administrator that is an employee of the national biometric database management authority. The administrator may manage the biometric database, update records, create new records, delete records, etc. without the key 130. For example, an administrator may have unrestricted access to consultants for issuing Structured Query Language (SQL) commands to a database. However, since the administrator does not have the key 130, the administrator cannot decrypt the encrypted data stored in the data storage 110. In some example embodiments, an administrator may not be able to introduce new encrypted data into data store 110 that is decryptable using key 130 without accessing key 130.

Each SEP in the cluster 120 may be connected to the data store 110. Some SEPs may be configured to write data to the data store 110, read data from the data store 110, and the like. In some exemplary embodiments, only SEPs included in cluster 120 are allowed to read from and write to data store 110, and data store 110 may be configured to deny any attempted access that is not performed by a member of cluster 120.

In some exemplary embodiments, an authorization agent executed by SEP 122 may be configured to encrypt client data with key 130 to obtain encrypted client data. The authorization agent executed by SEP 122 may store the encrypted client data in data store 110. Client data retained in data store 110 is not available to any non-clustered entities. The SEP 122, which has only write access to the data store 110, may be referred to as a writer (writer) SEP.

In some exemplary embodiments, an authorization agent executed by SEP 122 may be configured to encrypt client data in response to receiving the client data from client device 140. The client device 140 cannot directly obtain the encrypted client data. Additionally or alternatively, the client device 140 may provide only a portion of the sensitive data retained in the data store 110. Thus, potential information leakage from the client device 140 is a limited risk, not constituting a risk that the entire database is accessed by an unauthorized entity.

In some exemplary embodiments, an authorization agent executed by the SEP 124 may be configured to retrieve stored encrypted data from the data store 110. The authorization agent executed by the SEP 124 may be configured to decrypt the stored encrypted data using the key 130 to obtain an unencrypted form of the stored encrypted data. The SEP 124, which has only read access to the data memory 110, may be referred to as a reader SEP.

In some example embodiments, an authorization agent executed by the SEP 124 may be configured to retrieve and decrypt stored encrypted data in response to receiving an access query from the client device 140. The client device 140 may require data retained in the data store 110. Since the client device 140 does not have direct access to the data store 110, the client device 140 may need to access a specified portion of the encrypted data stored in the data store 110 by sending a query to the cluster 120 or directly to one of the SEPs (e.g., SEP 124) of the cluster 120. In the event that the client device 140 does not have access to the data store 110, the authorization agent executed by the SEP 124 may retrieve an encrypted form of the associated retained data from the data store 110, decrypt the encrypted form using the key 130, and provide the unencrypted data to the client device. It will be appreciated that even assuming that the client device has access to the data store 110, the client device may not be able to decrypt the stored data because the client device is not in possession of the key 130.

In some example embodiments, the same SEP, e.g., SPE 122, may be used to perform encryption and decryption of data. Additionally or alternatively, some SEPs (e.g., SEP 122) may have write-only access to data store 110, while other SEPs (e.g., SEP 124) may have read-only access to data store 110.

In some example embodiments, the client device 140 may be a non-SEP device, such as a personal computer, laptop computer, mobile device, or the like. A human user may access the data store 110 using the client device 140, such as using a query, using a dedicated user interface, and so forth. In some example embodiments, the client device 140 may be a server that provides a web-based user interface to generate queries based on user input, and is configured to issue queries to the cluster 120.

It is to be appreciated that the client device 140 may or may not be directly connected to the SEP 122 or another SEP. In some demonstrative embodiments, client device 140 may issue a query received by a gateway device (not shown) of cluster 120. In response, the gateway device may select the SEP of the cluster 120 to process the query, e.g., based on load balancing considerations, access rights of the SEP, query type, etc. In some cases, some SEPs may be pre-designated for processing a particular type of query, and the cluster 120 may be configured to route the query to the appropriate SEP.

Referring to the example of the biometric database, an employee of the executive will be authorized to collect biometric data from citizens and transmit the data to the biometric database (e.g., 110). Employees of the executive may use a device, such as the client device 140, to issue updates or insert queries to add data to the biometric database. The query may be received by SEP 122, and SEP 122 may encrypt the data using key 130 and store the encrypted data in the biometric database. Once the data is encrypted, employees may not be able to extract the data from the biometric database because they never know the key 130.

On the other hand, the data stored in the biometric database can be used for issuing a resident identification document, for verifying the identity of an individual, and the like. Authorized members, such as police officers, employees of security agencies, etc., may need to re-check the biometric data of an individual. To do so, they may use the client device 140 and, based on their rights, they may send an access query to the SEPs (e.g., 124) of the cluster 120. The SEP may have a key 130 and accordingly may retrieve the biometric data of the associated encrypted individual, decrypt the biometric data of the encrypted individual, process the biometric data, and provide the processed results to the authorized member via the client device 140 without the authorized member needing to know the key 130 or having direct access to the biometric database. In some exemplary embodiments, a user may be restricted from performing a particular type of query, receiving data of different granularity, and the like, based on the user's privileges. For example, some officials may only be able to insert new data, while other officials may be authorized to retrieve personalized data about a particular person. Still other officials may have access to a verification process that verifies the correctness of the biometric information but does not authenticate the officials to the biometric information itself, for example by taking a biometric reading, transmitting it to the SEP, which then verifies the information based on the stored biometric data. Still other officials may be authorized to issue a limited number of queries.

In some example embodiments, the SEPs of the cluster 120 are not allowed to forward the key 130 to any non-clustered entities, such as other SEPs not belonging to the cluster 120, or to any other devices. SEPs may be programmed to not display the key 130 in their user interface or otherwise provide the key 130 to a human user. Users of the SEP of the cluster 120 and other unauthorized agents executing thereby may not be able to obtain the key 130 even though they may access the SEP.

In some exemplary embodiments, the SEP 128 may be configured to add a new SEP, such as new SEP129, to the cluster 120. An enhanced cluster 120b may be defined. The SEP 128 may be configured to forward the key 130 to the new SEP129 over a secure communication channel when forming the enhanced cluster 120b as part of the process of adding the new SEP129 to the cluster 120. SEP 128 may be referred to as a planter SEP.

In some exemplary embodiments, any SEP that forwards the key 130 to another entity (e.g., the grower SEP) may use the proof to verify that the new SEP is indeed the SEP executing the authorizing agent before forwarding the key. The new SEP may use the proof to verify that the planter SEP is indeed the SEP executing the authorized agent before accepting the sent key.

In some exemplary embodiments, the new SEP129 may be prohibited from forwarding the key 130 to any computerized device. In some exemplary embodiments, the new SEP129 may not be a grower SEP itself, and thus, will not be able to continue to increase the size of the enhanced cluster 120 b.

In some exemplary embodiments, the SEP 128 may be configured to set a predetermined lifetime, such as a few minutes, an hour, a day, etc., for the new SEP 129. New SEP129 may be configured to be removed from cluster 120b at the end of a predetermined lifetime. The new SEP may be configured to automatically exit the cluster, be removed from the enhanced cluster 120 by another device, such as the SEP 128 or another management device (not shown) of the cluster 120, etc. In some exemplary embodiments, the new SEP129 may be configured to delete or clear the copy of the key 130 it retains upon exiting the enhanced cluster 120 b.

In some exemplary embodiments, the SEPs 128 may be configured to add a new SEP129 to the cluster 120 in response to the number of SEPs in the cluster 120 being below a predefined threshold, e.g., 2, 3, 10, etc. In some exemplary embodiments, it may be desirable to maintain a minimum number of SEPs, for example, to reduce the likelihood of losing all copies of the key 130. When the number of SEPs reaches a minimum threshold, the grower SEP may be configured to begin generating new SEPs that are added to the cluster 120 to ensure that a sufficient number of copies of the key 130 co-exist.

Additionally or alternatively, SEP 128 may be configured to add a new SEP129 to cluster 120 in response to SEP 122 or SEP 124 becoming inoperative. The new SEP129 may be configured to replace the inoperable SEP. In some exemplary embodiments, the lifetime of the new SEP129 may be limited to a predetermined lifetime estimated to be sufficient until the inoperable SEP is again operational.

It is understood that in some cases other SEPs (e.g., SEP 122, SEP 124, or SEP 126) may add a new SEP to cluster 120 or cluster 120 b. By default, new SEPs (e.g., new SEP 129) may be prohibited from being added to the enhanced cluster 120 b. However, in some cases, the administrator of the cluster 120 may allow new members to be added to the new SEP129, for example, if the new SEP129 becomes part of the backbone of the enhanced cluster 120b, if the grower SEP becomes inoperable, and so on. In some exemplary embodiments, the administrator may allow the lifetime of the SEP to be extended beyond the original predetermined lifetime.

Referring now to fig. 2A, a flow diagram of a method according to some exemplary embodiments of the present subject matter is shown.

At step 210, client data may be received. In some exemplary embodiments, the client data may be received by a SEP (such as 122 in FIG. 1) in the computerized environment. The SEP may be a member of a SEP cluster, such as 120 in fig. 1, having a connection to a data store (e.g., 110 in fig. 1). The data store may retain encrypted data encrypted using the key. The key may be shared between the SEPs of the cluster. Each SEP of the cluster may be configured to maintain confidentiality of data using a key when processing data.

In some exemplary embodiments, the customer data may include sensitive data, such as patient profiles, medical information, national security data, secure payment method data, financial records, confidential data, and the like. Sensitive data may need to be stored confidentially in a secure data store for future use.

In some example embodiments, the client data may be received from a client device (such as 140 in fig. 1). The client device may be a non-SEP device, such as a server, computerized device, or the like. The client device may or may not be operated by a human user. The client device may enable a user to define a query to be issued. The query may be a write query that introduces new data or updates an existing record in the data store. Queries may be defined using native programs executed by the client device, programs that display a Graphical User Interface (GUI) and forward the query to the client device when executed by the user device, web-based interfaces executed by the client device and accessible to the user using the user device, such as a computer executing a web browser, and so forth. The client device may not have access to the key or retain the key. In some example embodiments, the client device may not have direct access to the data store.

In some exemplary embodiments, the client device may provide the client data directly to the SEP. Additionally or alternatively, the client device may contact a gateway of the cluster, which may direct communications from the client device to the target SEP for processing.

At step 215, the client data may be encrypted using the key to obtain encrypted client data. The client data may be encoded in such a way that only SEPs with the key can decrypt it. In some exemplary embodiments, step 215 may be performed by an authorization agent executed by the SEP.

In some example embodiments, the client data may be encrypted using an encryption algorithm. The key may be part of an encryption algorithm, a parameter of an encryption algorithm, etc. The SEP may be able to decrypt the encrypted client data using the key

At step 220, the encrypted client data may be stored in a data store.

Referring now to fig. 2B, a flow diagram of a method according to some exemplary embodiments of the present subject matter is shown.

At step 230, the client query may be received by an SPE (such as 124 of FIG. 1). The SEP may be a member of a cluster of SEPs (such as 120 in fig. 1) that have connections to data storage. The data store may retain encrypted data encrypted using the key, such as encrypted client data stored in step 220.

In some example embodiments, the query may define a portion of the stored data to be obtained by a client device (such as 140 of FIG. 1). Additionally or alternatively, the query may define a portion of the stored data that is first retrieved by the SEP for processing and then provided to the client device based on the processing results thereof.

At step 235, the data store may be accessed by the SEP. In some exemplary embodiments, the data store may be accessible only by the SEPs of the cluster. The SEP may retrieve encrypted data associated with completing the query.

At step 240, the SEP may decrypt the encrypted data retrieved from the data store using the key. The encrypted data may be pre-encrypted by the SEP or a different SEP in the cluster using a key. The unencrypted form of the encrypted data may be obtained by decryption. In some exemplary embodiments, step 240 may be performed by an authorization agent executed by the SEP.

At step 245, the query may be completed. The SEP may complete the query and provide the relevant information to the client device using an unencrypted form of the encrypted data. In some exemplary embodiments, the query may require that processing of the sensitive data be performed on the SEP, e.g., by an authorization agent, without disclosing the sensitive data itself to the client device. Once processing is complete, the query may be completed by returning processing results (e.g., pass/fail results). Additionally or alternatively, the query may require that a portion of the sensitive data be provided, such as preserving the contents of certain fields of a record of the sensitive data. In this case, the client device may eventually be provided with a portion of the sensitive data retained in the data store. The query may be completed without the client device having direct access to the data store or having to independently decrypt encrypted data stored therein.

Reference is now made to fig. 2C, which illustrates a flowchart of a method according to some exemplary embodiments of the present subject matter.

At step 250, a key may be automatically generated. In some exemplary embodiments, the key may be generated by one SEP cluster.

In some example embodiments, the key may be generated by one or more SEPs of the cluster. As an example, multiple SEPs may collectively generate a key by each generating different parts of the key, e.g., the key may be created by concatenating different parts, which may be combined together. As another example, a single SEP may generate a key.

At step 255, the cluster may use a consensus protocol to agree on a key. The consensus protocol may enable various SEPs to agree on a common key. In some exemplary embodiments, the SEPs may each generate candidate values for the key (e.g., at step 250), communicate with each other, and agree on a single agreed-upon value for the key. Additionally or alternatively, a consensus protocol may be used for a single candidate key generated at step 250 and iteratively repeated in each iteration to generate a new candidate key until a consistency value is reached.

In some exemplary embodiments, a consensus protocol may be applied to agree on a leader SEP that indicates the key of the cluster. Additionally or alternatively, the consensus agreement may be agreed upon for the key based on a majority or other quorum of the SEPs.

In some exemplary embodiments, the consensus protocol may be run by one or more administrators that are not SEPs and provided to the SEPs at setup time.

In some example embodiments, based on consensus voting, the cluster may agree on a key to be used by the cluster. In some exemplary embodiments, the decision may be non-revocable. Additionally or alternatively, the cluster may decide to change keys periodically by agreeing on the second key. The sensitive data may be decrypted using the key, encrypted using the second key, and stored.

At step 260, the key may be distributed to all members of the cluster. In some exemplary embodiments, the key may be distributed by the leader SEP to the members, or as part of an application consensus protocol. The leader SEP may be configured to forward the key to each SEP in the cluster that has not retained the key. In some exemplary embodiments, no distribution is required, as the SEP is already informed of the key during the consensus protocol.

At step 265, the key may be used to maintain the confidentiality of the data. The SEPs of the cluster may use keys to maintain the confidentiality of the data when processing the data. The key may not be available to any non-clustered entity and may prohibit the SEP from distributing it to any non-SEP devices and SEP devices that are not new members of the cluster.

In some exemplary embodiments, the data may be stored in the data store after being encrypted with a key and decrypted with the key before using the encrypted data.

Reference is now made to fig. 2D, which illustrates a flow diagram of a method in accordance with some exemplary embodiments of the present subject matter.

At step 270, it may be determined that the number of members of the cluster is below a predetermined threshold. The predetermined threshold may be, for example, about 2, about 3, about 10, etc. In some exemplary embodiments, the predetermined threshold may be related to a target size of the cluster, such as about 40% of a desired optimal size. In some exemplary embodiments, the predetermined threshold may be a combination of a minimum absolute size and a minimum relative size.

In some exemplary embodiments, the threshold may be related to the potential risk of a disaster that may cause all SEPs of the cluster to fail and possibly lose keys. In some exemplary embodiments, the threshold may provide a desired SEP redundancy. Additionally or alternatively, the threshold may require that the SEPs are distributed in different geographical locations, for example at least in three different sites. Furthermore, the threshold may be related to a risk factor that may reduce the risk of all SEP failures simultaneously.

Additionally or alternatively, the determination may be a determination that the SEPs of the cluster become inoperable. Therefore, new SEPs may need to be added to replace inoperable SEPs in the cluster.

At step 275, a new member may be added to the cluster. The new member may be an SEP. In some exemplary embodiments, the new SEP may be the same type of SEP as an SEP already present in the cluster.

In some exemplary embodiments, new members may be added to the cluster by the grower SEP. The planter SEP can be a cluster member configured to add new members to the cluster. The planter SEP can be configured to add a new member in response to the determination of step 270. The planter SEP may send a piece of software to be loaded onto the new SEP for use by the new SEP when it becomes part of the cluster. It will be appreciated that in addition to the task of adding new members, the planter SEP may also be configured to process data while performing write, read or a combination of read and write operations on the data store.

Additionally or alternatively, new members may be added by any original member of the cluster. The original member of the cluster may be the SEP added to the cluster when the cluster was originally generated. The original member may have the right to add a new member to the cluster, forward the key to a new SEP, etc. Non-original SEPs, such as new members, may or may not be allowed to add new members.

In some exemplary embodiments, the new member may be a temporary member. The planter SEP can be configured to set the predetermined life of the new member. The new member may be configured to be removed from the cluster at the end of the predetermined lifetime. The predetermined lifetime may be set to ten minutes, one hour, ten hours, one day, etc. The predetermined lifetime may be set based on the reason for adding a new member, e.g., in case a new member is added to perform a specific task (e.g., adding new data during a workload surge), the predetermined lifetime may be set to be sufficient for the new SEP to add new data. As another example, where a new SEP is added to replace an inoperable SEP, the predetermined lifetime may be based on an expected recovery time for the inoperable SEP.

The key may be forwarded to the new member at step 280. The new member may be configured to use the key to maintain the confidentiality of the data when processing the data. It is possible to prohibit new members from exporting keys to any non-clustered entities or from forwarding keys to any devices not belonging to the cluster.

In some exemplary embodiments, members may be added by an administrator of the cluster. The planter SEP can be configured to provide the key to the new member.

In some example embodiments, the planter SEP may be configured to verify that the new member is an authorized SEP that is allowed to be added to the cluster before forwarding the key. The planter SEP can check if the new member is running an authorized agent. Additionally or alternatively, the new member may be configured to verify (e.g., based on the certificate) that the planter SEP is the SEP running the authorized agent before accepting the key.

In some exemplary embodiments, the new member may be configured to use the key to, for example, write or read to or from a data store connected to the cluster, based on permissions provided by the planter SEP, the cluster administrator, or any other SEP that adds the new member. The new member may be configured to encrypt the client data using the key to obtain encrypted client data and store the encrypted client data in the data store. Additionally or alternatively, the new member may be configured to retrieve the stored encrypted data from the data store, decrypt the stored encrypted data using the key to obtain an unencrypted form of the stored encrypted data. It is noted that the new member may be restricted to performing certain activities, such as having write-only or read-only access to the data store, etc.

At step 285, it may be determined that the predetermined lifetime of the new member has been reached. In some exemplary embodiments, this determination may be performed by the planter SEP. Additionally or alternatively, the determination may be performed by the new member.

At step 290, new members may be removed from the cluster. In some exemplary embodiments, in response to the new member determining that the predetermined lifetime has been reached at step 285, the new member may clear the key and exit the cluster. In some exemplary embodiments, instead of relying on a new member to clear a key, a substitute key may be determined and used as shown in FIG. 2C.