Secure secret recovery

Abstract

To provide data processing systems and methods for securely recovering a secret key.SOLUTION: In a secure secret key reconstruction method 300, a replacement key unit detects a failed key unit, initiates key reconstruction, receives fingerprints of encrypted key slices, and determines whether the received fingerprints match the group authority (GA)'s stored fingerprints; if the received fingerprints match the GA's stored fingerprints, then the GA key is transmitted to the replacement key unit, a new GA key is generated, the new GA key is transmitted to the replacement key unit, and the fingerprints are received from the replacement key unit and stored.SELECTED DRAWING: Figure 3

Description

Technical Field

[0001] The present invention generally relates to secure secret recovery in a data processing system.

Background Art

[0002] Secrets and access control are utilized across a wide variety of computer systems. Secrets can include confidential data such as encryption keys. Secrets are protected in various ways, but two of the more well-known methods are hashing and encryption. Both of these involve converting the secret into an essentially unreadable "ciphertext", but hashing is typically one-way (a hashed secret cannot be feasibly recovered, but can be compared to another hashed secret), while encryption is typically reversible (an encrypted secret can be "decrypted", but usually only when using a specific "key", enabling the recovery of the secret by a user with the encryption key). Thus, these methods have different use cases. For example, password systems typically use hashing (a website that stores a hashed password can check whether a user has entered their correct password, but the website cannot determine the user's "actual" password), while data that may need to be reused frequently typically uses encryption (communications, data storage, etc.).

[0003] There are many different encryption algorithms, but the general commonality among them is the use of one or more "keys". An encryption key is a unique data string used as input to an encryption function. To encrypt a secret, this secret is input into the encryption function along with the unique key, resulting in an encrypted output composed of ciphertext. This ciphertext appears essentially random, but it can be decrypted by inputting the ciphertext and the same encryption key (in the case of a "symmetric key" encryption system) or a different "decryption key" (in the case of "asymmetric key" encryption) into a decryption function (which is directly related to the encryption function used to encrypt the secret). Knowledge of which encryption function was used can often be empirically determined by an external user, and thus the protection of the encryption key is of utmost importance in protecting the secret. In some systems, it is often possible to encrypt the encryption key itself using different encryption functions (and different encryption keys). Some forms of encryption can decrypt a secret using any one of a predetermined number of keys. This can be made possible by storing multiple copies of the same secret, each encrypted with a different key.

[0004] Secrets such as encryption keys are generally stored securely to prevent their misuse. However, this often comes with a trade-off of reduced fault tolerance. If a secret is stored securely on a single drive, a failure of that drive can render the secret irrecoverable. If the secret is a storage encryption key (which controls the encryption of data stored in a storage system), losing the key can result in losing the data or losing access to the data (which may be functionally equivalent to losing the data itself in the absence of the key). Many systems have backups of secrets as an attempt to mitigate this, but simple backups have their own trade-offs. They can serve as additional attack vectors. For example, there is a risk that the backup itself may be illegally accessed by an attacker instead of the actual secret.

Summary of the Invention

[0005] A method according to one aspect of the present invention includes receiving a first encrypted slice from a first key unit and a second encrypted slice from a second key unit. The method also comprises receiving a group authority key from the group authority. The method also comprises decrypting the first encrypted slice and the second encrypted slice using the group authority key. The method also comprises reconstructing a secret based on the first decrypted slice and the second decrypted slice. The method advantageously enables secure recovery of the secret by requiring both multiple slices from multiple key units and a key from the group authority.

[0006] In an embodiment of the present invention, the method comprises generating a first fingerprint of the encrypted first slice and a second fingerprint of the encrypted second slice, and transmitting the first fingerprint and the second fingerprint to the group authority, wherein the step of receiving the group authority key is performed in response to the group authority verifying the first fingerprint and the second fingerprint. This advantageously provides additional security and verification to the secure secret recovery process by requiring the group authority to verify the slices via the fingerprints (without exposing the slices themselves to the group authority).

[0007] In an embodiment of the present invention, the method further comprises slicing the reconstructed secret into a first new slice and a second new slice; encrypting the first new slice and the second new slice; transmitting the encrypted first new slice to the first key unit; and transmitting the encrypted second new slice to the second key unit. Thereby, advantageously, new slices of the reconstructed secret can be distributed between key units, providing additional security (e.g., in the case of a component failure. In other situations, the reconstructed secret may be lost). Further, the distributed slices are encrypted again, further improving the security for the technology.

[0008] In an embodiment of the present invention, the method comprises obtaining a secret, receiving a group authority key from group authorities, and generating a plurality of encrypted slices of the secret based on the group authority key. Thereby, advantageously, it becomes possible to set up a system that can securely reconstruct the stored secret.

[0009] Another aspect of the present invention is a computer program product comprising a computer-readable storage medium, the computer-readable storage medium having program instructions embodied thereby, the program instructions being executable by a computer to cause the computer to execute either the method discussed above or the method claimed below. Thereby, advantageously, it becomes possible to securely recover the secret, requiring both a plurality of slices from a plurality of key units and a key from group authorities.

[0010] Another aspect of the present invention provides a system comprising a memory and a central processing unit (CPU). The CPU is configured to execute instructions for performing either the method discussed above or the method claimed below. Thereby, advantageously, it becomes possible to securely recover a secret, requiring both a plurality of slices from a plurality of key units and a key from group authorities.

[0011] The above summary is not intended to describe every illustrated embodiment or every implementation of the present disclosure. **Brief Description of the Drawings**

[0012] The drawings included in this application are incorporated herein and form a part hereof. They illustrate embodiments of the present disclosure and, together with the description, serve to explain the principles of the present disclosure. The drawings merely illustrate particular embodiments and do not limit the present disclosure. The features and advantages of various embodiments of the claimed subject matter will become apparent when reading the following detailed description of the invention and referring to the drawings. In the drawings, like numerals indicate like parts.

[0013]

Figure 1

[0014]

Figure 2

[0015]

Figure 3

[0016]

Figure 4

[0017]

Figure 5

[0018]

Figure 6

[0019]

Figure 7

[0020]

Figure 8

[0021]

Figure 9

[0022]

Figure 10

[0023] While the present invention is capable of various modifications and alternative forms, specific examples thereof are shown by way of illustration in the drawings and are described in detail. However, it should be understood that the intention is not to limit the present invention to the specific embodiments described. In contrast, the present invention is intended to cover all modifications, equivalents, and alternative forms included within the scope of the present invention.

Best Mode for Carrying Out the Invention

[0024] Aspects of the present disclosure relate to systems and methods for securely recovering a private key. More particular aspects relate to systems for determining that a key unit containing a private key has failed, rebuilding the private key using components stored in other key units, and enabling a replacement key unit to decrypt the rebuilt private key.

[0025] Systems and methods consistent with the present disclosure advantageously improve fault tolerance while minimizing security costs. In essence, secrets may be stored in an encrypted state, and rather than simply using a backup of the secret, the secret is “sliced” into multiple “slices” (parts or fragments), each of which is encrypted and stored by a separate “key unit”. The encrypted slices cannot be (practically) decrypted without keys provided by group authorities that oversee the various key units. Thus, in the event of a failure of a key unit storing a secret, the secret can be recovered with minimal security risk. This provides several advantages. For example, in the event of a failure of a key unit storing a storage encryption key, it may not be necessary to completely rebuild the storage system from a backup (a process that may take weeks or longer for larger storage systems), and instead, a system consistent with the present disclosure can rebuild the “lost” storage encryption key and regain useful control of the storage system and its data. Further, all of this can be done without incurring the risk of exposing the storage key to other key units or even to group authorities, and thus it may not be necessary to (immediately) change the storage key when it is rebuilt.

[0026] Throughout this disclosure, reference is made to "keys" such as "storage keys", "group authority keys", and "user keys". These designations are used for illustrative purposes only, and as will be understood by those skilled in the art, keys may be used for other purposes. In particular, a "storage key" is used as merely one example of a "securely stored secret" that is made securely recoverable by this disclosure. Other possible examples include communication keys, confidential data, and the like. Similarly, the term "key unit" is used as an illustrative example, but the same concept may more generically be simply referred to as a "unit".

[0027] Throughout this disclosure, reference is made to "slices". In particular, slices of secrets (such as storage keys) may be encrypted and distributed among multiple units of a group. A slice described as being "stored" in a unit is stored in encrypted form within the slice storage of that unit. A slice is encrypted by the unit that performed the initial slicing. A slice is encrypted using a special encryption key provided by group authority.

[0028] While most examples of the present disclosure refer to each unit storing a single encrypted slice of a secret, in some embodiments, a unit may store multiple slices. For example, in a group of four units, the secret S of the first unit may be sliced into slices s1, s2, and s3. In some embodiments, the second unit may store slice s1, the third unit may store slice s2, and the fourth unit may store s3, such that if a failure occurs in the first unit, the replacement unit can still receive all the slices and thus (assuming the other conditions described below are met) recover the secret S. However, in some embodiments, the second unit may store slices s1 and s2, the third unit may store s2 and s3, and the fourth unit may store s3 and s1. In this way, each slice is stored in at least two units, and thus, for example, if failures occur in both the first unit and the second unit, all the slices can still be recovered, and thus the secret S can still be reconstructed. This provides redundancy and, more advantageously, can improve fault tolerance in some systems. Further, this allows for comparing the slices to determine whether the slices of a single unit differ from "copies" of these slices stored in other units, enabling determination of whether a unit has been illegally accessed by a malicious actor or is otherwise damaged.

[0029] To enable reconstruction of the secret regardless of which unit (or, optionally, in embodiments where multiple units) fails, the slices of the secret may be distributed among the units. In some embodiments, to enable verification of the stored slices, a unit may also store parity data.

[0030] Secrets may initially be obtained from system operators (e.g., engineers who installed the key unit), hardware (which may be randomly generated), etc. In some embodiments, the secrets may be derived from information from group permissions. When it is necessary to reconstruct the secrets, new units may be added to the group (often referred to herein as "replacement key units"). When adding a new unit, the group permissions may verify its identification information (e.g., by certificate exchange / check). This new unit can receive a slice of the secret from the remaining units once it proves its identification information to the group permissions. Since the slice is encrypted by units other than the unit storing the slice (and uses a key controlled by the group permissions), the unit storing the slice may not be able to decrypt them.

[0031] In some embodiments, the key units may be organized into "groups", each group containing a set of n key units (where n >= 1). For example, group authorities may create a group of n key units prior to operation of the system. Each group may be managed by different group authorities such as GA110 in FIG. 1, although in some embodiments, a group authority may manage more than one group. However, for ease of explanation, only a single group of key units is described in detail herein. It may be beneficial for the GA to be a PKI certification authority to facilitate authentication of the identification information of system components. The GA may determine which set of key units belong to a particular group and may facilitate this by creating a certificate of group membership. The key units may then join the group. It may be beneficial for the key units to be proven to behave appropriately according to secure secret recovery requirements. This may be done by the manufacturer using serial numbers, certificates, signed codes, etc. This may help prevent malicious actors from joining the group (via "rogue" key units). For example, in some embodiments, the GA may be able to provide a manifest (optionally as a blockchain) that identifies the key units and the key units can be checked to match the manifest. In some embodiments, more than one group authority may share control of a group.

[0032] Throughout the present disclosure, mention is made of communications between, for example, key units and group authorities that issue group authority keys to key units, or between users, group authorities, etc., or both. To improve the security of messages, transport encryption may be used for such communications in a manner well known to those of ordinary skill in the art.

[0033] Figure 1 shows a high-level block diagram of an exemplary recoverable secure secret system 100 that conforms to some embodiments of the present disclosure. System 100 includes a group authority (GA) 110, key units including key unit U1 121, key unit U2 122, and key unit U3 123 (collectively "key units 121-123"), and storage units including storage unit 107, storage unit 108, and storage unit 109 (collectively "storage units 107-109"). GA 110 is responsible for determining the overall system configuration. GA 110 includes a set of GA keys 101, 102, and 103 (described in more detail below) used to protect information in the key units. GA 110 also includes fingerprint storage 114.

[0034] Storage units 107-109 store encrypted data using keys that are secret to users 104-106 and GA 110. Storage encryption keys 141, 142, and 143 (collectively "storage encryption keys 141-143" or "storage keys 141-143") are stored in key units 121-123. A particular storage encryption key may be stored in only one of the plurality of key units. Further, key units 121-123 may be constructed such that storage encryption keys 141-143 cannot be extracted from key units 121-123 (e.g., a given storage encryption key cannot be read by any entity other than the key unit storing it). Storage encryption keys 141-143 are stored in an encrypted state within key access control units 131-133.

[0035] The storage keys 141-143 may be encrypted with different user keys, such that a single user key (not shown in FIG. 1) may be able to decrypt only one storage key. For example, storage key 141 may be encrypted by a first user key and stored within key access control unit 131, storage key 142 may be encrypted by a second user key and stored within key access control unit 132, and storage key 143 may be encrypted by a third user key and stored within key access control unit 133, etc.

[0036] In some embodiments, each user of system 100 is provided with one or more “user keys” configured to decrypt a particular storage key, which is described in further detail below with reference to FIGS. 5 and 6.

[0037] As shown, key units 121-123 each store one of key access control units 131-133. However, in some embodiments not shown in FIG. 1, some key units may include multiple key access control units each storing a storage key. This may be particularly advantageous to provide a particular user with a more granular access to a particular storage key. This is described in further detail below with reference to FIGS. 5 and 6.

[0038] The key units 121 - 123 also include key slice storages 161 - 163 that enable a key unit to store slices of storage keys from other key units. For example, key slice storage 161 enables key unit 121 to store slice 172 of storage key 142 and slice 183 of storage key 143. Similarly, key storage 162 enables key unit U2 to store slice 173 of storage key 143 and slice 181 of storage key 141, while key storage 163 enables key unit 123 to store slice 182 of storage key 142 and slice 171 of storage key 141. During the process of creating a key unit (e.g., key unit 121) having a storage key (e.g., storage key 141), the key unit may slice the storage key into two or more slices (e.g., slices 171 and 181) by means of a slicing / reconstruction function. The key unit may then encrypt this slice using one or more group authority keys (e.g., GA keys 101 - 103). In some embodiments, each slice is encrypted with a different GA key. Once the slice is encrypted, the key unit may generate a fingerprint for the encrypted slice. The key unit may then send the fingerprint to the group authority to be stored in fingerprint storage 114.

[0039] In some embodiments, a key unit may store key slices in a storage unit. For example, key unit 121 may store key slices 172 and 183 in storage 107. When storing key slices, the key unit may encrypt them using the storage key held by the key unit (e.g., key unit 121 may encrypt key slices 172 and 183 using storage key 141 and store them in storage 107).

[0040] The storage key can be recovered (e.g., from a failed key unit) by the reconstruction function slicing the key into m slices, where m < n (and n = the number of units in the group), encrypting the slices, and sending the encrypted slices to different key units. The slices may be encrypted using one or more GA keys (e.g., GA keys 101 - 103) provided by the GA110. For example, in some embodiments, each key unit slices its storage key into m slices, encrypts each slice, and sends one slice to each other key unit. Thus, each key unit may receive m encrypted slices (each slice being a slice of a different key). In some embodiments, a key unit may include more than one storage key, and thus may send m slices for each storage key (so some key units may receive more than m slices).

[0041] In some embodiments, the GA keys sent to each key unit are different. The use of GA keys means that it is necessary to possess m slices, but it is not sufficient to recover the secret key. This means that, barring the situation of "key unit failure", malicious actors accessing key units illegally and reducing the risk of naturally recovering the key advantageously improves the security of system 100 over the prior art (such as Shamir's secret sharing which only requires a quorum). Even if a key unit has obtained m slices of the key, without the correct GA key from the GA, the key unit cannot decrypt the slices (and thus cannot recover the key). Thus, even if an actor can access one GA key (such as the GA key previously used by the illegally accessed key unit to encrypt its own slice), without the remaining GA keys, the key still cannot be reconstructed.

[0042] In some embodiments, GA110 provides different GA keys to each slice. For example, when m = 2, GA110 may provide key 101 to the first slice 171 and key 102 to the second slice 181. The number of slices m may depend on the number of key units n in the group and the characteristics of the erasure code or error correction code used to protect the slices. In some embodiments, parity may be included to verify the integrity of the slices.

[0043] For example, the key group may include n = 5 key units, and the storage key w is recoverable if there are additional missing key units (e.g., one of the five key units may be faulty). Thus, to create a code with n - 1 elements, the code may have m = 3 slices and one parity calculated from these slices. The slices are encrypted with keys from GA110 that are not available to the set of remaining key units, so the secret is protected from ownership of the m slices by units other than those with the appropriate authorization (such as replacement key units added to replace faulty key units). Further, the keys from GA110 are required to recover the secret key.

[0044] As an example, when encoding the new secret key 141 of the key unit 121, the group authority GA110 may distribute the GA keys 101 to 103 to the key unit 121. The reconstruction function 116 of the key unit 121 may slice the storage key 141, encrypt each slice with a different one of the GA keys 101 to 103, and then calculate a fingerprint for each such encrypted slice. These fingerprints may be returned to GA110 and stored in the fingerprint storage 114. The encrypted slices may then be transmitted to the other key units 122 and 123. For example, the key unit 122 may receive the encrypted slice 171, while the key unit 123 may receive the encrypted slice 181. Also, the key units may utilize the reconstruction function to perform erasure encoding / error correction encoding and slice distribution.

[0045] During the recovery operation (e.g., when a failure occurs in the key unit 121, thereby losing the storage key 141), GA110 may require proof that the replacement key unit (not shown in FIG. 1) has all the key slices necessary to rebuild the storage key 141 before transmitting the GA keys necessary to decrypt the slices. This may be accomplished by the replacement key unit receiving the encrypted key slices 171 and 181 from the key units 122 and 123, respectively. The replacement key unit may then verify the slices (by the fingerprints that GA110 compares with the fingerprint storage 114), and then GA110 may transmit the GA keys necessary to decrypt the slices 171 and 181 to the replacement key unit. Upon receiving the keys, the replacement key unit may decrypt the slices and reconstruct the secret key 141.

[0046] In some embodiments, rather than slicing the key and then encrypting the slices, the key may be encrypted (and fingerprinted) before being sliced. For example, in some embodiments, the key unit 121 receives the GA key 101, encrypts the storage key 141 with the GA key 101, generates a fingerprint of the encrypted key (e.g., by a hash function), and may transmit the fingerprint to the GA110. The GA110 may store the fingerprint of the encrypted key, and then the key unit 121 may slice the encrypted key into slices 171 and 181 and distribute them to the key units 123 and 122 respectively. When reconstructing the key, the replacement key unit receives the encrypted slices, reassembles them into the encrypted key, generates a verification fingerprint of the encrypted key, and may transmit the fingerprint to the GA110. The GA110 may verify the fingerprint and return the appropriate GA key 101 to enable the replacement key unit to decrypt and recover the key. Thereby, the complexity of the system 100 may be reduced and the storage overhead may be reduced (because the GA110 only needs to store one fingerprint of the entire encrypted key instead of fingerprints of each encrypted slice).

[0047] Figure 2 is a high-level secure secret key reconstruction method 200 that uses the "encrypt-after-slicing" technique, which is consistent with some embodiments of the present disclosure. The method 200 may be executed by a system, such as the system 100 of FIG. 1, configured to enable secure secret reconstruction. The method 200 may be executed in response to, for example, a failure occurring in the key unit or an audit being initiated. The method 200 includes, in operation 202, receiving encrypted slices of a key. Operation 202 may be executed, for example, by a substitution key unit. Operation 202 may include receiving encrypted slices of the secret key from other key units within the system. In some embodiments, operation 202 may also include receiving one or more parity keys from key units within the system. In some embodiments, operation 202 may include receiving one of each slice of the secret key. In some embodiments, operation 202 may include receiving all slices of the secret key except one, together with parity keys, to enable reconstruction of the missing slice.

[0048] The method 200 further includes, in operation 204, verifying the slices. Operation 204 may include, for example, generating a fingerprint of the encrypted slice and comparing this fingerprint with a stored fingerprint. For example, the key unit may utilize a hash function such as Secure Hash Algorithm (SHA)-256 or may generate a checksum. The key unit may generate a fingerprint and transmit the fingerprint to the group authority. In some embodiments, the group authority may compare the received fingerprint with the stored fingerprint to determine whether the encrypted slice is valid. While the present disclosure focuses on the use of fingerprint verification, other techniques for proving ownership of a secret, including "zero-knowledge" proofs, may also be used.

[0049] Method 200 further includes, at operation 206, decrypting a slice. Operation 206 may include decrypting the slice, for example, using one or more group authorization keys. The group authorization may confirm (e.g., after operation 204) that the fingerprint of the encrypted slice is valid, and then the group authorization may transmit the group authorization key to the key unit. When the group authorization key is received, the key unit uses this group authorization key to decrypt the slice. In some embodiments, different group authorization keys may be used for each slice. In some embodiments, a single group authorization key may be used for multiple (or even all) slices.

[0050] Method 200 further includes, at operation 208, reconstructing a key. Operation 208 may be performed by a replacement key unit. The replacement key unit may input the decrypted slice of the storage key into a reconstruction function and instead receive the storage key. Note that the unencrypted storage key is not output / returned to, or accessible by, entities external to the key unit that reconstructed the storage key.

[0051] When operation 208 is complete, the storage key has been reconstructed, and preparations for use in the storage operation may be complete without the need to rebuild the storage unit. Advantageously, this can reduce the downtime that would otherwise occur due to a failure of the key unit. Operations 210 and 212 allow the system to prepare for subsequent recovery (e.g., if a subsequent failure occurs in the replacement unit itself). In particular, this reconstruction of the storage key enables the information stored in the storage unit to be protected while it is encrypted with the storage key. Thus, the reconstructed data is encrypted with the storage key and is therefore kept secure. Rebuilding the data by other means requires protection (e.g., RAID) that allows access to the unencrypted data, which is generally not as secure.

[0052] Method 200 further includes, in operation 210, distributing a new slice of the newly reconstructed storage key. Operation 210 may be performed by a replacement key unit. Operation 210 may include, for example, slicing the storage key into a plurality of slices. The number of slices (m) may be based on the number of key units (n) within the group. For example, in some embodiments, m = n - 1. However, in some embodiments, the key may be sliced into fewer slices, in which case the slices are sent to more than one key unit (advantageously, redundancy is improved). The group authority may generate a new set of group authority keys and send this new GA key to the replacement key unit. The key unit may then encrypt the new slice using the new GA key. In some embodiments, each slice may be encrypted using a different GA key. In some embodiments, the GA key may be used for more than one slice. When all slices are encrypted, the replacement key unit may send the encrypted slices to other key units in the group. The new encrypted slices may be stored in the slice storage of the other key units and replace the slices received in operation 202.

[0053] Method 200 further includes, in operation 212, updating the fingerprint based on the new slice. Operation 212 may include, for example, the key unit generating a fingerprint of the newly encrypted slice. Operation 212 further includes sending the fingerprint to the group authority. The group authority may store the new fingerprint in the fingerprint storage unit and replace the previously stored fingerprint that was checked in operation 204.

[0054] In some embodiments, the order of operations 204-208 may be different. For example, the order shown in FIG. 2 may be utilized in a "slice then encrypt" scheme. However, in some embodiments, the key may be encrypted before being sliced (referred to as an "encrypt then slice" embodiment). In such embodiments, the verification fingerprint may be generated based on the entire encrypted key rather than on each individual slice. For example, in some embodiments, after receiving the encrypted slices in operation 202, the slices may be assembled into a (still encrypted) key, a fingerprint of the encrypted key may be generated and verified, and the key may be decrypted using the group authority key. In such embodiments, operation 210 may include encrypting the recovered key with the new GA key, then slicing the newly encrypted key and distributing the slices. A high-level, exemplary encrypt then slice embodiment is described below with reference to FIG. 7. FIG. 2 shows a system-level flowchart of secure secret key reconstruction operations. FIGS. 3 and 4 show more detailed flowcharts of operations performed by the group authority and replacement key units, respectively.

[0055] Figure 3 is an exemplary secure secret key reconstruction method 300 from the perspective of group permissions, which is consistent with some embodiments of the present disclosure. Method 300 may be executed by group permissions such as GA110 in FIG. 1, for example. Method 300 includes, in operation 302, detecting a key unit that has malfunctioned. Operation 302 may include, for example, determining that the key unit is no longer responsive, receiving an indicator that a malfunction has occurred in the key unit, etc. The key units communicate with each other and can use techniques such as heartbeat detection to check whether other units are kept in a responsive state. Power outages often occur temporarily and these should be distinguished from real malfunctions. Consensus means that a small number of units (possibly including the GA and any users) determine that they cannot reach the key unit for some duration. In some embodiments, the operator may be notified to demonstrate whether the problem lies with the key unit or elsewhere. In some embodiments, the group permissions may consider only the "malfunctioned" unit if the remaining units agree.

[0056] Method 300 further includes, in operation 304, starting key reconstruction. Operation 304 may include, for example, identifying a replacement key unit and sending a signal to the key unit group indicating that the replacement key unit is scheduled to reconstruct the malfunctioned key unit. In some embodiments, the replacement key unit may be manually installed by a technician, for example. In some embodiments, the key unit group may include a "standby" or "backup" replacement key unit, in which case operation 304 may include starting up or otherwise activating the backup replacement key unit. Upon the start of operation 304, the replacement key unit can request and receive an encrypted key slice from other active key units, which will be discussed in more detail below with reference to method 400 in FIG. 4.

[0057] Method 300 further includes, at operation 306, receiving a fingerprint of the encrypted key slices. These fingerprints may be received, for example, from a replacement key unit. In some embodiments, operation 306 includes receiving fingerprints of all encrypted slices of the key to be reconstructed. In some embodiments, the slices may be combined before decryption, and operation 306 includes receiving a single fingerprint of the encrypted key.

[0058] Method 300 further includes, at operation 308, determining whether the received fingerprint matches a stored fingerprint of the group permissions. For example, the group permissions may maintain a set of verification fingerprints in a fingerprint storage (such as the fingerprint storage 114 of FIG. 1). At operation 308, by determining whether the fingerprints match, the group permissions may be able to determine whether the replacement key unit has obtained all slices, and whether the replacement key unit has any expired or otherwise damaged slices. This may be useful for detecting fraudulent requests for key reconstruction.

[0059] The group permissions that execute method 300 may store multiple fingerprints. For example, in some embodiments, the fingerprint storage of the group permissions may include fingerprints of all slices of all storage keys within the group. As will be understood by those skilled in the art, the fingerprint storage may further include a data structure or other means for mapping which fingerprint corresponds to which slice of which key.

[0060] If the fingerprint received in operation 306 does not match the stored fingerprint (the "no" in 308), the group authority executing method 300 may return an error in operation 310. In some embodiments, operation 310 may further include generating an alert signal or otherwise indicating that the reconstruction attempt has failed due to a slice fingerprint mismatch.

[0061] If the fingerprint received in operation 306 matches the stored fingerprint of the GA (the "yes" in 308), method 300 further includes, in operation 312, transmitting the group authority key to the replacement key unit. Operation 312 may include identifying or otherwise selecting the GA key (stored by the group authority) required to decrypt the encrypted slice. For example, in some embodiments, each slice may be encrypted only with a different GA key. By transmitting the appropriate key, the replacement key unit can decrypt the slice and thus reconstruct the storage key of the failed key unit. In particular, the storage key is reconstructed by the replacement key holder without any other entity (such as group authority, user, another key unit, etc.) having access to the storage key. Further, the key cannot be reconstructed without both the slice from another key unit and the key from the group authority, which advantageously increases security.

[0062] Method 300 further includes, in operation 314, generating a new GA key. Operation 314 may enable the encryption of the newly generated slice of the storage key to create a new unique encrypted slice (which may then be distributed by the replacement key unit to other key units). Similar to the previous key, the group authority may generate a new GA key for each slice. Method 300 further includes, in operation 316, transmitting the new GA key to the replacement key unit.

[0063] Upon receiving a new GA key, the replacement key unit can encrypt a new slice, and in turn generate a new fingerprint for this newly encrypted slice. Method 300 may further include, at operation 318, receiving and storing the fingerprint of the new encrypted key slice. Operation 318 may include receiving the fingerprint from the replacement key unit and storing the fingerprint in the group authority's fingerprint storage. In some embodiments, the group authority may overwrite an existing fingerprint associated with the storage key reconstructed by the replacement key unit.

[0064] FIG. 4 is an exemplary secure secret key reconstruction method 400 from the perspective of a replacement key unit, consistent with some embodiments of the present disclosure. Method 400 may be an example of a "slice then encrypt" regime, as shown in FIG. 4, but may also be modified to enable embodiments of "encrypt then slice". Method 400 may be executed by a replacement key unit included in or added to a group of key units. The replacement key unit may be similar to one of the key units 121-123 of FIG. 1, and may be added when a failure occurs in an existing key unit or otherwise activated. Method 400 includes, at operation 402, receiving an instruction to reconstruct a key from group authority (such as GA110 in FIG. 1, etc.). The GA may issue these instructions in response to detecting that a failure has occurred in the group's key unit (as discussed with reference to FIG. 5).

[0065] Method 400 further includes, at operation 404, receiving an encrypted slice of the secure private key from another key unit. Operation 404 may include, for example, requesting a slice corresponding to the lost key (of the key unit in which the failure occurred) from each of the remaining key units in the group. For example, if a failure occurs in unit 122 of FIG. 1 (when access to storage key 142 is lost), a replacement key unit (not shown in FIG. 1) may request a slice of key 142 from units 121 and 123. The replacement key unit may then receive encrypted key slice 172 from key unit 121 and encrypted key slice 182 from key unit 123. In some embodiments, operation 404 may further include receiving one or more parity keys, whereby the replacement key unit may be enabled to generate the missing encrypted key slice.

[0066] Method 400 further includes, at operation 406, sending a fingerprint of the encrypted key slice to group authority. Operation 406 may include, for example, generating a fingerprint of the key slice received at operation 404. The fingerprint may be generated using a reconstruction function of the replacement key unit (similar to reconstruction functions 116, 118, 120 of FIG. 1). Once generated, the fingerprint may be sent to a group authority such as GA110. Thereby, the group authority can compare the fingerprint with a stored fingerprint to verify that the replacement key unit has the appropriate slice.

[0067] Method 400 may further include, in operation 408, receiving one or more group authority keys from group authority. In some embodiments, the replacement key unit may receive GA keys for each slice. In some embodiments, GA keys may be received for more than one slice. If the fingerprint transmitted in operation 406 does not match the fingerprint in the GA fingerprint store, GA may reject the transmission of the GA key and the reconstruction may fail. Depending on the embodiment, the drive may still be rebuilt using conventional methods. However, this may require a protection / backup system (e.g., RAID) to be calculated for unencrypted data and is generally considered less secure.

[0068] Method 400 may further include, in operation 410, decrypting the slices with the group authority key and reconstructing the storage key. Operation 410 may be performed by the reconstruction function of the replacement key unit. The group authority may specify which GA key should be used with which encrypted slice. Once the slices are decrypted, they may be gathered again to form the original storage key. Once the storage key is reconstructed, access to the storage unit associated with the storage key may be performed and normal operation may resume. However, by operations 412 - 420, the system may further be able to recover from potential future failures of the replacement key unit by setting new slices and fingerprints.

[0069] Method 400 further includes, in operation 412, receiving a replacement GA key from GA. Once the storage key is reconstructed, GA may generate new encryption keys that are used to encrypt the slices of the storage key in a new way. These new GA keys are then transmitted to the replacement key unit.

[0070] Method 400 further includes, in operation 414, generating new slices of the reconstructed key. Operation 414 may be performed by the reconstruction function of the replacement key unit.

[0071] When a replacement GA key is received (operation 412) and a new slice is generated (operation 414), method 400 further includes, at operation 416, encrypting the new slice using the replacement GA key. With the new GA key, the replacement key unit may be able to encrypt the slice in a different manner than the previous slice (i.e., the slice received at operation 404). Also, operation 416 may be performed by a reconstruction function of the replacement key unit.

[0072] Method 400 further includes, at operation 418, sending the fingerprint of the new (encrypted) slice to the group authority. Operation 418 may include, for example, using a reconstruction function of the replacement key unit to generate the fingerprint of the encrypted slice and sending that fingerprint to the group authority. GA may replace the previously stored fingerprint with the newly generated fingerprint.

[0073] Method 400 further includes, at operation 420, sending the new encrypted slice to other key units. If there are more other key units than slices, operation 420 may further include selecting the key unit that transmits the slice. In some embodiments, operation 420 may include sending the slice to the key unit that was the source of the previous slice received by the replacement key unit (at operation 404). This may advantageously make it possible to keep the distribution of key slices in a relatively less changing state.

[0074] In particular, the failed key unit may have included slices of other keys stored in other key units. Thus, when the failed key is recovered by the replacement key unit, (either in one order or the other depending on whether the system implements a "slice then encrypt" or an "encrypt then slice" approach) the keys of the other key units may be re-sliced and re-encrypted, and the encrypted slices may be redistributed. In some embodiments, all the stored slices across the group of key units may be replaced in this way. In some embodiments, only the slices stored by the failed key unit may be regenerated and sent to the replacement key unit. To achieve this, the key units of the group may utilize the same slicing arrangement ("symmetric arrangement"). Thus, if the first unit is notified that a second unit has failed, the first unit may be able to determine which of its key slices were stored in the second unit. In an asymmetric arrangement, group authority may instead track this information.

[0075] In some embodiments, before transmitting the new encrypted slices, the key unit may calculate a cyclic redundancy check (CRC) for each slice and transmit it along with the slice itself. When a slice is received, the CRC may be recalculated and checked to detect whether the slice is damaged.

[0076] In some embodiments, rather than (or in addition to) the key unit generating a new slice (operation 414), the key unit may add some other information, such as a timestamp, a sequence number, or a nonce, to an "old" slice (i.e., the slice decrypted in operation 410). When encrypted and fingerprinted (operations 416 and 418), the additional information causes the fingerprint to be different. This can provide security against an attacker who attempts to "collect" old slices over time and ultimately enable key reconstruction (because thanks to the additional information, the old slices will still have different fingerprints). This can provide additional security, and the system can securely reuse the old slices rather than generating new slices upon recovery.

[0077] In some embodiments, some of the operations of method 400 may be performed in a different order. For example, rather than slicing the key and then encrypting the slices (such as operations 414 - 416), the system may encrypt the key and then slice the encrypted key.

[0078] FIG. 5 is a diagram illustrating a high - level secure secret - key operation method 500 consistent with some embodiments of the present disclosure. Method 500 describes the overall operation of a system such as system 100 of FIG. 1. Method 500 may be performed by a key unit that communicates with a user and a storage device or system. For example, method 500 may be performed by key unit 121 (which communicates with the user and storage system 107).

[0079] Method 500 includes, at operation 502, receiving a request and a user key from a user. While method 500 describes reading data from a storage system, as will be understood by those skilled in the art, method 500 may be modified to enable writing data to storage. Operation 502 may include, for example, receiving a read request regarding data stored in a storage system. The key unit also receives a user key for decrypting a storage key stored (in encrypted state) within the key unit. Operation 502 may also include performing an authentication procedure (as part of establishing a secure communication link in many cases).

[0080] Method 500 further includes, at operation 504, determining whether the user key can access the use of the key by the key unit (such as by decrypting the storage key). If the user key does not decrypt the storage key, the user may not be able to access the storage key (the "no" of 504), and as a result, the request will be rejected at operation 506. Operation 506 may include returning an error message to the requesting user. The error message may indicate that the user cannot access the storage system or the storage key.

[0081] If the user key can decrypt the storage key (the "yes" of 504), method 500 further includes, at operation 508, searching for the requested (encrypted) data from storage. The storage key is then decrypted by the user key at operation 510, and the decrypted storage key is used to decrypt the data retrieved at operation 512. Method 500 further includes, at operation 514, transmitting the requested data to the user in response to the request.

[0082] In some embodiments, test data chunks are generated, stored in storage (by the modified method 500), and encrypted by a storage key (or by a test key generated by encrypting the storage key using an attestation key stored by group permissions or by a key unit holding the storage key of the test subject), and group permissions may attest to the storage key. The fingerprint of the data can be stored in the group permission fingerprint storage. At a later time, the group permissions can cause the key unit to decrypt the data, generate a new fingerprint, and send the new fingerprint to the group permissions. If the fingerprints do not match, the storage key may have been changed. This may be particularly advantageous for demonstrating whether reconstruction was successful.

[0083] FIG. 6 is a block diagram showing a system 600 including a more detailed exemplary key unit 621, including a plurality of key access control units 631, 632, 633, 634, and 635, and storage keys 641 and 642, consistent with some embodiments of the present disclosure. The key unit 621 may be part of a larger group of key units (not shown in FIG. 6). FIG. 6 also shows a user 601 (having a user key 611), a user 602 (having a user key 612), and a user 603 (having a user key 613). In essence, to allow multiple users to access the same storage key, the key unit 621 may include multiple copies of the storage key, each encrypted using a different key. In this way, multiple users (each having their own user key) may be allowed to access the same key without compromising security, regardless of how the key is stored.

[0084] If the user desires to access the storage 608, the user submits the user key to the key unit 621. The user key is then submitted to the encryption / decryption function of one of the key access control units (represented as the padlocks 651, 652, 653). For example, the encryption / decryption function 651 of the key access control unit 631 may be decrypted with the user key 611, while the encryption / decryption function 652 of the key access control unit 632 may be decrypted with the user key 612. In particular, both the key access control unit 631 and the key access control unit 632 store an encrypted copy of the same storage key 641. (Since the user key 611 can only decrypt the padlock 651) For example, the copy is simply encrypted in a different manner so that the user key 611 cannot access the key access control unit 632.

[0085] Furthermore, the key access control unit 633 may include a different storage key 642, but it is encrypted (padlock 651) so that the user key 611 cannot decrypt it. Similarly, the key access control unit 634 may include a second encrypted copy of the storage key 642 by encryption 652, and the key access control unit 635 may include a third encrypted copy of the storage key 642 by encryption 653 that can be decrypted by the user key 613. This may mean, for example, that two users may be able to access the storage key 641, while three users may be able to access the storage key 642.

[0086] The key unit 621 also includes the slice storage 660 shown in FIG. 6 for including a plurality of slices 661, 662, 663, and 664 of different keys (collectively "slices 661 to 664"). The slices 661 to 664 may correspond to slices of different keys securely stored from other key units within the same group. The slices 661 to 664 are stored in an encrypted state and may be transmitted to the replacement key unit upon request from the group authority.

[0087] The key unit 621 is connected to a storage system 608 that includes one or more storage devices. Data transmitted to and received from the storage system 608 may be encrypted / decrypted by one of the storage keys 641 or 642.

[0088] When the key unit 621 is first initialized, the storage keys 641 and 642 are sliced by a reconstruction function. The slices are then encrypted using one or more group permission keys received from group permissions (not shown in FIG. 6) and may be distributed among other key units within a group (not shown in FIG. 6) for secure storage.

[0089] FIG. 7 is a diagram illustrating a high-level secure secret key reconstruction method 700 using an "encrypt-then-slice" technique, consistent with some embodiments of the present disclosure. The method 700 may be performed by a system configured to enable secure secret reconstruction, such as the system 100 of FIG. 1, for example. The method 700 may be performed in response to a failure occurring in a key unit, an audit being initiated, etc. The method 700 includes, in operation 702, receiving encrypted slices of a key. Operation 702 may be performed, for example, by a replacement key unit. Operation 702 may include receiving encrypted slices of a secret key from other key units within a key group or within the system. In some embodiments, operation 702 may also include receiving one or more parity keys from key units within the system. In some embodiments, operation 702 may include receiving one of each slice of the secret key. In some embodiments, operation 702 may include receiving all slices of the secret key except one slice, along with parity keys, to enable reconstruction of the missing slice.

[0090] Method 700 further includes, in operation 704, the step of collecting encrypted slices into an encrypted key. Operation 704 may include, for example, the step of reading one or more tags of each slice to determine an appropriate order in which to arrange them to collect the slices into an encrypted key. In particular, the key unit may be able to collect the encrypted key, but on the other hand, without the appropriate group authority key, the key cannot be decrypted (and thus recovered). The group authority may require the key unit to prove that the encrypted key collected by the key unit is the correct key.

[0091] Method 700 further includes, in operation 706, the step of verifying the fingerprint of the encrypted key. Operation 706 may include, for example, the step of generating a fingerprint of the encrypted key and comparing this fingerprint with a stored fingerprint. For example, the key unit may utilize a hash function such as Secure Hash Algorithm (SHA)-256 or may generate a checksum. The key unit may generate a fingerprint and transmit the fingerprint to the group authority. In some embodiments, the group authority may compare the received fingerprint with the stored fingerprint to determine whether the encrypted key is valid (e.g., to confirm whether the re-collected encrypted key is the same as the previously sliced encrypted key being reconstructed). In particular, the encrypted key itself may not need to be transmitted to the group authority. Instead, it may only be necessary to receive a hash of the encrypted key. In this way, not even the group authority can obtain the key.

[0092] Method 700 further includes decrypting the key in operation 708. Operation 708 may include decrypting the collected encrypted keys, for example, using a group authority key. If the group authority confirms that the fingerprint of the encrypted key is valid (e.g., after operation 706), the group authority may transmit the group authority key to the key unit. When the group authority key is received, the key unit uses this group authority key to decrypt the key. In particular, the group authority may include (or be capable of generating / acquiring) a plurality of different group authority keys. The key unit can decrypt the key only with the appropriate key. Based on, for example, the result of fingerprint comparison (the stored fingerprint may be used as an index for an array of group keys), a specific request (the key unit may explicitly declare that it is attempting to reconstruct a specific storage key or may request a specific group authority key), etc., the group authority may determine which key to transmit to the key unit.

[0093] In some embodiments, the encrypted slices considered throughout this disclosure may be encoded into an error correction code (such as an erasure code) to create a second set of slices. The code used may be any type of error correction code (e.g., 3 + P, Tornado code, Reed Solomon code, etc.), including codes having multiple parities.

[0094] In some embodiments, even in the "encrypt - then - slice" approach, a fingerprint may be generated for each encrypted slice and transmitted to the group authority. This may enable the group authority to detect whether the key unit has modified the slice (which could be evidence of a malicious attacker or corruption). The error correction code can also detect and correct such modifications (up to a power of the code).

[0095] This disclosure includes a detailed description of cloud computing, but it is understood that the implementations of the teachings described herein are not limited to cloud computing environments. Rather, embodiments of the present invention can be implemented in conjunction with any other type of computing environment, whether currently known or developed in the future.

[0096] Cloud computing is a service delivery model that enables convenient on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services), which can be rapidly provisioned and released with minimal management effort or interaction with a service provider. This cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

[0097] The characteristics are as follows.

[0098] On-demand self-service: Cloud consumers can provision computing capabilities, such as server time and network storage, automatically and on their own, without the need for human interaction with a service provider.

[0099] Broad network access: The functions are available via the network, and access to the functions is through standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0100] Resource pooling: Pool the provider's computing resources to provide services to multiple consumers using a multi-tenant model. Multiple different physical and virtual resources are dynamically allocated and reallocated according to demand. Consumers generally have no control or knowledge of the exact location of the resources provided, but there is location independence in that it may be possible to specify the location at a higher level of abstraction (e.g., country, state, or data center).

[0101] Rapid adaptability: Functions can be provisioned quickly and adaptively, sometimes automatically, to scale out quickly and released quickly to scale in. For consumers, there often appears to be an unlimited amount of functionality available for provisioning and it can be purchased in any quantity at any time.

[0102] Measured services: Cloud systems automatically control and optimize resource usage by leveraging a metering function at an appropriate level of abstraction for the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported to provide transparency to both the provider and consumer of the services utilized.

[0103] The service model is as follows.

[0104] Software as a Service (SaaS): The functionality provided to consumers is to use the provider's applications running on cloud infrastructure. This application is accessible from various client devices through a client interface such as a web browser (e.g., web-based email). Consumers do not manage or control the underlying cloud infrastructure, which includes the network, servers, operating system, storage, or even individual application functionality. However, limited user-specific application configuration settings may be an exception.

[0105] Platform as a Service (PaaS): The functionality provided to consumers is to deploy the applications created or acquired by consumers, which are created using programming languages and tools supported by the provider, onto cloud infrastructure. Consumers do not manage or control the underlying cloud infrastructure, including the network, servers, operating system, or storage, but control the deployed applications and, in some cases, the configuration of the application hosting environment.

[0106] Infrastructure as a Service (IaaS): The functionality provided to consumers is to provision processing, storage, network, and other basic computing resources, and consumers can deploy and run any software that can include an operating system and applications. Consumers do not manage or control the underlying cloud infrastructure, but control the operating system, storage, deployed applications, and, in some cases, limitedly control selected network-forming components (e.g., host firewall).

[0107] The deployment models are as follows.

[0108] Private cloud: The cloud infrastructure is operated solely for one organization. It may be managed by the organization or a third party and may exist on-premises or off-premises.

[0109] Community cloud: The cloud infrastructure is shared by several organizations and supports a specific community with common concerns (e.g., mission, security requirements, policies, and regulatory compliance considerations). It may be managed by the organization or a third party and may exist on-premises or off-premises.

[0110] Public cloud: The cloud infrastructure is made available to the general public or a large industry group and is owned by an organization that sells cloud services.

[0111] Hybrid cloud: The cloud infrastructure remains a distinct entity but is a composition of two or more clouds (private, community, or public) linked together by standard or proprietary technologies that enable portability of data and applications (e.g., cloud bursting for load distribution between clouds).

[0112] Cloud computing environments are service-oriented, focusing on statelessness, low coupling, modularity, and semantic interoperability. The core of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0113] Referring now to FIG. 8, an exemplary cloud computing environment 800 is shown. As shown, cloud computing environment 800 includes one or more cloud computing nodes 810 with which local computing devices used by cloud consumers, such as, for example, a personal digital assistant (PDA), or cellular telephone 840A, desktop computer 840B, laptop computer 840C, or automotive computer system 840N, or a combination thereof, can communicate therewith. Nodes 810 may communicate with each other. They may be physically or virtually grouped in one or more networks such as the private cloud, community cloud, public cloud, or hybrid cloud described above, or a combination thereof (not shown). Thereby, cloud computing environment 800 can provide infrastructure, platform, software, or a combination thereof, as services such that a cloud consumer need not maintain resources on a local computing device. The types of computing devices 840A - 840N shown in FIG. 8 are only intended to be exemplary, and it should be understood that cloud computing nodes 810 and cloud computing environment 800 can communicate with any type of computerized device via any type of network or network addressable connection or both (e.g., using a web browser).

[0114] Referring now to FIG. 9, a set of functional abstractions provided by cloud computing environment 800 (FIG. 8) is shown. It should be understood in advance that the components, layers, and functions shown in FIG. 9 are only intended to be exemplary and that embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functions are provided.

[0115] The hardware and software layer 960 includes hardware components and software components. Examples of hardware components include mainframe 961, RISC (Reduced Instruction Set Computer) architecture-based server 962, server 963, blade server 964, storage device 965, and network and network-forming components 966. In some embodiments, the software components include network application server software 967 and database software 968.

[0116] The virtualization layer 970 provides an abstraction layer from which the following examples of virtual entities may be provided: virtual server 971, virtual storage 972, virtual network 973 including a virtual private network, virtual applications and operating systems 974, and virtual client 975.

[0117] In one example, the management layer 980 may provide the functions described below. Resource provisioning 981 provides for the dynamic procurement of computing resources and other resources utilized to execute tasks within a cloud computing environment. Metering and pricing 982 provides for cost tracking when resources are utilized within a cloud computing environment and for invoicing or billing for the consumption of these resources. In one example, these resources may include application software licenses. Security provides for the authentication of cloud consumers and task identification information and for the protection of data and other resources. User portal 983 provides access to the cloud computing environment for consumers and system administrators. Service level management 984 provides for the allocation and management of cloud computing resources such that required service levels are met. Service level agreement (SLA) planning and fulfillment 985 provides for the preparation and procurement of cloud computing resources for which future requirements are anticipated in accordance with the SLA.

[0118] The workload layer 990 provides examples of functions that can utilize a cloud computing environment. Examples of workloads and functions that may be provided from this layer include mapping and navigation 991, software development and lifecycle management 992, virtual classroom education delivery 993, data analysis processing 994, transaction processing 995, and secure secret recovery 996.

[0119] Referring now to FIG. 10, a high-level block diagram of an exemplary computer system 1000 is shown that may be configured to execute various aspects of the present disclosure, including, for example, methods 200, 300, 400, 500, or 700, or combinations thereof. The exemplary computer system 1000 may be used in implementing one or more of the methods or modules described herein, and any associated functions or operations, according to embodiments of the present disclosure (e.g., using one or more processor circuits or computer processors of a computer). In some embodiments, the main components of the computer system 1000 may include one or more CPUs 1002, a memory subsystem 1008, a terminal interface 1016, a storage interface 1018, an I / O (input / output) device interface 1020, and a network interface 1022, all of which may be communicatively coupled directly or indirectly for component-to-component communication via a memory bus 1006, an I / O bus 1014, and an I / O bus interface unit 1012.

[0120] Computer system 1000 may include one or more general-purpose programmable central processing units (CPUs) 1002, some or all of which may include one or more cores 1004A, 1004B, 1004C, and 1004D, collectively referred to herein as CPU 1002. In some embodiments, computer system 1000 may include multiple processors typical of relatively large-scale systems. However, in other embodiments, computer system 1000 may alternatively be a single CPU system. Each CPU 1002 may execute instructions stored in memory subsystem 1008 on CPU core 1004 and may include one or more levels of on-board cache.

[0121] In some embodiments, memory subsystem 1008 may include random access semiconductor memory, a storage device, or storage media (either volatile or non-volatile) for storing data and programs. In some embodiments, memory subsystem 1008 may represent all of the virtual memory of computer system 1000 and may also include the virtual memory of other computer systems coupled to computer system 1000 or connected via a network. Memory subsystem 1008 may conceptually be a single monolithic entity, but in some embodiments, memory subsystem 1008 may be a more complex arrangement, such as a hierarchy of caches and other memory devices. For example, the memory may exist at multiple levels of cache, and these caches may be further divided by function, such that one cache holds instructions while another cache holds non-instruction data used by one or more processors. As is known in any of various so-called non-uniform memory access (NUMA) computer architectures, the memory may be further distributed and associated with different CPUs or sets of CPUs. In some embodiments, main memory or memory subsystem 804 may include elements for the control and flow of memory used by CPU 1002. This may include memory controller 1010.

[0122] Memory bus 1006 is shown in FIG. 10 as a single bus structure that provides a direct communication path between CPU 1002, memory subsystem 1008, and I / O bus interface 1012. However, in some embodiments, memory bus 1006 may be arranged in various forms, such as a hierarchical configuration, a star configuration, or a web configuration of point-to-point links, multiple hierarchical buses, parallel and redundant paths, or any other suitable type of configuration, and may include multiple different buses or communication paths that can be arranged in any of a variety of forms. Further, while I / O bus interface 1012 and I / O bus 1014 are shown as single respective units, computer system 1000 may, in some embodiments, include multiple I / O bus interface units 1012, multiple I / O buses 1014, or both. Further, while multiple I / O interface units that separate I / O bus 1014 from various communication paths to various I / O devices are shown, in other embodiments, some or all of the I / O devices may be directly connected to one or more system I / O buses.

[0123] In some embodiments, computer system 1000 may be a multi-user mainframe computer system, a single-user system, or a server computer or similar device that has little or no direct user interface but receives requests from other computer systems (clients). Further, in some embodiments, computer system 1000 may be implemented as a desktop computer, a portable computer, a laptop or notebook computer, a tablet computer, a pocket computer, a telephone, a smartphone, a mobile device, or any other suitable type of electronic device.

[0124] Note that FIG. 10 is intended to show representative major components of an exemplary computer system 1000. However, in some embodiments, individual components may have more or less complexity than shown in FIG. 10, components other than or in addition to those shown in FIG. 10 may exist, and the number, type, and configuration of such components may vary.

[0125] The present invention may be a system, method, or computer program product, or a combination thereof, at any possible technical detail level of integration. The computer program product may include a computer-readable storage medium having computer-readable program instructions for causing a processor to implement aspects of the present invention.

[0126] A computer-readable storage medium can be a tangible device that can hold and store instructions for use by an instruction execution device. The computer-readable storage medium can be, for example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof, but is not limited thereto. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, punch card, or mechanically encoded devices such as raised structures within grooves in which instructions are recorded, and any suitable combination thereof. A computer-readable storage medium, as used herein, should not be construed to be a transient signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., an optical pulse passing through an optical fiber cable), or an electrical signal transmitted through a wire.

[0127] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to respective computing devices / processing devices, or may be downloaded from an external computer or an external storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface of each computing device / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions for storage on a computer-readable storage medium within each computing device / processing device.

[0128] The computer-readable program instructions for carrying out the operation of the present invention may be source code or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuits, or object-oriented programming languages such as Smalltalk® and C++, and procedural programming languages such as the "C" programming language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer as a stand-alone software package, may be executed partially on the user's computer, may be executed partially on the user's computer and partially on a remote computer, or may be executed entirely on a remote computer or server. In the latter situation, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection to an external computer may be made (e.g., via the Internet using an Internet service provider). In some embodiments, an electronic circuit, including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may execute the computer-readable program instructions by utilizing the state information of the computer-readable program instructions to personalize the electronic circuit for performing aspects of the present invention.

[0129] Aspects of the invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer readable program instructions.

[0130] These computer readable program instructions may be provided to a computer processor or other programmable data processing apparatus to produce a machine, such that the instructions executed by the computer processor or other programmable data processing apparatus create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions for implementing the function / act specified in the flowchart and / or block diagram block or blocks.

[0131] Also, the computer readable program instructions may be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to produce a computer implemented process, such that the instructions executed on the computer, other programmable apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0132] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagram may represent a module, segment, or portion of instructions that include one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions noted in the blocks may be performed in an order other than that noted in the figures. For example, two blocks shown in succession may in fact be implemented as one step, may be executed simultaneously, may be executed substantially simultaneously, may be executed in a partially or wholly temporally overlapping manner, or the blocks may be executed in the reverse order depending on the functionality involved. It is also noted that each block of the block diagram or flowchart diagram, or combinations of blocks of the block diagram or flowchart diagram, or both, may be implemented by a dedicated hardware-based system that performs the specified function or operation, or may be implemented by a combination of dedicated hardware and computer instructions.

[0133] The descriptions of the various embodiments of the present disclosure have been presented for purposes of illustration, but are not intended to be exhaustive or limiting of the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope of the described embodiments. The terms used herein were chosen to explain the principles of the embodiments, actual application, or technical improvements over technologies found in the marketplace, or to enable other ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. 1. A system comprising: Memory, a central processing unit (CPU) coupled to the memory, the CPU comprising: instructions for determining that a key unit storing a secret has been compromised, the key unit being included in a group; instructions for receiving a fingerprint of the encrypted key slice from the replacement key unit; instructions for verifying the received fingerprint, the verifying including comparing the received fingerprint with a stored fingerprint stored in a fingerprint storage; instructions for transmitting one or more stored group authority keys to the replacement key unit in response to said verifying; A CPU configured to execute A system comprising:

2. The CPU, adding the replacement key unit to the group; The system of claim 1 , further configured to verify an identity of the replacement key unit.

3. The CPU, generating one or more new group authority keys; 3. The system of claim 1, further configured to transmit the one or more new group authority keys to the replacement key unit.

4. The CPU, receiving a new fingerprint from the replacement key unit; The system of claim 2 , further configured to store the new fingerprint in a fingerprint store.

5. 5. A system according to claim 1, wherein the group authority is a certification authority.

6. The system of claim 1 , wherein the secret is a storage encryption key.

7. On the computer, The procedure for obtaining the secret, receiving one or more group authority keys from a group authority; generating a plurality of encrypted slices of said secret based on said one or more group authorization keys; A computer program for execution.

8. The computer generating one or more fingerprints based on the private key; transmitting said one or more fingerprints to said group authority; The computer program product of claim 7 , further comprising:

9. the one or more group authority keys consist of a single group authority key; generating the plurality of encrypted slices, encrypting said secret using said single group authority key; Slicing the encrypted secret; 9. A computer program according to claim 7 or 8, comprising:

10. generating the plurality of encrypted slices, slicing the secret into a number of slices; encrypting the plurality of slices using the one or more group authority keys; 10. A computer program according to any one of claims 7 to 9, comprising:

11. 11. The computer program product of claim 7, further comprising the step of: transmitting the encrypted slices to a number of key units.

12. The computer includes: generating a second plurality of slices based on the plurality of encrypted slices and an error correction code; transmitting the second plurality of slices to a plurality of key units; 12. The computer program product of claim 7, further comprising:

13. The computer includes: receiving a first encrypted slice from a first key unit and a second encrypted slice from a second key unit; storing the first encrypted slice and the second encrypted slice; receiving a request from the group authority to transmit the second encrypted slice to a substitution key unit; transmitting the second encrypted slice to the substitution key unit in response to the request; 13. A computer program product according to any one of claims 7 to 12, further comprising:

14. The computer includes: receiving a replacement slice from the replacement key unit; replacing the first encrypted slice with the replacement slice; The computer program product of claim 13 , further comprising:

15. The computer includes: receiving one or more new group authority keys from the group authority; generating one or more new encrypted slices of the secret based on the one or more group authorization keys; transmitting at least one of the one or more new encrypted slices to the replacement key unit; The computer program product of claim 14 , further comprising:

Images