Restoration of Scattered Keys from Backup Storage

Abstract

A method for restoring a distributed private key from backup storage is disclosed. An original private key is generated and distributed to two or more servers. A first server creates a backup containing at least the first server's shares of the original private key. Each server refreshes the original private key at least once. During each refresh, the server generates a refreshed distributed private key and a distributed difference between the previous private key and the refreshed private key. Each server generates a secret version of the difference share to share with at least some of the other servers. Each server generates an accumulated secret version of the difference share received from the other servers based on the received secret version of the difference share and the previous accumulated secret version. The first server restores the original private key share from the backup, requests the accumulated secret version of the difference share from the other servers, and restores the latest refreshed private key share from the received accumulated secret version and the restored share of the original private key.

Description

Technical Field

[0001] Technical Field to Which the Invention Belongs The present invention relates to a method for restoring a secret key distributed from a backup storage. According to the method of the present invention, even when the distributed secret key is refreshed several times after backup creation, the secret key can be restored safely.

Background Art

[0002] Background of the Invention In a threshold encryption scheme or a threshold signature scheme, the secret key may be distributed among two or more servers such that each server holds at least one share of the secret key and no single server has access to all the shares and thus the entire secret key. When encrypting, decrypting, or signing using the key, in order to enable a transaction, at least a predefined number of subsets of servers need to participate. Therefore, an adversary needs to expose multiple servers in order to access a sufficient number of key shares to perform an improper signature, encryption, or decryption that meets the threshold criteria.

[0003] Each server is desirably to create a backup of the share of the secret key at appropriate time intervals. The backups are independent and each server does not necessarily need to create a backup at the same time. If a server fails and it is necessary to restore the content including the share of the secret key from the backup, this server is restored but the other servers are not affected.

[0004] In the case of a long-term secret key, for example, a secret key that is secretly shared over a long period of time, an adversary may gradually gain access to a sufficient number of key shares and be able to use the secret key illegally. To avoid this, the secret key, and thus the key shares, may sometimes be refreshed. Therefore, it is not only necessary for the adversary to gain access to a sufficient number of key shares. Also, the adversary needs to access the key shares within the same time period while the secret key is refreshed twice. This is sometimes referred to as "proactive secret sharing."

[0005] However, if the secret key is refreshed more than once from the time the backup is created until the time when it is necessary to restore the key shares from the backup, the key shares obtained from the backup will become invalid because they are different from the currently applicable key shares.

Summary of the Invention

Problems to be Solved by the Invention

[0006] An object of an embodiment of the present invention is to provide a method for restoring a distributed secret key from a backup storage that can restore a refreshed secret key without compromising the confidentiality of the secret key.

[0007] A further object of an embodiment of the present invention is to provide a method for restoring a distributed secret key from a backup storage, the method being capable of restoring a refreshed secret key while maintaining proactive secrecy.

Means for Solving the Problems

[0008] The present invention provides a method for restoring a distributed secret key from a backup storage, the method comprising: Generating an original secret key and distributing the original secret key to two or more servers, wherein each server holds a share of the original secret key thereby, and no server holds all shares of the original secret key; The first server creating a backup, the backup including at least the share of the original secret key held by the first server; The server refreshing the original at least once, each refresh including: Each server generating a refreshed distributed secret key and a distributed difference between the previous secret key and the refreshed secret key, each server holding a share of the distributed difference, the distributed difference constituting a zero sharing, and the server discarding the share of the previous secret key; Each server generating a secret version of the share of the distributed difference and sharing the secret version with at least a portion of the other servers; Each server generating a cumulative secret version of the share of the distributed difference received from the other servers based on the received secret version of the share of the distributed difference and the previous cumulative secret version; including the refreshing step; The first server restoring the share of the original secret key from the backup and requesting the cumulative secret version of the share of the distributed difference distributed to the other servers; At least a portion of the other servers providing the cumulative secret version of the share of the distributed difference of the first server among the distributed differences of the first server; The first server restoring the share of the latest refreshed secret key from the received cumulative secret version and the restored share of the original secret key; including.

[0009] Accordingly, the method according to the present invention is a method for restoring a distributed secret key from backup storage. The secret key may be, for example, a secret encryption / decryption key or a secret signature key, i.e., a secret key applied to generate a digital signature.

Brief Description of the Drawings

[0010] The present invention will now be described in more detail with reference to the accompanying drawings.

[0011]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Embodiments for Carrying Out the Invention

[0012] An object of an embodiment of the present invention is to provide a method for restoring a distributed secret key from backup storage that can restore a refreshed secret key without compromising the confidentiality of the secret key.

[0013] A further object of embodiments of the present invention is to provide a method for restoring a distributed secret key from backup storage, which can restore a refreshed secret key while maintaining proactive secrecy.

[0014] The present invention provides a method for restoring a distributed secret key from backup storage, the method comprising: generating an original secret key and distributing the original secret key to two or more servers, each server thereby holding a share of the original secret key such that no single server holds all shares of the original secret key; a first server creating a backup, the backup including at least the share of the original secret key held by the first server; the servers refreshing the original at least once, each refresh comprising: each server generating a refreshed distributed secret key and a distributed difference between the previous secret key and the refreshed secret key, each server holding a share of the distributed difference, the distributed difference constituting a zero sharing, and the server discarding the share of the previous secret key; each server generating a secret version of the share of the distributed difference and sharing the secret version with at least a portion of the other servers; each server generating a cumulative secret version of the share of the distributed difference received from the other servers based on the received secret version of the share of the distributed difference and the previous cumulative secret version; the refreshing step including; a first server restoring the share of the original secret key from the backup and requesting the cumulative secret version of the share of the distributed difference distributed to the other servers; At least a portion of another server provides a cumulative secret version of the share of the first server among the distributed differences of the first server; The first server restores a share of the latest refreshed secret key from the received cumulative secret version and the restored share of the original secret key; and includes.

[0015] Therefore, the method according to the present invention is a method for restoring a distributed secret key from backup storage. The secret key may be, for example, a secret encryption / decryption key or a secret signature key, that is, a secret key applied to generate a digital signature.

[0016] According to this method, the original secret key is generated and distributed to two or more servers, but each server holds a share of the original secret key so that no server has all the shares of the secret key. Therefore, no server can reconstruct the entire original secret key, and thus at least a subset of a predefined number of servers must participate in order to use the original secret key. The secret key may be first generated and then distributed among the servers, or the servers may cooperate to directly generate the secret key in a distributed form, for example, using secret sharing.

[0017] The servers may be separate hardware servers physically separated from each other. As an alternative, the servers may be in the form of virtual servers and do not necessarily have to be located on separate hardware. However, the servers are separated from each other in the sense that no server can access the content stored on other servers.

[0018] After generating the original secret key, the first server creates a backup. Since the first server holds the first share of the original secret key, this first share of the original secret key is included in the created backup. The backup of the first server is performed independently of the backups of other servers.

[0019] At some point after the backup is created, each server refreshes the original secret key at least once. Each refresh is performed in the manner shown below.

[0020] First, the server generates a refreshed distributed secret key and a distributed difference between the previous secret key and the refreshed secret key. The refreshed distributed secret key and / or the distributed difference may be generated in the same manner as the method by which the original secret key was generated. This will be explained in more detail below. In any case, each server will hold a share of the refreshed secret key and a share of the distributed difference. Further, no server holds all the shares of the refreshed secret key, and no server holds all the shares of the distributed difference. Thus, no server can reconstruct the entire refreshed secret key or the entire distributed difference by itself.

[0021] In this specification, the term "previous secret key" should be interpreted to mean the distributed secret key that is valid at the time when the refresh is performed. Thus, when the first refresh is performed, the previous secret key is the original secret key. When the second refresh is performed, the previous secret key is the refreshed secret key generated at the first refresh of the secret key, etc.

[0022] At this time, the distributed difference becomes zero sharing. As a result, the refreshed secret key becomes identical to the previous secret key, and thus the original secret key, in the sense that the difference between the distributed secret keys becomes zero. However, the share of the secret key held by the server after key refresh is not the same as the share of the secret key held by the server before key refresh.

[0023] After the refreshed secret key is generated and distributed to each server, each server discards the individual shares of the previous secret key. As a result, the previous secret key is discarded, and the refreshed distributed secret key becomes the valid version until the next refresh is performed. Furthermore, no access can be made to any of the shares of the previous secret key, and accordingly, the entire previous secret key cannot be constructed.

[0024] Furthermore, each server generates a secret version of the share of the difference and shares that secret version with at least some of the other servers. The secret version can be, for example, an encrypted version of the share of the difference. Alternatively or additionally, the server may distribute the share of that share of the difference among the other servers, in which case the secret version may be in the form of a sharing of the secret of the share. In any case, the server only publishes the secret version of the share of the difference to the other servers, and only a predetermined server can reconstruct the share of the difference from the secret version. Therefore, no server can know the actual share of the difference held by the other servers from the received secret version. Therefore, an adversary who has accessed the share of the previous distributed secret key and the secret version of the share of the difference cannot reconstruct the corresponding share of the refreshed distributed key.

[0025] Finally, each server generates a cumulative secret version of the difference shares received from other servers based on the cumulative secret version of the difference shares received from other servers and the previous cumulative secret version. In this way, the cumulative secret version of the difference shares represents the respective differences between the shares of the original distributed secret key and the currently valid shares of the refreshed secret key. The cumulative secret version may be generated in various ways. This will be explained in more detail below.

[0026] When the distributed secret key is refreshed multiple times in the above manner, an incident occurs at the first server that requires the first server, and thus the share of the distributed secret key held by the first server, to be recovered. However, the share of the distributed key stored in the backup storage is the share of the original distributed secret key, and since the distributed secret key has been refreshed at least once after the backup was created, the original secret key is no longer valid, and the currently valid share of the secret key held by the first server cannot be directly restored from the backup immediately.

[0027] Therefore, the first server restores the share of the original secret key, i.e., the actually usable share, from the backup and requests the cumulative secret version of the difference shares from other servers.

[0028] In response to this request, at least some of the other servers provide the first server with the accumulated secret version of the share of the difference of the first server. In some embodiments, only one of the other servers may provide the accumulated secret version, and in other embodiments, two or more of the other servers may provide the accumulated secret version. Thus, the first server is now in a state of owning its share of the original secret key, the secret representation of the difference between the share of the first server of the original secret key and the share of the first server of the currently valid secret key. However, since only the accumulated secret version is provided to the first server, no server has any knowledge of the share of the first server of the intermediate version of the refreshed secret key.

[0029] Finally, the first server restores the share of the latest refreshed secret key, i.e., the currently valid secret key, from the received accumulated secret version and the restored share of the original secret key. As described above, the accumulated secret version represents the difference between the share of the first server of the original secret key and the share of the first server of the currently valid secret key, i.e., the share of the latest refreshed secret key. Thus, the first server can derive this difference from the received accumulated secret version, whereby the first server can easily reconstruct the share of the latest refreshed secret key from the original share and the derived difference.

[0030] In this way, the method according to the present invention enables an independent backup of the share of the secret key of the threshold key system, maintains high security in the sense that the risk of leakage of the secret key is low, frequently refreshes the distributed secret key, and enables the reliable restoration of the share of the key from the backup.

[0031] In particular, the restoration of the key share only restores the latest refreshed version of the key share and does not restore potential intermediate refreshed versions, making it impossible for an adversary to access such intermediate refreshed versions. Thereby, after the expiration of the refresh period, the adversary is prevented from collecting a sufficient number of key shares belonging to the same refresh.

[0032] Therefore, the method according to the present invention enables the server to restore its current secret key share from a backup including an old version of the server's key share and the cumulative difference of secrets received by the server from one or more of the other servers. In particular, this method enables the restoration of the share of the first server without giving other servers the ability to restore the secret key share of the first server.

[0033] The step in which each server generates a secret version of the differential share may be performed by an additive homomorphic scheme, and the step in which each server generates a cumulative secret version may be composed of each server adding the received secret version of the differential share to its respective previous cumulative secret version and discarding the previous cumulative secret version.

[0034] The additive homomorphic scheme is a scheme in which addition is possible in the encrypted area, that is, E(d1 + d2) = E(d1) + E(d2), where E means encryption. Thus, when an additive homomorphic scheme is applied to generate a secret version of the differential share, each server encrypts its own share d i and can transfer the encrypted version E(d i ) to other servers. Then, other servers can obtain the encrypted version of the sum of the differential shares simply by adding the encrypted versions.

[0035] Therefore, according to this embodiment, the method may be executed as follows. For simplicity, the method is described from the perspective of the first server, that is, only the shares held by the first server are described. However, it should be noted that other servers may execute similar steps.

[0036] When the first refresh is executed, the first server generates a share, d1, of the difference between the original secret key and the first refreshed secret key. This share of the difference d1 corresponds to the difference between the share of the original secret key held by the first server and the share of the first refreshed secret key held by the first server. Next, the first server encrypts its share d1 using an additive homomorphic scheme, thereby obtaining a secret version E(d1) of the share d1. This secret version E(d1) is transferred to at least one of the other servers. The secret version of this share d1 constitutes the first accumulated secret version A1 = E(d1).

[0037] When the second refresh is executed, the first server similarly generates its share, d2, of the difference between the first refreshed secret key and the second refreshed secret key. As a result, the difference between the share of the original secret key held by the first server and the share of the second refreshed secret key held by the first server is d1 + d2.

[0038] Next, the first server decrypts its share d2 using an additive homomorphic scheme, thereby obtaining the secret version E(d2) of the share d2. The secret version E(d2) is then transferred to at least one of the other servers. In response to receiving the secret version E(d2) of the second share, the other server generates the first server's share of the difference between the original secret key and the second refreshed secret key, the second accumulated secret version A2 of d1 + d2, adds the newly received secret version E(d2) to the previously received secret version E(d1), thereby obtaining A2 = E(d1)+E(d2)=A1 + E(d2). Since E represents an additive homomorphic scheme, the accumulated secret version is actually the accumulated secret version of the difference, i.e., A2 = E(d1)+E(d2)=E(d1 + d2). When the second accumulated secret version A2 is generated, the server discards the first accumulated secret version A1.

[0039] When the third refresh is performed, the above procedure is repeated, generating the third accumulated secret version A3, where A3 = A2+E(d3)=E(d1 + d2 + d3), and discarding the previous accumulated secret version A2.

[0040] By repeating this for each refresh, each server always holds the latest version of the accumulated secret version A n =E(d1 + d2+...+d n ) and does not hold the previously accumulated secret versions.

[0041] If a backup of the first server is required, the first server obtains the share of the original secret key from the backup storage and requests the accumulated secret version of the difference from the other servers. Then, at least one of the other servers provides the currently valid version of the accumulated secret version A n to the first server. And the first server receives the accumulated secret version A nBy decrypting, the actual difference d1 + d2 +... + d between the share of the original secret key for the first server and the share of the currently valid refreshed secret key for the first server can be obtained. n Therefore, the first server can restore the share of the currently valid refreshed secret key by adding the difference accumulated in the restored share of the original secret key. Thus, the share of the currently valid refreshed key is restored without revealing any of the intermediate shares.

[0042] An example of an additive homomorphic scheme is the Paillier public key encryption scheme.

[0043] The additive homomorphic scheme may be a public key encryption scheme, and the step of the first server creating a backup may include storing the private decryption key as part of the backup. According to this embodiment, the secret decryption key is necessary when the first server needs to decrypt the accumulated secret versions received from other servers, but is not necessarily required otherwise. By storing the secret decryption key as part of the backup, it is guaranteed to be difficult for an adversary to access the secret encryption key because access to the backup storage is only required when it is necessary to restore the first server from the backup. On the other hand, in such a situation, the first server obtains the content of the backup storage including the secret encryption key, so that the secret encryption key can be used by the first server to decrypt the received accumulated secret versions as part of restoring the share of the currently valid secret key. When creating a backup, the first server may further delete the secret decryption key from the first server after storing it in the backup storage. Similarly, when restoring the backup, the first server may delete the secret decryption key from the first server after once using the secret decryption key to decrypt the difference of the received secret accumulation versions. This can limit the period during which an adversary who has invaded the first server can access the secret decryption key, thus enhancing security.

[0044] As described above, the present invention has been described from the perspective of an additive secret sharing where the shares of the secret key s satisfy s = s1 + s2 +... + s n and the difference generated in the refresh process was in the form of an additive secret sharing where each server locally adds a zero share to the secret share. In an alternative embodiment, the secret sharing may be multiplicative, i.e., the secret share s satisfies s = s1 * s2 *... * s n and the step of refreshing the secret sharing consists of generating a multiplicative random sharing of 1, multiplying this by the existing secret sharing to generate a refreshed sharing, and each server locally multiplying its share of 1 with the secret share to generate its sharing. In this case, generating the secret version of the difference share may be performed by a multiplicative homomorphism scheme. This may be a public key encryption scheme that is multiplicatively homomorphic, such as the ElGamal encryption scheme.

[0045] In what follows, the additive notation will continue to be used. That is, it will be said that the secret sharing is refreshed by adding a zero sharing and a total of d1 + d2 +... + d n is generated. However, this method also functions similarly in the case of multiplicative secret sharing, where the secret sharing is refreshed by multiplying by a sharing of 1 and a secret version of the accumulated d1 * d2 *... * d n is generated.

[0046] As an alternative strategy, the secret decryption key may be separately stored in external storage such as, for example, cold storage, a hardware secure model (HSM), and / or may be decrypted by an encryption key that is not easily available on the first server or protected by a password. For example, the encryption key or password may be managed by an administrator. In this case, when restoring from a backup, it is necessary to obtain a separate secret decryption key, for example, by requesting the secret encryption key from cold storage, requesting the administrator to decrypt the secret decryption key, or performing decryption of the stored secret version.

[0047] The step in which each server generates a secret version of its share of the difference may include each server creating a sharing of its share of the difference and distributing the shares among at least some of the other servers. The sharing may be in the form of, for example, secret sharing. According to this embodiment, the secret version of the share of the difference is in the form of the created sharing. Thereby, no other server can grasp the whole of the share of the difference. According to this embodiment, when a server receives the share of the first server of the distributed difference, it adds this to the previous share of the share of the first server of the distributed difference to obtain a new accumulated share of the share of the first server of the distributed difference and discards its old share. Creating a sharing in such a way can be applied as an alternative means to the public key encryption scheme described above. As an alternative, these two approaches may be combined in the sense that the shares distributed to other servers are further encrypted.

[0048] Each refresh is a step in which the server creates a zero sharing, each server adds the share of the zero sharing to the share of the previous secret key, thereby creating a refreshed secret key distributed among the servers, and discarding the share of the previous secret key, wherein the zero sharing constitutes a distributed difference, and the discarding step, Each server generates a secret version of the share with zero sharing and shares the secret version with at least some of the other servers, and may include.

[0049] According to this embodiment, the refreshed secret key is generated by the server generating a zero sharing, for example, a zero secret sharing, and then adding this zero sharing to the previous secret key. This is done by each server adding its share of the zero sharing to its share of the previous secret key. Further, according to this embodiment, the distributed difference shares held by the servers are the shares of the zero sharing held by each server.

[0050] As an alternative, the server may generate a refreshed secret key by creating a new sharing of the previous secret key and derive the distributed difference from the shares of the new refreshed secret key and the previous refreshed secret key respectively.

[0051] The method may further include storing the backup in offline storage. According to this embodiment, the backup is not accessible online, and thus an adversary would need to physically penetrate the offline storage to access the backup. The offline storage is in the form of a portable storage medium such as a USB storage or a disk, and may be locked in a secure or separate, restricted area. The location of the offline storage may be different from the location of the server, in which case it is necessary to physically transfer the backup between locations when creating the backup and when the backup needs to be restored. For this reason, creating the backup becomes cumbersome and the backup may not be created very frequently. For this reason, it is expected that the secret key will be refreshed many times between two backups, so the method of the present invention is very meaningful.

[0052] Each step of refreshing the secret key may further include a step in which each server verifies the correctness of the received secret version of the differential share by verifying a zero-knowledge proof.

[0053] Apart from attempting unauthorized access to the secret key, an adversary can also actively try to break the system by providing false information to an honest party, i.e., an honest server. For example, the adversary can damage one of the servers, e.g., the first server. In this case, the differential shares received by the other servers and transmitted from the first server may be damaged. Therefore, there may be a need to be able to detect when one of the parties deviates from a given protocol. According to this embodiment, this is done by verifying a zero-knowledge proof.

[0054] As used herein, the term "zero-knowledge proof" should be construed to mean a method by which one party proves to another party that it knows a secret without revealing details about the secret. Thus, according to this embodiment, the first server actually proves that the secret version of the differential share transferred to the other servers is the actual share's secret version. The first server does this in zero-knowledge, i.e., without revealing details about the actual share. Subsequently, the other server verifies the proof, and if the proof is found to be invalid, the other server can know that the first server is damaged and abort the refresh protocol.

[0055] Alternatively or additionally, the method may further include a step in which the first server verifies the correctness of the received cumulative secret version by verifying a zero-knowledge proof.

[0056] This is the same as the above-described embodiment. However, in this case, it is the first server that guarantees that the accumulated secret version received during restoration from backup is actually correct. Thereby, the first server can detect whether one or more of the other servers are damaged and / or deviate from a predetermined protocol. In this case, the first server can abort the restoration process.

[0057] Alternatively or additionally, each step of refreshing the secret may further include a step of verifying that each server holds the difference of the same secret as other servers, for example, by broadcasting and comparing the difference or the hash digest of the difference. If each server does not agree to hold the same secret difference, the refresh process may be aborted.

[0058] Note that the distributed secret key may be a secret signing key. According to this embodiment, the system is applied to provide digital signatures using the distributed secret key.

[0059] Furthermore, according to this embodiment, the correctness of the difference secret shares and / or the accumulated secret versions may be guaranteed by the server generating a test signature, for example, a threshold signature, and the parties verifying that the test signature is valid and correct.

[0060] As an alternative, the distributed secret key may be a secret encryption key. According to this embodiment, the system is utilized to provide encryption and decryption of data using the distributed secret key.

[0061] In the special case where there are only two servers, the second server already knows the value of its own share and knows that the sum of the two shares is zero, so it already knows that the value of the first server's share is zero. In this case, also, if the secret version and the zero share are generated using encryption, there is no need to use a zero-knowledge proof. Instead, the second server can verify the correctness of the received zero secret share by performing the encryption of the first server's zero share itself and comparing it with the secret version received from the first server. This can be done by using a deterministic encryption scheme or, alternatively, by having the first server reveal to the second server the randomness used to encrypt its zero share.

[0062] This method further includes repeating at least once the step of the first server creating a new backup and the step of the server refreshing the original secret key, and the step of the first server restoring the share of the original secret key may include restoring the share of the secret key saved with the new backup.

[0063] According to this embodiment, the above-described processing is repeated each time a new backup is created, and when restoration from the backup is required, the latest available backup is used. Therefore, the distributed secret key that was valid at the time a new backup was created can be regarded as the original secret key, for example, in the sense of the method of the claims.

[0064] Alternatively or additionally, each refresh may further include the step of the first server generating a cumulative secret version of the difference shares and storing the cumulative secret version at the first server, the secret version of the difference shares forming part of a new backup, and the step of the first server restoring the shares of the most recently refreshed secret key may be performed based on the restored shares of the secret key forming part of the new backup, the cumulative secret version of the accumulated differences forming part of the new backup, and the cumulative secret versions received from at least some of the other servers.

[0065] In some cases, the backup of the server may be executed as an independent autonomous process and may have no correlation with the generation of the distributed secret key. Therefore, the shares of the secret key included in a certain backup may not necessarily match the secret versions of the accumulated difference shares held by other servers in the sense that they cannot easily restore the shares of the most recently refreshed key of the first server based on the shares included in the backup and the accumulated secret versions received from other servers. According to this embodiment, this can be processed as follows.

[0066] Each time there is a refresh, the first server not only generates a cumulative secret version of the difference shares and transmits it to other servers, but also retains the cumulative secret version for its own shares of the accumulated differences, stores this together with the shares of the refreshed secret key that are valid at that time, and deletes the previous version. The cumulative secret version of the differences is preferably such that the individual differences of the accumulated differences cannot be easily derived. For example, this requires that the cumulative secret version of the differences is based on a homomorphic public key encryption that cannot be decrypted by the first server, and for example, the decryption key may be stored in cold storage or a hardware security module (HSM).

[0067] When a new backup is created, the refreshed share of the secret key that is valid at that time and the secret version of the accumulated difference that is valid at that time constitute part of the new backup, i.e., are saved as part of the new backup.

[0068] At a later point in time, if it is necessary to restore the share of the secret key from the backup, the first server restores from the backup the refreshed share that is no longer valid and the secret version of the accumulated difference. Also, the first server receives the secret version of the accumulated difference from at least some of the other servers. Using the homomorphic property of encryption, the first server adds the secret version of the difference from the backup and the secret version of the difference received from at least some of the other servers. This generates a combined secret version of the accumulated difference that is the accumulated difference between the refreshed share from the backup that is no longer valid and the latest refreshed share that the first server wants to restore.

[0069] Next, the first server decrypts this combined secret accumulated difference, for example, by requesting the decryption key of the secret from cold storage, sending the combined secret accumulated difference to a hardware security module (HSM), etc. Next, the first server adds the decrypted accumulated difference to the no-longer-valid share from the backup to restore its latest refreshed version of the share (adding the accumulated difference from the backup returns the share to its creation time, and adding the accumulated difference from the other servers leads to the share from its creation time to the current time).

[0070] Thus, the step of restoring the shares of the original secret key and the step of restoring the shares of the latest refreshed secret key may be performed in one step as described above. Alternatively, these may be performed as separate steps, in which case, the share of the original secret key for the first server is restored by the accumulated differences that form part of the backup, and then, based on the restored original share and the received cumulative secret version, the share of the latest refreshed secret key may be restored in the manner described above.

[0071] Detailed Description of the Drawings FIG. 1 is a diagram for explaining a prior art method for restoring a distributed secret key from backup storage. In the example shown in FIG. 1, the original secret key s is distributed among three servers, namely Server 1, Server 2, and Server 3. Thus, each server holds a share of the secret key, and no single server owns all the shares, and hence the entire key. Thus, Server 1 holds share s1^1, Server 2 holds share s2^1, and Server 3 holds share s3^1. The secret key may alternatively be distributed between two servers or among four or more servers, and it should be noted that the presence of the three servers in FIG. 1 is merely illustrative.

[0072] At time T^1 (which may be immediately after the original secret key is distributed among the servers), Server 1 stores the backup in a cold store. This backup is composed of the share s1^1 of the secret key of Server 1.

[0073] At time T^2, the servers refresh the distributed secret key, and each server holds the share of the refreshed secret key. Thus, Server 1 holds share s1^2, Server 2 holds share s2^2, and Server 3 holds share s3^2, and the previous shares become invalid and are deleted.

[0074] At time T^3, a similarly distributed secret key refresh is performed. As a result, server 1 holds share s1^3, server 2 holds share s2^3, and server 3 holds share s3^3. Note that this refresh process may be repeated multiple times.

[0075] While shares s1^3, s2^3, and s3^3 are valid, data loss occurs on server 1 and restoration from backup is required. However, the key share saved together with the backup is s1^1 which has become invalid instead of the currently valid key share s1^3. Therefore, server 1 cannot restore the currently valid secret key share from the backup.

[0076] FIG. 2 is a diagram for explaining the method according to the first embodiment of the present invention. In FIG. 2, for simplicity, only two servers, server 1 and server 2, are illustrated. However, it should be noted that alternatively, three or more servers may be applied.

[0077] Similar to the prior art method described above with reference to FIG. 1, the secret key is distributed between two servers, and server 1 saves a backup of its share s1^1 in a cold store. However, server 1 also creates a key pair of the secret key sk and the public key pk, and the secret key sk is saved in the cold store together with the backup. This key pair constitutes an additive homomorphic encryption scheme.

[0078] Also, similar to the prior art method described above with reference to FIG. 1, the distributed secret key is refreshed multiple times. In the method shown in FIG. 2, each refresh of the distributed secret key is performed in the following manner.

[0079] The distributed secret keys are refreshed in a standard way, thereby generating refreshed distributed secret keys and the difference between the refreshed secret keys and the previous secret keys, and the difference constitutes zero sharing among the servers. This can be done in at least two ways. The servers generate zero sharing, and each server may add the share of the zero sharing to the share of the previous secret key to thereby obtain the share of the refreshed key. As an alternative, the servers may generate the refreshed key, for example, by creating a new sharing of the previous key, and each server may derive the share of the zero sharing as the difference between the share of the previous secret key and the share of the refreshed secret key.

[0080] In any case, after the first refresh of the secret key, at time T2^, the first server holds the share s1^2 of the refreshed secret key, where s1^2 = s1^1 + d1^1, and here d1^1 is the share of the zero sharing of server 1.

[0081] Next, the first server encrypts the share d1^1 of the zero sharing using the public key of the previously generated key pair, thereby obtaining D^1 = Enc pk (d1^1) and provides D1 to other servers including server 2. The first server further deletes s1^1, d1^1, and sk, whereby sk is stored only in the backup storage.

[0082] Upon receiving D^1, server 2 generates the cumulative version of the received encrypted share of the zero sharing. Since D^1 relates to the first refresh, it is also the first encrypted share received by server 2, and thus the cumulative version is A^1 = D^1 in this case.

[0083] At the next refresh, the first server encrypts the share, D^2 = Enc pk(d1^2) is provided to server 2, and server 2 generates a new accumulated version, A^2 = A^1 + D^2 = D^1 + D^2, and deletes A^1. Further, for each subsequent refresh, server 2 generates a new accumulated version, A^n = A^(n - 1) + D^n = D^1 + D^2 +... + D^(n - 1) + D^n, and deletes the previous accumulated version, A^(n - 1). Since the encryption applied to the zero - sharing shares is performed with an additive - homomorphic encryption scheme, the sum of the encrypted versions is equal to the encrypted version of the sum, i.e., Enc pk (d1^1 + d1^2) = Enc pk (d1^1) + Enc pk (d1^2) = D^1 + D^2. Therefore, the accumulated version held by server 2 corresponds to the encrypted version of the sum of server 1's zero - sharing shares for each refresh performed since the backup was created.

[0084] In the method shown in Figure 2, server 1 experiences data loss that requires restoration from the backup while the share s1^4 of the secret key is valid. Thus, server 1 restores from the backup the share of the original distributed secret key, s1^1 and the secret key sk. Further, server 1 requests the currently valid accumulated version A^4 from other servers, and at least server 2 returns A^4 to server 1.

[0085] Server 1 can decrypt A^4 using the restored secret key sk and obtain the sum of the differences added to the share of server 1 of the original distributed secret key. That is, Dec sk (A^4) = Dec sk (D^1 + D^2 + D^3) = Dec sk (D^1) + Dec sk (D^2) + Dec sk (D^3) = d1^1 + d1^2 + d1^3

[0086] Therefore, server 1 has s1^4 = s1^1 + d1^1 + d1^2 + d1^3 = s1^1 + Dec sk (A^4), so by adding the decrypted accumulated version Dec sk (A^4) to the restored original share s1^1, the valid distributed key share s1^4 can be restored.

[0087] Furthermore, for either of the intermediate refreshed key shares s1^2, s1^3, valid shares can be restored without revealing anything to server 1.

[0088] FIG. 3 is a diagram for explaining the method according to the second embodiment of the present invention. Since this method is very similar to the method illustrated in FIG. 2, detailed description is omitted here. However, in the method illustrated in FIG. 3, the refresh of the distributed secret key is executed in the following procedure.

[0089] Server 1 obtains, by the method described above with reference to FIG. 2, the refreshed secret key share and the zero share that constitutes the difference between the refreshed key and the previous key. Then, the secret share ring of the difference server 1's share, d1^1 in the first refresh, is created, and each of the other servers receives the share. For example, server 2 receives share a2^1.

[0090] Other servers including server 2 generate the accumulated version A2^n of the difference by adding the newly received share to the previous accumulated version A2^(n - 1) and then deleting the previous accumulated version A2^(n - 1) at each refresh.

[0091] While the share s1^4 of the private key is valid, data loss occurs on Server 1 and restoration from backup is required. Therefore, Server 1 restores the original distributed private key s1^1 from the backup and requests the versions stored on other servers. The other servers provide the versions stored for Server 1. For example, Server 2 provides a2^4, and Server i provides ai^4. Then, Server 1 can restore the sum of the differences related to each refresh by recombining the accumulated versions received from other servers, and can obtain the valid share s1^4 by adding the restored sum to the restored original share s1^1. Also, in this embodiment, nothing is revealed about either of the intermediate refreshed key shares s1^2, s1^3.

[0092] Figure 4 is a diagram for explaining the method according to the third embodiment of the present invention. The method shown in Figure 4 is very similar to the methods shown in Figures 2 and 3, so detailed description is omitted here. However, in the embodiment of Figure 4, the share of the difference d1^1 of Server 1 is secretly shared as described above with reference to Figure 3, and the secret shares are encrypted using an additive homomorphic encryption scheme as described above with reference to Figure 2 before being provided to each of the other servers. Therefore, the embodiment of Figure 4 can be regarded as a combination of the embodiment of Figure 2 and the embodiment of Figure 3. Thereby, additional security is added to the system.

[0093] Figure 5 is a diagram for explaining the method according to the fourth embodiment of the present invention. The method of Figure 5 is very similar to the method illustrated in Figure 2, so detailed description is omitted here.

[0094] In the method illustrated in Figure 5, Server 1 generates a zero-knowledge proof, ZKP, during each refresh and transfers this together with the encrypted version of the share of the zero-sharing to other servers. Thereafter, the other servers verify the zero-knowledge proof. If at least one server determines that the zero-knowledge proof is not valid, the refresh process is interrupted.

[0095] FIG. 6 is a diagram for explaining the method according to the fifth embodiment of the present invention. Since the method of FIG. 6 is very similar to the method illustrated in FIG. 2, detailed description is omitted here. However, in the method illustrated in FIG. 6, at each refresh, each server transmits its version to all other servers, and each server compares the accumulated versions by comparing the received versions. And when at least one server receives non-identical accumulated versions, the refresh process is aborted.

[0096] FIG. 7 is a diagram for explaining the method according to the sixth embodiment of the present invention. Since the method of FIG. 7 is very similar to the method shown in FIG. 3, detailed description is omitted here. However, in the embodiment of FIG. 7, each refresh includes an additional verification step that is executed before the refreshed secret key and zero sharing are generated.

[0097] The distributed secret key is, in this case, the signature key used for generating a digital threshold signature, and each server holds the public verification key VK. In the additional verification step, the servers agree on a random message M^1, sign the random message using each share of the distributed key, thereby generating a signature SIG^1. The generated signature is provided to each server, and each server verifies the signature with the public verification key VK. If at least one server cannot verify the signature, the refresh process is interrupted.

[0098] Note that FIGS. 4 to 7 illustrate only the refresh of the distributed secret key, but it should be understood that restoration from backup can also be basically performed by the method described above with reference to FIG. 2 or FIG. 3.

[0099] FIG. 8 is a diagram for explaining the method according to the seventh embodiment of the present invention. Since the method of FIG. 8 is very similar to the method illustrated in FIG. 2, detailed description is omitted here.

[0100] The method illustrated in FIG. 8 uses a threshold signature scheme, similar to the embodiment of FIG. 7. In contrast to the embodiment of FIG. 7, however, in the method of FIG. 8, the distributed secret key need not be the same as the distributed key of the threshold signature scheme. In the embodiment of FIG. 8, the public verification key (VK) of the threshold signature scheme is stored in backup.

[0101] In the embodiment of FIG. 8, the server signs the differentially encrypted share D^1 using the distributed signature key, thereby generating a signature SIG^1. Each server stores SIG^1 together with the accumulated version of the difference.

[0102] If restoration is required, server 1 requests the accumulated versions stored on other servers, and the other servers also provide the currently valid signature (SIG^2 in the example of FIG. 8). Server 1 then verifies the signature SIG^2 and aborts the restoration process if verification fails.

[0103] Optionally, a timestamp may be included, in which case server 1 also verifies that T^2 actually represents the time immediately before the data loss.

Claims

【Claim 1】 A method for restoring a distributed secret key from a backup storage, comprising: generating an original secret key and distributing the original secret key to two or more servers, each server holding a share of the original secret key and no single server holding all shares of the original secret key; a first server creating a backup, the backup including at least the share of the original secret key held by the first server; the two or more servers refreshing each share of the original secret key at least once, each refreshing step including: the two or more servers generating a refreshed distributed secret key and a distributed difference between the previous distributed secret key and the refreshed distributed secret key, each server holding a share of the distributed difference, the distributed difference forming a zero share, and the two or more servers discarding the shares of the previous distributed secret key; each server generating a secret version of the share of the distributed difference and sharing the secret version with at least a portion of the other servers; each server generating a cumulative secret version of the share of the distributed difference received from the other servers based on the received secret version of the share of the distributed difference received and the previous cumulative secret version; and refreshing; the first server restoring the share of the original distributed secret key from the backup and requesting the cumulative secret version of the share of the distributed difference from the other servers; at least some of the other servers providing the cumulative secret version of the distributed difference of the first server to the first server; The step in which the first server restores a share of the latest refreshed distributed secret key from the received and stored secret version and the restored share of the original distributed secret key A method comprising the above. **Claim 2** The step in which each server generates a secret version of the share of the distributed difference is executed by an additive homomorphic scheme, The step in which each server generates an accumulated secret version includes each server adding the received secret version of the share of the distributed difference to its respective previous accumulated secret version and discarding the previous accumulated secret version, The method according to claim 1. **Claim 3** The additive homomorphic scheme is a public key encryption scheme, The step in which the first server creates a backup includes storing a private decryption key as part of the backup, The method according to claim 2. **Claim 4** The step in which each server generates a secret version of the share of the distributed difference includes each server creating a sharing of the share of the distributed difference and distributing the share among at least some of the other servers, The method according to claim 2 or 3. **Claim 5** Each refresh is The step in which the two or more servers create a sharing of zeros, each server adds the share of the sharing of zeros to the share of the previous distributed secret key, thereby creating the refreshed distributed secret key distributed among the two or more servers, and discarding the share of the previous distributed secret key, wherein the sharing of zeros constitutes a distributed difference, and the discarding step, Each server generates a secret version of the sharing with zero and shares the secret version with at least a part of the other servers. The method according to any one of claims 1 to 4, comprising: **Claim 6** Further comprising the step of storing the backup in offline storage. The method according to any one of claims 1 to 5. **Claim 7** Each step of refreshing includes the step that each server verifies the correctness of the received secret version of the shared differential by verifying a zero-knowledge proof. The method according to any one of claims 1 to 6, further comprising: **Claim 8** The step that the first server verifies the correctness of the received accumulated secret version by verifying a zero-knowledge proof. The method according to any one of claims 1 to 7, further comprising: **Claim 9** The method according to any one of claims 1 to 8, wherein the distributed secret key is a secret signature key. **Claim 10** The method according to any one of claims 1 to 8, wherein the distributed secret key is a secret encryption key. **Claim 11** Furthermore, The step that the first server creates a new backup, and The step of repeating at least once the step that the two or more servers refresh respective shares of the original secret key. Including: The step that the first server restores the share of the original distributed secret key includes restoring the share of the distributed secret key stored by the new backup. The method according to any one of claims 1 to 10. **Claim 12** Each refresh further includes the step of the first server generating an accumulated secret version of the distributed difference shares and storing the accumulated secret version at the first server, The secret version of the distributed difference shares forms part of the new backup, The step of the first server restoring the share of the latest refreshed distributed secret key is the restored share of the distributed secret key forming part of the new backup, the secret version of the accumulated difference forming part of the new backup, and the accumulated secret version received from at least a part of the other servers The method according to claim 11, which is carried out based on.

Images