Distributed anonymous compatible encryption management system

Abstract

A data security protection method implemented as an application program on a device includes generating a request for one or more secret shares needed to reconstruct a key. The device stores a first secret share in its memory. The method also includes signing the request with a certificate that identifies the request as valid without identifying the device, and sending the request signed with the certificate to at least one other device. The method further includes receiving the one or more secret shares from the at least one other device, determining whether the one or more secret shares received from the at least one other device are sufficient to reconstruct the key, and upon determining that the one or more secret shares are sufficient to reconstruct the key, reconstructing the key using the first secret share and the one or more secret shares.

Description

[0001] Cross-references to related applications

[0002] This application claims the benefit of U.S. non-provisional application No. 16 / 900,391, filed June 12, 2020, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure relates to an encryption management system and an associated method for protecting data using a shared, reconstructed cryptographic key that can be saved from a separate key manager. Background Technology

[0004] Data owners may wish to store sensitive data in remote locations, such as cloud storage or digital enterprise vaults. This data may be extremely sensitive and should only be accessible to authorized entities, even if the data owner disappears. Examples of such data include data collected through IoT devices.

[0005] To facilitate data access, typical cryptographic systems generate digital keys that the data owner can use to decrypt the data. These systems also generate secret shares that can be used to reconstruct the digital keys and distribute these secret shares among several key managers. Therefore, even if the digital keys are lost, data can be accessed by reconstructing the digital keys if a sufficient number of secret shares have been reassembled. The reconstructed secret shares may be smaller than all the unprocessed secret shares. Since each secret share is held by a different key manager, a sufficient number of key managers must agree on the conditions for authorizing the reconstruction of the keys in order to compile a sufficient number of secret shares.

[0006] However, in typical cryptographic systems that rely on secret sharing, key managers know each other's identities. Therefore, these systems are vulnerable to unauthorized digital key reconstruction attacks, which occur when several key managers collude to reconstruct keys from their secret share. Thus, a cryptographic management system is needed to address these and other shortcomings of current systems. Summary of the Invention

[0007] This disclosure describes an encryption management system that addresses problems in conventional encryption management systems. Specifically, this disclosure describes an encryption management system having the following features.

[0008] In an example aspect of the disclosure, a data security protection method implemented as an application on a device includes generating a request for one or more secret shares needed to reconstruct a key, the device storing a first secret share in its memory; signing the request with a certificate that identifies the request as valid without identifying the device; and sending the request signed with the certificate to at least one other device. The method also includes receiving the one or more secret shares from the at least one other device; determining whether the one or more secret shares received from the at least one other device are sufficient to reconstruct the key; and upon determining that the one or more secret shares are sufficient to reconstruct the key, reconstructing the key using the first secret share and the one or more secret shares.

[0009] Because the certificate in the request sent by the device does not identify the device, the device remains anonymous to the other device that receives the request. Thus, the devices holding the secret shares and all parties thereof do not know each other's identity, making it more difficult to collude to illegally reconstruct the key and access the data. Maintaining the identity of the devices, and thus of all parties thereof, the secret also protects the secret share holders from attempts to steal their secret shares or force them to provide their secret shares or reconstruct the key.

[0010] In an example aspect of the disclosure, the method also includes retrieving encrypted data from a data storage device using the key.

[0011] In an example aspect of the disclosure, the retrieving of the data includes decrypting the data with the key.

[0012] In an example aspect of the disclosure, the device sends the request to the at least one other device by uploading the request to a distributed ledger.

[0013] In an example aspect of the disclosure, the device anonymously uploads the request to the distributed ledger. For example, the device uses Tor to upload the request to the distributed ledger to remain anonymous. As discussed above, this protects the secret share holders from attempts to force them to provide their secret shares, reconstruct the key, or access the encrypted data.

[0014] In an example aspect of the disclosure, the distributed ledger is a blockchain. Each entry in a blockchain includes a hash value based on the previous entry, which makes the blockchain resistant to modification of the data written therein.

[0015] In an example aspect of the disclosure, the device receives the one or more secret shares by downloading the one or more secret shares from the distributed ledger.

[0016] In example aspects of the disclosure, the method further includes receiving a first secret share from a server that manages the secret shares and the key; and receiving a certificate from a server that manages certificates for devices that hold secret shares.

[0017] In example aspects of the disclosure, the one or more secret shares received by the device include one or more signatures based on one or more certificates of one or more devices from which the one or more secret shares were received.

[0018] In example aspects of the disclosure, the method further includes verifying the received one or more secret shares based on one or more signatures included in the secret shares. As mentioned above, the certificate of a device does not identify the device itself. Thus, based on the signature of the device, the device is not identified, thus allowing the device to remain anonymous. The verification is based on, for example, a pseudonym included in the certificate, the issuer of the certificate, and the like. This is advantageous for protecting the device and its parties from possible coercion attempts, and also reduces the likelihood that two or more secret share holders will attempt to collude to reconstruct the key and access the encrypted data without authorization.

[0019] In example aspects of the disclosure, as part of the verification, the method further includes querying a server that manages device certificates to determine whether the one or more signatures included in the one or more secret shares are valid.

[0020] In example aspects of the disclosure, as part of the verification, the method further includes determining the validity of one or more secret shares based on a list obtained from a distributed ledger and one or more signatures included in the one or more secret shares.

[0021] In example aspects of the disclosure, the method further includes receiving a request from another device, verifying the request based on an internal policy of the device, and sending a first secret share to the other device when the request is determined to be valid.

[0022] In example aspects of the disclosure, the method further includes verifying the request using zone information; and determining that the request is invalid in the event that the zone information indicates that the other device is not located in a zone in which data encrypted by the key is accessible. For example, if a particular device is located in a country that requires compliance with the General Data Protection Regulation (GDPR), a request from a country and / or organization that does not comply with the GDPR can be rejected by the particular device.

[0023] In example aspects of the present disclosure, the list is a certificate revocation list, and the device determines that the request is invalid if a certificate used to sign the request is indicated as invalid in the certificate revocation list. A revocation list advantageously allows an issuer of a certificate to revoke a certificate of a malicious secret share holder who attempts to recover a key or launch an attack (e.g., a denial of service attack) on a system without authorization. Once the issuer identifies a malicious secret share holder, the corresponding certificate on the list can be revoked, thereby denying any request for a secret share made by the malicious secret share holder.

[0024] In example aspects of the present disclosure, a method implemented by software executing on a processor of a device includes receiving information about one or more devices, generating one or more certificates for the one or more devices based on the information about the one or more devices, the one or more certificates not indicating an identity of the one or more devices, and distributing the one or more certificates to the one or more devices.

[0025] In example aspects of the present disclosure, the method further includes maintaining regional information about the one or more devices, and providing the regional information to the one or more devices.

[0026] In example aspects of the present disclosure, the providing the regional information includes uploading the regional information to a distributed ledger.

[0027] In example aspects of the present disclosure, the method further includes maintaining a certificate revocation list indicating a revocation status of the one or more certificates distributed to the one or more devices, and providing the certificate revocation list to the one or more devices.

[0028] In example aspects of the present disclosure, the providing the certificate revocation list to the one or more devices includes uploading the certificate revocation list to a distributed ledger.

[0029] In example aspects of the present disclosure, the method further includes receiving an indication that a regional authority has obtained the key.

[0030] In an example aspect of the disclosure, an apparatus includes circuitry including at least a processor coupled to a memory storing computer-readable instructions that, when executed by the processor, cause the processor to receive a first secret share that, in combination with other secret shares, provides a key that provides access to encrypted data, and receive a certificate for authenticating communications of the apparatus without disclosing an identity of the apparatus. The processor also generates a request for one or more secret shares from other apparatuses, signs the request with the certificate, sends the request to the other apparatuses, receives the one or more secret shares in response to the request, and reconstructs the key with the one or more secret shares received and the first secret share when a number of the one or more secret shares received is sufficient to reconstruct the key.

[0031] As can be appreciated, the encrypted data can be sensitive data that is only accessible under certain conditions, such as in the event of a natural disaster, a pandemic, war, a financial crisis, etc. Access to the data can also be authorized in the event of the disappearance of the data owner. The encrypted data itself can include information needed to access funds (e.g., bank account information, stock and bond information, etc.), or can be classified information needed for a particular task required to exercise the conditions for accessing the data.

[0032] In an example aspect of the disclosure, the processor sends the request by uploading the request to a distributed ledger. Communicating using a distributed ledger advantageously protects data written thereto from tampering and / or substitution. Distributed ledgers also facilitate device-to-device communications, such as in Internet of Things (IoT) applications, as will be appreciated by those of ordinary skill in the art.

[0033] In an example aspect of the disclosure, the processor receives the one or more secret shares by downloading the one or more secret shares from a distributed ledger.

[0034] In an example aspect of the disclosure, the processor anonymously uploads the request to the distributed ledger.

[0035] In an example aspect of the disclosure, the processor downloads the one or more secret shares from the distributed ledger without determining an identity of one or more apparatuses corresponding thereto.

[0036] In an example aspect of the disclosure, the processor further receives a request from another apparatus, authenticates the request based on an internal policy of the apparatus, and sends the first secret share to the other apparatus when the request is determined to be valid.

[0037] In an example aspect of the disclosure, the processor verifies the request using zone information; and determines the request is invalid if the zone information indicates the other device is not located in a zone in which data encrypted by the key is accessible.

[0038] In an example aspect of the disclosure, the device verifies the request using a certificate revocation list, and determines the request is invalid if a certificate used to sign the request is indicated as invalid in the certificate revocation list.

[0039] In an example aspect of the disclosure, the processor receives an indication that the key has been obtained by a zone authority.

[0040] In an example aspect of the disclosure, a device includes circuitry including at least a processor coupled to a memory storing computer-readable instructions that, when executed by the processor, cause the processor to: receive information about one or more devices; generate one or more certificates for the one or more devices based on the information about the one or more devices, the one or more certificates not indicating an identity of the one or more devices; and distribute the one or more certificates to the one or more devices.

[0041] In an example aspect of the disclosure, the processor maintains zone information about the one or more devices, and provides the zone information to the one or more devices.

[0042] In an example aspect of the disclosure, the processor provides the zone information to the one or more devices by uploading the zone information to a distributed ledger.

[0043] In an example aspect of the disclosure, the processor maintains a certificate revocation list indicating a revocation status of the one or more certificates distributed to the one or more devices, and provides the certificate revocation list to the one or more devices.

[0044] In an example aspect of the disclosure, the processor provides the certificate revocation list to the one or more devices by uploading the certificate revocation list to a distributed ledger.

[0045] In an example aspect of the disclosure, the processor receives an indication that a zone authority has obtained the key. BRIEF DESCRIPTION OF DRAWINGS

[0046] A more complete understanding of the present application and the many attendant advantages thereof will readily be had by reference to the following detailed description when considered in connection with the accompanying drawings, wherein:

[0047] Figure 1 is a block diagram of an encryption management system according to example aspects of the present disclosure;

[0048] Figure 2 is another block diagram of an encryption management system according to example aspects of the present disclosure;

[0049] Figure 3 is a hardware diagram of a computing device according to example aspects of the present disclosure;

[0050] Figure 4A is a functional block diagram of an encryption management system according to example aspects of the present disclosure;

[0051] Figure 4B is another functional block diagram of an encryption management system according to example aspects of the present disclosure;

[0052] Figure 4C is another functional block diagram of an encryption management system according to example aspects of the present disclosure;

[0053] Figure 4D is another functional block diagram of an encryption management system according to example aspects of the present disclosure;

[0054] Figure 5 is a communication process diagram according to example aspects of the present disclosure;

[0055] Figure 6 is an algorithmic flow diagram of a process performed by a computing device according to example aspects of the present disclosure;

[0056] Figure 7 is another algorithmic flow diagram of a process performed by a computing device according to example aspects of the present disclosure;

[0057] Figure 8A is a functional block diagram of an encryption management system according to example aspects of the present disclosure;

[0058] Figure 8B is another functional block diagram according to example aspects of the present disclosure;

[0059] Figure 9 is a communication process diagram according to example aspects of the present disclosure;

[0060] Figure 10 is an algorithmic flow diagram of a process performed by a computing device according to example aspects of the present disclosure;

[0061] Figure 11 is another algorithmic flow diagram of a process performed by a computing device according to example aspects of the present disclosure;

[0062] Figure 12Ais a functional block diagram of an encryption management system according to example aspects of the present disclosure;

[0063] Figure 12B is another functional block diagram of an encryption management system according to example aspects of the present disclosure;

[0064] Figure 12C is another functional block diagram of an encryption management system according to example aspects of the present disclosure;

[0065] Figure 13 is a communication process diagram according to example aspects of the present disclosure;

[0066] Figure 14 is an algorithmic flow diagram of a process performed by a computing device according to example aspects of the present disclosure;

[0067] Figure 15 is a functional block diagram of an encryption management system according to example aspects of the present disclosure;

[0068] Figure 16A is a functional block diagram of an encryption management system according to example aspects of the present disclosure;

[0069] Figure 16B is another functional block diagram of an encryption management system according to example aspects of the present disclosure;

[0070] Figure 16C is another functional block diagram of an encryption management system according to example aspects of the present disclosure;

[0071] Figure 17A is a functional block diagram of an encryption management system according to example aspects of the present disclosure;

[0072] Figure 17B is another functional block diagram of an encryption management system according to example aspects of the present disclosure;

[0073] Figure 17C is another functional block diagram of an encryption management system according to example aspects of the present disclosure;

[0074] Figure 18 is a functional block diagram of an encryption management system according to example aspects of the present disclosure;

[0075] Figure 19 is a functional block diagram of an encryption management system according to example aspects of the present disclosure;

[0076] Figure 20 is a functional block diagram of an encryption management system according to example aspects of the present disclosure; and

[0077] Figure 21 is a functional block diagram of an encryption management system according to example aspects of the present disclosure. DETAILED DESCRIPTION

[0078] Reference will now be made to the drawings wherein like numerals refer to like components throughout the several figures, Figure 1 is a block diagram providing an overview of an encryption management system in accordance with example aspects of the present disclosure. In Figure 1 , a data owner 100 has data to be securely stored. The data owner 100 connects to a regional custodian 105, which receives the data from the data owner 100, encrypts the data using an encryption key, and transfers the encrypted data to a data storage 110. Once stored in the data storage 110, the encrypted data can only be retrieved by entities having the encryption key. Further details regarding encryption and protection of the data are provided below.

[0079] The data storage 110 and the regional custodian are both connected to a network 140, which can be a public network such as the Internet. Also connected to the network 140 are a licensing authority 135, a distributed ledger 115 (e.g., a blockchain), and a plurality of key managers 120, 125, and 130. As explained in greater detail below, the licensing authority 135 authenticates each of the key managers 120, 125, and 130, for example, by providing certificates to these entities, and the distributed ledger 115 is used by the key managers 120, 125, and 130 to communicate between themselves and the licensing authority.

[0080] As can be appreciated, the distributed ledger 115 (e.g., a blockchain) can be a growing list of records, where each new record or block contains a cryptographic hash of the previous record or block. Such a distributed ledger can be managed by a peer-to-peer network, where a change record requires a change to all previous records due to the cryptographic hash embedded therein, and thus requires unanimous agreement of all peers. Some distributed ledgers can support smart contracts, which facilitate execution of a contract digitally. For example, a piece of information can be provided to a party using a smart contract once that party has certified that certain conditions have been met. Of course, other distributed ledgers are possible without departing from the scope of the present disclosure.

[0081] As previously described, the regional custodian 105 encrypts the data from the data owner 100 using an encryption key. The regional custodian 105 can then generate a secret share from the encryption key and distribute the secret share to the key managers 120, 125, and 130. Each of the secret shares is not sufficient by itself to recover the encryption key. Thus, any one of the key managers 120, 125, and 130 cannot recover the encryption key without obtaining a secret share of at least one other key manager 120, 125, 130, which adds an additional security measure because more than one key manager 120, 125, 130 must agree that access to the encrypted data in the data storage 110 is authorized in order to combine a sufficient number of secret shares to recover the key.

[0082] As can be appreciated, the regional custodian 105 can generate N secret shares and distribute the N secret shares to N key managers. However, it can only take M secret shares to recover the encryption key, where M < N. Thus, it can only take a subset of the key managers 120, 125, 130 to combine their secret shares in order to recover the key. To recover the encryption key, the key managers 120, 125, 130 generate a key request and send the key request to the other key managers 120, 125, 130 via the distributed ledger 115, as will be explained in greater detail below. If sufficient secret shares are received in response to the key request, the requesting key manager 120, 125, 130 is able to recover the encryption key and access the encrypted data stored in the data storage 110. Figure 1

[0083] Figure 1 Three key managers 120, 125, 130 are illustrated. However, this is for clarity only, as in practice there can be more than three key managers. Furthermore, Figure 1 Each of the data owner 100, the regional custodian 105, the data storage 110, the distributed ledger 115, the key managers 120, 125, 130, and the licensing authority 135 is illustrated as a separate entity. However, this is for clarity only. Thus, Figure 1 The different blocks illustrated in the diagram of FIG. 1 can be separate, independent entities, or can form part of a single entity, but are not limited thereto.

[0084] Figure 1 Each of the blocks illustrated in the diagram of FIG. 1 can be a single device, such as a computer, a laptop, a tablet computer, a mobile phone, etc.; or Figure 1 Each of the blocks illustrated in the diagram of FIG. 1 can itself be a system comprising several different devices (e.g., computers, servers, etc.) interconnected by a network. Thus, Figure 1 The particular composition of the blocks illustrated in the diagram of FIG. 1 is not limiting to the present disclosure.​

[0085] Figure 2 may form Figure 1 An example block diagram of a system that can be one or more of the blocks illustrated in Figure 2 The system illustrated in can correspond to any of the data owner 100, the regional custodian 105, the data storage 110, the distributed ledger 115, the licensing authority 135, or any of the key managers 120, 125, 130. In Figure 1 In the case where any of the blocks in are included in a single system, the single system can be illustrated by Figure 2 For example, the data owner 100, the regional custodian 105, and the data storage 110 can be part of a single system, such as Figure 2 As can be appreciated, other combinations of different blocks of into a single system (e.g., the system of Figure 1 are possible. Figure 2

[0086] Figure 2 The example system illustrated in includes multiple computing devices 205, 210, 215 and multiple server devices 220, 225, 230 interconnected by a local area network (LAN) 200. As can be appreciated, the LAN 200 can be a packet-switched network that is a private network, a public network, or a combination of private and public networks. The LAN 200 can also include wired or wireless portions, and can be connected to a public network (e.g., the Internet).

[0087] The computing devices 205, 210, 215 can include desktop computers, laptop computers, tablet computers, mobile phones, thin clients, and any other known computing devices. The computing devices 205, 210, 215 can also have permanent, semi-permanent, or temporary connections to the LAN 200. These connections can also be wired, such as Ethernet connections, or can be wireless, such as WiFi, Bluetooth, or cellular connections (i.e., 3G, 4G, LTE, etc.). Although three computing devices 205, 210, 215 are illustrated, the system of Figure 2 The system of can include any number of computing devices, but is not limited thereto.

[0088] The servers 220, 225, and 230 are connected to the LAN 200 via permanent connections, and can store data and can provide services to the computing devices 205, 210, 215, such as email, database services, etc. In the system of Figure 2 In the system of there can be more than three servers or fewer than three servers, but is not limited thereto.

[0089] Next, reference is made to Figure 3 ​A description of the hardware of the computing devices 205, 210, 215, and servers 220, 225, 230 is provided. In Figure 1 cases where the blocks illustrated in FIG. 1 correspond to individual devices, the hardware of those devices can also be as illustrated in Figure 3 FIG. 2. Figure 3 The device of FIG. 1 includes a processor 305, a communication interface 310, a main memory 325, a read only memory (ROM) 320, a disk controller 315, a display controller 330, a hard disk 340, and a removable media drive 335.

[0090] The processor 305 can be based on a reduced instruction set (RISC) circuit architecture, a von Neumann architecture, a Harvard architecture, or any other known processing circuit architecture. The processor 305 can also be implemented as a system on a chip, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or having discrete logic circuit components. The processor 305 can also be implemented in software executing on processing circuitry having any of the above described architectures.

[0091] The communication interface 310 is circuitry that connects the device of FIG. 1 to one or more communication networks, such as an Ethernet network, a cellular network, a WiFi network, a Bluetooth network, etc. For example, the communication interface 310 can be a network interface card (NIC). Figure 3

[0092] The main memory 325 and the ROM 320 are used to store instructions and other data needed by the processor 305 to carry out various tasks in accordance with exemplary aspects of the present disclosure. In particular, the ROM 230, being a read only memory circuit, can contain permanent instructions that do not need to change, such as lower level routines. The main memory 325 can contain a combination of random access memory and erasable programmable read only memory (EPROM) to store programming instructions that can be updated periodically, as well as data that can change periodically or frequently as the processor 305 executes the instructions.

[0093] The display controller 330 is an interface circuit that permits a display 345, such as a liquid crystal display, to be connected to the device of FIG. 1 in order to provide visual information to a user thereof. The disk controller 315 is an interface circuit that permits devices such as a hard disk 340 providing mass storage to be connected to the bus 300 and thus to the processor 305. The disk controller 315 also permits connection of other removable media 335 such as an optical disk reader or a secure digital (SD) card, memory stick, etc. A keyboard 350 and a pointing device 355 such as a mouse can also be connected to the device of FIG. 1 as illustrated in order to provide a way for a user of the device to enter data into the device. Further description of these components is omitted for brevity. Figure 3 Figure 3 The display controller 330 is an interface circuit that permits a display 345, such as a liquid crystal display, to be connected to the device of FIG. 1 in order to provide visual information to a user thereof. The disk controller 315 is an interface circuit that permits devices such as a hard disk 340 providing mass storage to be connected to the bus 300 and thus to the processor 305. The disk controller 315 also permits connection of other removable media 335 such as an optical disk reader or a secure digital (SD) card, memory stick, etc. A keyboard 350 and a pointing device 355 such as a mouse can also be connected to the device of FIG. 1 as illustrated in order to provide a way for a user of the device to enter data into the device. Further description of these components is omitted for brevity. ​​

[0094] Next, reference is made to Figures 4A-4D descriptions of various functions performed by the data owner 100, the regional custodian 105, the data storage 110, the distributed ledger 115, the licensing authority 135, and the key managers 120, 125, 130. In Figure 4A In step 400, the data owner 100 passes data to be securely stored to the regional custodian 105. It should be noted that the type and quantity of data to be securely stored is not limiting to the present disclosure, as the inventive features described herein apply to the storage of any type and quantity of data. After receiving the data from the data owner 100, the regional custodian 105 encrypts the data using an encryption key and transmits the encrypted data to the data storage 110 at step 405, where the encrypted data is securely stored.

[0095] The regional custodian 105 then generates a secret share from the encryption key and distributes the secret share to the key managers 120, 125, 130 at step 410. In one exemplary aspect, each key manager 120, 125, 130 receives one secret share. However, each key manager 120, 125, 130 can receive more than one secret share, and each key manager 120, 125, 130 can store secret shares corresponding to different encryption keys for different encrypted data.

[0096] The regional custodian 105 can generate the secret share using an algorithm (e.g., the Shamir secret sharing scheme), but other methods and algorithms for generating secret shares are possible. Once the secret share is generated and distributed, the regional custodian destroys the encryption key. Alternatively, the regional custodian 105 can not destroy the encryption key and can maintain the securely stored encryption key for access by an entity such as a government entity.

[0097] As Figure 4B As illustrated in FIG. 1, the licensing authority 135 can provide each of the key managers 120, 125, 130 with an identity certificate. The identity certificate is generated by the licensing authority 135 based on information from the key managers 120, 125, 130, but does not reveal the identity of the key managers 120, 125, 130. Instead, the certificate provides a guarantee to the key managers 120, 125, 130, such that a message from, for example, the key manager 120 containing the key manager’s 120 certificate can be authenticated as a legitimate message even if the identity of the key manager 120 is not disclosed in the message, in the certificate, or during message authentication.

[0098] The identities of key managers 120, 125, and 130 are known to licensing authority 135. The licensing authority verifies the identities of key managers 120, 125, and 130 and generates identity certificates using pseudonyms to protect the true identities of key managers 120, 125, and 130, who remain anonymous to each other. The licensing authority may also include additional information in the certificates, such as the license level of the key managers and their approximate geographical location. Licensing authority 135 may also set time limits for the identity certificates, requiring them to be updated periodically. The licensing authority may also require identity certificate updates when events occur, such as a key manager moving from one geographical region to another, or a change in the number or composition of key managers. Of course, as those skilled in the art will recognize, many other events can trigger identity certificate updates. The events described above are merely illustrative.

[0099] To generate identity certificates, the licensing authority 135 may verify that key managers 120, 125, and 130 are associated with data owner 100 in some way, such as being a spouse, child, other family member, or business partner of the data owner, and that key managers 120, 125, and 130 are residents of a specific geographic area (e.g., city, state, country). The licensing authority 135 may also verify the amount of funds held by key managers 120, 125, and 130, or otherwise verify the financial status of the key managers, and may verify the security licenses of key managers 120, 125, and 130. As may be understood, the licensing authority 135 may verify any information relating to, but not limited to, key managers 120, 125, and 130 or the relationship between each of them and data owner 100. The information items mentioned above are merely exemplary.

[0100] To verify the key manager information, licensors 120, 125, and 130 may be part of a company and, for example, associated with or forming part of the company's human resources department. Licensors may also be part of local or regional governments (e.g., municipal, state, provincial, or national governments). Licensor 135 may also be part of international organizations (e.g., the World Health Organization, the International Monetary Fund, etc.). In fact, the specific organization or entity forming part of licensor 135 is not limiting to this disclosure.

[0101] Using the information described above, the licensing authority generates a certificate for each of the key managers 120, 125, and 130, and distributes the certificate to the respective key managers 120, 125, and 130 at step 415. It should be noted that the licensing authority 135, through, for example... Figure 1The network 140 provides the certificate to the key managers 120, 125, 130. The certificate can also be provided to the key managers 120, 125, 130 by the licensing authority 135 by uploading the certificate to the distributed ledger 115. In certain example aspects, the certificate of the key managers 120, 125, 130 can be loaded onto a portable storage medium and physically delivered to the location of the key managers 120, 125, 130. Other methods of distributing the certificate to the key managers 120, 125, 130 are also possible without departing from the scope of the disclosure.

[0102] Figure 4C A key request is generated and transmitted by one of the key managers (e.g., key manager 120) in accordance with example aspects of the disclosure is illustrated. In Figure 4C The key manager 120 generates a key request in which the key manager requests a secret share of the other key managers 125 and 130. The key manager 120 signs the request with its certificate, which is received from the licensing authority 135 as explained above with reference to Figure 4B Subsequently, at 420, the key manager 120 uploads the request anonymously to the distributed ledger 115.

[0103] Since the key managers 120, 125, 130 all monitor the distributed ledger 115, the other key managers 125 and 130 detect that the request has been uploaded to the distributed ledger 115 and download the request at 425. Each key manager 125 and 130 then authenticates the request to ensure that it is a legitimate request, even though the key managers 125 and 130 cannot determine the identity of the request sender from the request itself. Each key manager 125, 130 then compares the request to its own internal policies to determine whether to grant or deny the request.

[0104] For example, in Figure 4D The key manager 125 determines that the request from the key manager 120 is not authorized. Therefore, the key manager 125 takes no action with respect to the request and does not upload anything to the distributed ledger 115. Instead, the key manager 125 can upload a message to the distributed ledger 115 anonymously indicating that the request from the key manager 120 was denied.

[0105] The key manager 130 determines that the request sent by the key manager 120 is authorized and, in response, uploads a message containing its secret share anonymously to the distributed ledger 115 at 440. The message containing the secret share of the key manager 130 can be signed with the certificate of the key manager 130 so as to vouch for the message being authentic without revealing the identity of the key manager 130.

[0106] At 435, the key manager 125 downloads the message from the key manager 130 and authenticates the message. Once the message is authenticated, the key manager extracts the secret shares of the key manager 130 and determines whether it has enough secret shares (including its own secret share) to recover the encryption key. If the key manager 120 determines that it has enough secret shares to recover the encryption key, the encryption key manager 120 can then combine the secret shares it has to recover the encryption key. Once the encryption key is recovered, the key manager can access the encrypted data stored in the data store 110 at 430, decrypt the data using the encryption key, and use the data.

[0107] On the other hand, if the key manager 120 determines that it does not have enough secret shares to recover the encryption key, the key manager 120 can save the secret shares received from the other key managers for a predetermined amount of time to wait for additional secret shares to be uploaded by the other key managers. If no additional secret shares are uploaded, the key manager 120 can destroy the secret shares received from the other key managers (e.g., the key manager 130).

[0108] Next, reference is made to Figure 5 communications exchanged between the data owner 100, the regional custodian 105, the data store 110, the licensing authority 135, and the key managers 120, 125, 130 are described. In Figure 5 In the communications exchanged between the data owner 100, the regional custodian 105, the data store 110, the licensing authority 135, and the key managers 120, 125, 130 are described. In

[0109] The regional custodian 105 then generates the secret shares for the key managers 120, 125, 130, as described above, and transmits the secret shares to the key managers 120, 125, 130 at 510. As can be appreciated, the transmission of the secret shares can be over a secure connection (e.g., a virtual private network (VPN) connection), and the secret shares can be encrypted as an additional security measure.

[0110] At 515, the licensing authority 135 distributes the certificates to the key managers 120, 125, 130, for example, using secure connections such as those described above. The certificates can also be encrypted prior to transmission.

[0111] Key manager 120 generates a key request and, at 520, anonymously sends the key request to other key managers 125 and 130. As may be understood, the key request is sent to other key managers 125 and 130 via a distributed ledger 115 using a system such as Tor to maintain anonymity. Key managers 125 and 130 authenticate the request and, in response, determine whether to upload their secret share based on their own internal policies.

[0112] At point 525, if key manager 125 determines not to upload its secret share, no further action is taken and no further communication is generated. If key manager 130 determines to upload its secret share to distributed ledger 115, the key manager generates a message containing its secret share and signed with its certificate, and anonymously uploads the message to distributed ledger 115 at point 530.

[0113] Key manager 120 continuously monitors distributed ledger 115 for messages and detects messages uploaded by key manager 130. Although key manager 120 cannot determine the identity of key manager 130 from the message, it can still authenticate the message due to the signature based on key manager 130's certificate. Therefore, key manager 120 can extract the secret share from the message sent by key manager 130 and combine this secret share with its own secret share to recover the encryption key. At 535, key manager 120 can use the encryption key to access data stored in data storage device 110 and decrypt the data for use.

[0114] Next, refer to Figure 6 The algorithm flowchart is explained by other key managers (e.g., Figures 4A-4B The key manager of 5 (120) requests the secret sharing key manager to perform the process. Figure 6 The process begins at step 600 and proceeds to step 605, where the key manager generates a key request. At step 610, the key manager signs the key request with its certificate, and at step 615, the key manager uploads the signed key request to a distributed ledger, such as distributed ledger 115 described above. The key manager then monitors the distributed ledger for messages that may contain secret shares in response to the uploaded key request.

[0115] If, at 620, the key manager determines that a message containing a secret share has been uploaded to the distributed ledger, the key manager proceeds to 625, where the key manager authenticates the message and extracts the secret share contained in the message. At step 625, the key manager also determines whether it has enough secret shares to recover the encryption key. If so, the key manager proceeds to 630 to reconstruct the encryption key, followed by accessing the data encrypted with the encryption key at 635.

[0116] If, at 620, the key manager does not detect the message in the distributed ledger, the key manager remains at 620 to continue monitoring the distributed ledger. Although not shown, in one example aspect, the key manager can monitor the distributed ledger for a predetermined amount of time, followed by ending the process at 640 if no message containing a secret share is uploaded within the time. Alternatively, the key manager can monitor the distributed ledger at all times. In this way, the key manager can monitor the distributed ledger not only for responses to its own key requests, but also for key requests from other key managers.

[0117] At 625, if the key manager determines that it does not have enough secret shares, it can proceed to 640 to end the process. At 640, the key manager can destroy any secret shares it can have from other key managers.

[0118] Next, reference is made to Figure 7 a process performed by a key manager that receives a key request is described. Figure 7 The process illustrated in FIG. 7 begins at step 700 and proceeds to step 705, where the key manager receives a key request. As mentioned above, the request can be received via a distributed ledger (e.g., distributed ledger 115) that the key manager monitors. As also described above, the request can be anonymous in that it is not possible to discern the identity of the originator of the request from the request itself.

[0119] At step 710, the key manager compares the request to its own internal policies. This can include determining whether the request originated from a particular region, whether certain global, political, or economic conditions are met, etc. For example, the key manager can have a policy that prohibits providing access to an encryption key to an entity located in a different country than the country in which the key manager is located. Thus, if the key manager determines that the request originated from a different country, the key manager can deny the request and not send its secret share to the originator of the request. It should also be noted that each key manager can have its own set of policies, at least some of which are different from the policies of other key managers.

[0120] At step 715, the receiving key manager determines whether to accept the request after comparing the request to its internal policy. If the key manager accepts the request, the process proceeds to step 720, where the key manager uploads the request to a distributed ledger, such as the distributed ledger 720. Subsequently, the process ends at step 725.

[0121] If at step 715, the key manager does not accept the request, the process proceeds to step 725 and ends. It should be noted that if the key manager rejects the request, the key manager does not respond to the request and thus does not upload or otherwise transmit a rejection notification to the key manager that transmitted the request. However, in an alternative, the key manager can upload a notification of the rejected request to the distributed ledger 115. Like other communications, the rejection notification is anonymous such that the notification originator cannot be identified from the notification itself. Sending a rejection notification can allow the key manager that sent the request to more quickly determine whether there is a possibility of receiving additional secret shares, or whether all other key managers have responded and will not receive more secret shares. Of course, other variations are possible without departing from the scope of the present disclosure.

[0122] In aspects of the present disclosure, it can be advantageous to avoid transmitting secret shares through the distributed ledger 115 or via any other communication medium in response to a request to recover an encryption key. In such cases, a multi-party computation scheme can be utilized. A multi-party computation scheme (or MPC) is a cryptographic primitive that allows two or more parties to compute a function of their respective inputs (i.e., respective secret shares), i.e., a secret sharing scheme, without actually revealing their secret share to the other parties. In effect, a party can reconstruct an encryption key without knowing the secret shares of the other parties by receiving the MPC view of the other parties and combining these MPC views with its own view. Reference is made to Figures 8A-8B This process is explained in further detail.

[0123] In Figure 8A The key manager 120 generates a key request containing its MPC view and signed with its identity certificate. As described above, the key manager 120 receives the identity certificate from the licensing authority 135. After preparing the key request, the key manager 120 anonymously uploads the key request to the distributed ledger 115, which can be a blockchain, at 800. As mentioned above, this can be done using Tor or a similar system for maintaining anonymity.

[0124] The other key managers 125 and 130 monitor the distributed ledger 115 to determine if a request or other related communication has been uploaded. Thus, the key managers 125 and 130 are able to detect that a key request was uploaded to the distributed ledger 115 and download the key request at 805. As mentioned above, the key request includes the MPC view of the key manager 120 and is signed with the identity certificate of the key manager 120.

[0125] Each key manager 125 and 130 determines whether to accept or reject the key request based on its own internal policy, as described above. For example, the key manager 125 rejects the request and thus takes no further action with respect to the request.

[0126] The key manager 130 accepts the request and uploads a response to the distributed ledger 115 at 810. The response from the key manager 130 includes the MPC view of the key manager 130 and is signed with the identity certificate of the key manager 130. Also, the key manager 130 anonymously uploads the response to the distributed ledger 115 using a system such as Tor or any other system to maintain known anonymity.

[0127] The key manager 120 that sent the key request monitors the distributed ledger 115 for responses from the other key managers 125 and 130. At 815, the key manager 120 determines that a response has been uploaded to the distributed ledger 115 and downloads the response. Then, the key manager 120 extracts the MPC view included in the response and combines it with its own MPC view to determine whether the two MPC views are sufficient to recover the encryption key. If the encryption key can be recovered, then the key manager 120 accesses the data stored in the data store 110 at 820.

[0128] If the key manager does not receive enough responses to recover the encryption key, the key manager 120 can destroy the received responses or can store the MPC views in the received responses in case additional responses are received in the future. In one aspect, the MPC views in the responses received by the key manager 120 can expire after a predetermined amount of time to prevent the key manager 120 from indefinitely storing MPC views and eventually recovering the encryption key. Other variations are possible as will be appreciated by one of ordinary skill in the art.

[0129] Next, reference is made to Figure 9The communication exchange between the key managers 120, 125, and 130 and the data store 110 is described. At 900, the key manager 120 anonymously communicates a key request to the key managers 125 and 130 via, for example, the distributed ledger 115. As mentioned above, the key request can include the MPC view of the key manager 120 and is signed by the identity certificate of the key manager 120. However, it is not possible to determine the identity of the key manager 120 from the key request. In an example variation, the key request can not include the MPC view of the key manager 120.

[0130] At 905, the key manager 125 denies the key request from the key manager 120 based on its internal policy. Accordingly, the key manager 125 takes no further action with respect to the key request. In an example variation, the key manager 125 can send a denial notification to the key manager 120 by anonymously uploading the notification to the distributed ledger 115. The notification can be signed with the identity certificate of the key manager 125, but the identity of the key manager 125 is also protected such that it is not possible to determine the identity of the sender of the notification from the notification itself.

[0131] At 910, the key manager 130 accepts the key request from the key manager 120 and, in response, sends a response to the key manager 120 via the distributed ledger 115. As described above, the response includes the MPC view of the key manager 130 and is signed with the identity certificate of the key manager 130. However, it is not possible to determine the identity of the sender of the response from the response alone, thereby protecting the anonymity of the key manager 130.

[0132] At 915, the key manager 120 receives the response from the key manager 130 by downloading the response from the distributed ledger 115 and uses the MPC view in the response along with its own MPC view to recover the encryption key and access the data in the data store 110.

[0133] Next, reference is made to Figure 10 The process performed by the key manager that generates the key request is explained. Figure 10 The method in FIG. 10 begins at step 1000 and proceeds to step 1005 where the key manager generates a key request. As mentioned above, the key request can include the MPC view of the key manager, or alternatively, the MPC view of the key manager can be omitted. At step 1010, the key manager signs the key request with its identity certificate and at step 1015 the key manager uploads the key request to the distributed ledger 115. As mentioned above, the key request is uploaded to the distributed ledger 115 anonymously and the identity of the key manager is protected since it is not possible to identify the sender of the key request from the key request itself.

[0134] At step 1020, the key manager monitors the distributed ledger 115 to determine whether a response to the key request has been uploaded. If the response has not been uploaded, the process remains at step 1020. As can be appreciated, the key manager can continuously monitor the distributed ledger 115 and thus remain at step 1020 indefinitely, or the key manager can stop monitoring the distributed ledger 115 after a predetermined amount of time.

[0135] If at step 1020, the key manager detects a response in the distributed ledger 115, the process moves to step 1020, where the key manager downloads the response, extracts the MPC view stored in the response, and determines whether the encryption key can be reconstructed. If the encryption key cannot be reconstructed, the process ends at step 1040. However, if the encryption key can be reconstructed, the process moves to step 1030, where the key manager combines the MPC view received in the response with its own MPC view in order to reconstruct the encryption key. Then, the process moves to step 1035, where the key manager uses the encryption key to access data stored in the data store. Subsequently, the process ends at step 1040.

[0136] Next, reference is made to Figure 11 The process performed by the key manager that receives the key request is described. Figure 11 The process in FIG. 11 begins at step 1100 and proceeds to step 1105, where the key manager receives the key request by downloading the key request from the distributed ledger 115. The key manager cannot determine the identity of the sender of the key request, but the key manager is able to verify the authenticity of the request because the request has been signed with an identity certificate.

[0137] At step 1115, the key manager compares the key request to its internal policies in order to determine whether to allow or deny the request. The comparison of the request to the key manager’s internal policies has been described above and is not repeated here for the sake of brevity.

[0138] At step 1120, the key manager determines whether to accept or reject the key request based on the comparison of the key request to its internal policies. If the key manager rejects the request, the process ends at step 1130. However, if the key manager accepts the request, the process moves to step 1125, where the key manager generates a response and uploads the response to the distributed ledger 115. As described above, the response includes the MPC view of the key manager and is signed with the identity certificate of the key manager. However, it is not possible to discern the identity of the key manager from the response alone. Also, the key manager uploads the request to the distributed ledger 115 anonymously, as described above.

[0139] In certain example aspects, it can be advantageous to restrict access to data in data store 110 based on geographic location. For example, some regions have more stringent regulations than others, such as the General Data Protection Regulation (GDPR) in Europe. In such cases, it can be desirable to limit access to data in data store 110 to regions that comply with the GDPR. Reference is made below to Figures 12A-12C Implementing regional access using the features of the application described herein is described.

[0140] In Figure 12A , licensing authority 135 generates and maintains a regional identity registry 1200 that associates a key manager's certificate with the region to which the corresponding key manager is associated. For example, in Figure 12A , regional identity registry 1200 associates a key manager's identity certificate with China, Switzerland, Italy, and the United States. As can be appreciated, Figure 12A Regional identity registry 1200 in Figure 12A is merely an example of a regional identity registry and associates key manager identity certificates with Figure 12A other countries as shown in It is also possible for licensing authority 135 to maintain multiple regional identity registries, as one of ordinary skill in the art will recognize.

[0141] In Figure 12A , at 1210, key manager 120 generates a key request and uploads the key request to distributed ledger 115. At 1205, other key managers 125 and 130 download the key request from distributed ledger 115. Then, as Figure 12B illustrated in , at 1215, key managers 125 and 130 query the licensing authority to determine whether the key request is from a key manager located in a region where access to data in data store 110 is possible. Key managers 125 and 130 can query licensing authority 135 by, for example, providing the identity certificate included in the key request.

[0142] In response to the query, licensing authority 135 can respond to key managers 125 and 130 with the country or region corresponding to the identity certificate provided by key managers 125 and 130. This allows each of key managers 125 and 130 to independently determine whether to accept the request by comparing the country to its own internal policies. Alternatively, licensing authority 135 can respond to the key managers with instructions indicating whether key managers 125 and 130 are to accept or reject the request.

[0143] In Figure 12CIn this process, after consulting the area identity register 1200, key manager 130 determines an acceptable key request based on the response from the licensing authority. Therefore, at 1220, key manager 130 sends a response to the key request. The response contains key manager 130's secret share and is signed with key manager 130's identity certificate. Of course, the response may contain key manager 130's MCP view instead of the key manager's secret share as discussed above. As described above, the response from key manager 130 is uploaded to distributed ledger 115, while maintaining key manager 130's anonymity.

[0144] Key manager 120 monitors distributed ledger 115 for any responses to its key requests. Therefore, key manager 120 can detect that a response has been uploaded, but cannot determine whether it was uploaded by key manager 130. Then, at 1225, key manager 120 downloads the response, verifies its reliability using the identity certificate that signed the response, and extracts a secret share or MPC view as appropriate. Key manager 120 then determines whether it is possible to recover the encryption key from the information contained in the response; if so, at 1230, the encryption key is recovered and the data stored in data storage device 110 is accessed.

[0145] If the key manager 120 is unable to recover the encryption key using the received response, the key manager may destroy the received response after a predetermined time period, or may maintain the response for a predetermined time period to see if another response that can be used to recover the encryption key in combination with the response already received by the key manager 120 is uploaded.

[0146] Next, refer to Figure 13 Explanation and Figures 12A-12C The corresponding communication exchange. In Figure 13 At 1300, key manager 120 sends a key request by uploading it to distributed ledger 115, as described above. Key managers 125 and 130 download the key request from distributed ledger 115 and at 1305 query licensee 135 to determine whether the key request originates from a region that allows access to data in data storage device 110. As explained above, the query from key managers 125 and 130 may include an identity certificate included in the request, allowing licensee 135 to verify the location of the corresponding entity by consulting the region identity register 1200.

[0147] After consulting the regional identity register 1200, at 1310 the licensing authority 135 responds to the key managers 125 and 130. The response of the licensing authority 135 can include the region from which the key request originated, or can include instructions indicating that the key manager 125 and 130 accept or reject the key request. The response from the licensing authority 135 can be sent via the distributed ledger 115, the network 140, or another communication channel, as will be appreciated by one of ordinary skill in the art. The response can also be encrypted using any known encryption method, such as Rivest-Shamir-Adleman (RSA) encryption.

[0148] Based on the response from the licensing authority, the key manager 1315 determines that the key request should be rejected and takes no further action. The key manager 130 determines that the key request should be accepted, and at step 1320 responds to the request by uploading its secret shares to the distributed ledger 115. As explained above, the response from the key manager 130 can include its MPC view rather than its secret shares.

[0149] The key manager 120 determines that a response has been uploaded to the distributed ledger 115, and downloads the response. The key manager 120 then determines that the encryption key can be recovered based on the information included in the response, and recovers the encryption key. At 1325, the key manager 120 uses the encryption key to access data stored in the data store 110.

[0150] Next, reference is made to Figure 14 The process performed by the key manager that receives the key request (e.g., the key manager 125 and 130) is described. Since the process performed by the key manager that sends the key request (e.g., the key manager 120) is substantially the same as the process described above, further description is omitted for the sake of brevity.

[0151] Figure 14 The process in FIG. 14 begins at step 1400 and proceeds to step 1405, where the key manager receives a key request. As mentioned above, the request is received anonymously via the distributed ledger 115 and signed by a certificate of identity of the sender, which authenticates the key request without revealing the identity of the sender.

[0152] At step 1410, the key manager queries the licensing authority for regional information regarding the key request. At step 1415, the key manager compares the regional information received from the licensing authority 135 to its internal policy to determine whether the key request is acceptable. As mentioned above, the key manager's internal policy can indicate that the key request must originate from a GDPR-compliant region to be accepted. However, the ordinarily skilled artisan will also recognize that other region- and geography-based restrictions are possible.

[0153] At step 1420, the key manager accepts or rejects the key request. If the key manager accepts the key request, the process moves to step 1425, where the process uploads the secret share in response to the key request to the distributed ledger 115. As explained above, the response is signed with the key manager's identity certificate, but the identity of the key manager remains anonymous. The process ends at step 1430.

[0154] If at step 1420, the key manager rejects the key request, the process moves to step 1430, at which point the process ends. It should be noted that no action is required by the key manager side after the key manager determines that the key request should be rejected. However, in some example aspects, the key manager can anonymously upload a notification of the rejection to the distributed ledger 115.

[0155] Figure 15 Other example aspects of the disclosure are illustrated. In Figure 15 In an example aspect, the licensing authority 135 uploads the regional identity register 1200 to the distributed ledger 115 at 1500. This eliminates the need for the key managers 120, 125, 130 to query the licensing authority 135 for regional information, as that information is now available on the distributed ledger 115. Because the regional identity register 1200 associates the identity certificates of different key managers with their corresponding regions, the identity of the key managers remains anonymous even though the regional identity register 1200 is placed on the distributed ledger 115.

[0156] In example aspects, a licensing authority for each region can be used. For example, in Figure 16A In an example aspect, there are three licensing authorities 1600, 1605, 1610, each corresponding to a different region. Each of the licensing authorities 1600, 1605, 1610 can correspond to a different country or a different region within a country. The licensing authorities 1600, 1605, 1610 can also correspond to different corporate entities, or different divisions of a single corporate entity. Other variations are possible without departing from the scope of the disclosure.

[0157] As in the other example aspects that have been explained, at 1620, Figure 16AThe key managers 125 and 130 can upload the key requests to the distributed ledger 115, and at 1615, the key managers 125 and 130 can download the key requests from the distributed ledger 115. The key managers 125 and 130 can then use, for example, the identity certificates included in the key requests to query their corresponding license authorities. In particular, at 1625, the key manager 125 can query the license authority 1605, and at 1630, the key manager 130 can query the license authority 1610.

[0158] As Figure 16C illustrated in FIG. 16B, the key manager 125 denies the request based on the zone information provided by the license authority 1605. However, the key manager 130 accepts the key request based on the zone information obtained from the license authority 1610. Accordingly, at 1635, the key manager 130 responds to the key request by anonymously uploading its secret share to the distributed ledger 115. The details of uploading the response to the distributed ledger 115 and maintaining anonymity of the key manager 130 have been described above and are not further discussed here. At 1640, the key manager 120 downloads the response including the secret share of the key manager 130, reconstructs the encryption key, and accesses the data stored in the data store 110 at 1645.

[0159] In example aspects, it can be advantageous to guard against a case where one of the key managers is a bad actor. For example, a key manager can recover the encryption key with a false pretext (e.g., claiming to have an emergency). A key manager can also launch a denial-of-service (DoS) attack on the system by repeatedly sending false key requests. To identify a misbehaving key manager and punish the key manager, for example, by revoking the key manager's rights as a key manager, the license authority 135 can maintain a certificate revocation list (CRL) 1700 that associates the identity certificates of the key managers 120, 125, 130 with a corresponding status (i.e., good or revoked).

[0160] In Figure 17A FIG. 17A, at 1710, the key manager 120 uploads a plurality of key requests to the distributed ledger 115 as part of a DoS attack. At 1705, the license authority 133 and the key managers 125 and 130 download the requests from the distributed ledger 115. The license authority 135 can then determine that the requests are false and part of a DoS attack by comparing the number of requests per unit of time to a threshold and / or by analyzing the content of the requests. Once the license authority 135 determines that the requests from the key manager 120 are fraudulent, the license authority can compare the identity certificates used to sign the requests to the CRL 1700 and revoke the identity certificate of the key manager 120 that sent the fraudulent requests.

[0161] In Figure 17B , the key managers 125 and 130 query the licensing authority using, for example, the identity certificate corresponding to the key request downloaded from the distributed ledger 115. The licensing authority 135 can then compare the identity certificate of the query to the key managers 125 and 130 to the CRL 1700 and determine that the identity certificate has been revoked. The licensing authority then notifies the key managers 125 and 130 of this information, and the key managers 125 and 130 deny the request, as Figure 17C illustrated in

[0162] As illustrated in Figure 18 , the licensing authority 135 can upload the CRL 1700 to the distributed ledger 115. In this case, the key managers 120, 125, 130 do not need to query the key managers 135 directly. Instead, the key managers 120, 125, 130 can download the CRL 1700 from the distributed ledger 115 and perform their own comparison of the identity certificate corresponding to the received key request to the CRL 1700.

[0163] As can be appreciated, whenever the status of an identity certificate of one of the key managers 120, 125, 130 changes, whenever a new key manager is added, whenever a key manager is removed, or periodically, Figure 18 the licensing authority in may upload a new version of the CRL 1700 to the distributed ledger 115. The licensing authority can also upload multiple CRLs 1700, each corresponding to a different encryption key, a different geographic region, a different company, or a combination thereof.

[0164] In certain aspects, it can be advantageous to provide the encryption key to the regional authority 1900 (e.g., a government agency) without forcing the regional authority to obtain the secret shares of the key managers 120, 125, 130 to recover the key.

[0165] Figure 19 An exemplary aspect of the disclosure is illustrated in which the regional custodian 105 does not destroy the encryption key after encrypting the data stored in the data storage 110 and distributing the secret shares to the key managers 120, 125, and 130. Upon presentation of the credentials required to establish the reliability of the regional authority 1900 to the regional custodian 105, at 1905, the regional custodian 105 can provide the encryption key to the regional authority 1900. Subsequently, at 1910, the regional authority 1900 can utilize the encryption key to access the data stored in the data storage 110.

[0166] Alternatively, the regional custodian 105 may lock the encryption key in a key vault 2000. For example, the encryption key itself may be encrypted with a key and stored in the key vault. Once the regional authority presents the required certificate, the regional custodian can provide the regional authority 1900 with a key to access the encryption key.

[0167] Alternatively, such as Figure 20 As illustrated, regional custodian 105 can place the key in a smart contract and upload the smart contract to distributed ledger 115. This requires a distributed ledger capable of using smart contracts. Then, at 2010, regional authority 1900 can access the key in the smart contract using the required certificate or other information. Using the key, at 2005, regional authority 1900 can access the encryption key in key vault 2000, and at 2015, can use the encryption key to access data in data storage device 110.

[0168] In other respects, regional custodian 105 can place the encryption key directly into a smart contract and upload the smart contract to a distributed ledger 115, which is a distributed ledger capable of using smart contracts (step 2100). This is in... Figure 21 The diagram is shown below. Then, at 2105, the regional agency 1900 can directly access the encryption key from the smart contract using the appropriate certificate and / or other information. Then, at 2115, the regional agency 1900 is able to access the data in data storage device 110 using the encryption key. At 2110, the regional custodian notifies the regional agency 1900, to key managers 120, 125, and 130, and to licensing authority 135, that the data in data storage device 110 has been accessed. As may be understood, the regional custodian 105 may also notify the data owner 100 that the data in data storage device 110 has been accessed by the regional agency 1900.

[0169] Obviously, numerous modifications and variations of the invention are possible in light of the foregoing teachings. Therefore, it should be understood that the invention can be practiced in ways different from those specifically described herein, within the scope of the appended claims.

Claims

1. A method for generating a key, comprising: The device's processing circuitry generates a request for secret information corresponding to the key; The request is signed using a pseudonym that identifies the request as a valid certificate; The request, signed with the certificate, is sent to at least one other device; Receive the requested secret information corresponding to the key from the multi-party computation view from the at least one other device; Determine whether the secret information corresponding to the key received from the at least one other device is sufficient to reconstruct the key; as well as After determining that the secret information corresponding to the key is sufficient to reconstruct the key, the key is reconstructed using the information corresponding to the key.

2. The method according to claim 1, further comprising: Use the key to retrieve encrypted data from the data storage device.

3. The method of claim 2, wherein retrieving the encrypted data comprises decrypting the encrypted data using the key.

4. The method of claim 1, wherein the means sends the request to the at least one other means by uploading the request to a distributed ledger.

5. The method of claim 4, wherein the device anonymously uploads the request to the distributed ledger.

6. The method of claim 5, wherein the apparatus uses the Tor router to upload the request to the distributed ledger to remain anonymous.

7. The method of claim 4, wherein the distributed ledger is a blockchain.

8. The method of claim 5, wherein the apparatus receives the secret information corresponding to the key by downloading the secret information corresponding to the key from the distributed ledger.

9. The method of claim 1, further comprising: Receive the first secret share as the secret information corresponding to the key from the server that manages the secret share and the key; as well as The first secret share is combined with one or more secret shares to reconstruct the key.

10. The method of claim 1, wherein the secret information received by the device corresponding to the key includes one or more signatures based on one or more certificates of one or more devices from which the secret information corresponding to the key is received.

11. The method of claim 10, further comprising verifying the received secret information corresponding to the key based on the one or more signatures contained in the secret information.

12. The method of claim 11, wherein, as part of the verification, the method further comprises querying a server managing device certificates to determine whether the one or more signatures contained in the secret information corresponding to the key are valid.

13. The method according to claim 11, wherein, As part of the verification, the method further includes determining the validity of the secret information corresponding to the key based on a list obtained from the distributed ledger and one or more signatures contained in the secret information corresponding to the key.

14. The method of claim 1, further comprising: Receive a request from another device; The request is verified based on the device's internal policy; as well as When the request is determined to be valid, the internal key information is sent to the other device.

15. The method of claim 14, further comprising: Use region information to verify the request; as well as If the area information indicates that the other device is not located in an area where data encrypted by the key can be accessed, the request is determined to be invalid.

16. The method of claim 13, wherein the list is a certificate revocation list, and the apparatus determines that the secret information corresponding to the key is invalid if one or more certificates are indicated as invalid in the certificate revocation list.

17. A method executed by a server, comprising: A circuit system is used to perform a verification process to verify the one or more devices based on identity information corresponding to the one or more devices, wherein at least one of the security license of the one or more devices, the financial information of the one or more devices, or the residential information of the one or more devices is verified during the verification process; After successfully verifying the one or more devices, the circuit system generates one or more pseudonyms for the one or more devices; The circuit system generates one or more certificates for the one or more devices, the one or more certificates containing the one or more pseudonyms and license levels of the one or more devices; and The circuit system is used to distribute the one or more certificates to the one or more devices.

18. The method of claim 17, further comprising: Maintain the area information corresponding to the one or more devices; as well as The region information is inserted into the one or more certificates before they are distributed to the one or more devices.

19. The method of claim 18, further comprising uploading the region information to a distributed ledger accessible by the one or more devices.

20. The method of claim 17, further comprising: The maintenance instructions are distributed to the revocation status of the one or more certificates of the one or more devices in the certificate revocation list; as well as The certificate revocation list is provided to the one or more devices.

21. The method of claim 20, wherein providing the certificate revocation list to the one or more devices comprises uploading the certificate revocation list to a distributed ledger accessible by the one or more devices.

22. A data security protection system, comprising: The first device is configured as follows: The data is encrypted using a key and then transmitted over a network to a data storage device. A secret share is generated based on the key, and The secret sharing is distributed to multiple terminals via the network using a multi-party computational view. The second device is configured to: Generate certificates corresponding to the plurality of terminals, each of which includes a pseudonym of the corresponding terminal among the plurality of terminals and verifies communication from the corresponding terminal among the plurality of terminals without disclosing the identity of the corresponding terminal among the plurality of terminals. The certificate is distributed to the multiple terminals via the network; and The plurality of terminals, each of the plurality of terminals, is configured to: Store one of the secret shares distributed by the first device. A request is generated to be signed by the corresponding one of the certificates distributed by the second device. The request may be transmitted anonymously to one or more of the plurality of terminals. Anonymously receive one or more responses from the plurality of terminals, the one or more responses comprising one or more of a secret share distributed by the first device. The key is reconstructed using one or more of the secret shares, and The encrypted data stored in the data storage device is accessed using the key.

23. The data security protection system according to claim 22, wherein each of the plurality of terminals is further configured to: Receive a request from another of the plurality of terminals. The validity of the request is determined based on the certificate contained in the request, which corresponds to another of the plurality of terminals. After confirming the request is valid, the corresponding secret is shared and sent to the other of the plurality of terminals.

24. The data security protection system of claim 22, wherein the plurality of terminals communicate via a distributed ledger.

25. The data security protection system according to claim 22, wherein... The second device is configured to maintain a revocation list indicating the validity of the certificates corresponding to the plurality of terminals, and Each of the plurality of terminals is configured to query the second device to determine whether a certificate contained in communication from another of the plurality of terminals is valid. The second device responds to the query based on the cancellation list.

Images