Technique for secretly refreshing a fragment used as a private key by each person while maintaining a public key for multi-signing verification

Abstract

To secretly refresh a fragment to be used as a secret key by each person while maintaining a public key for multi-sig verification.SOLUTION: In a signature system 11, a user terminal 13 secretly holding a user fragment and a signature server 14 secretly holding a server fragment cooperate to generate a signature for a message. The signature is generated by a secret key which is the product of the user fragment and the server fragment, without either the user terminal 13 or the signature server 14 knowing the secret key. The user terminal 13 and the signature server 14 cooperatively execute refresh processing in which the user terminal 13 secretly generates a new user fragment from the user fragment, and the signature server 14 secretly generates a new server fragment from the server fragment. Here, the product of the new user fragment and the new server fragment is equal to the product of the user fragment and the server fragment.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a technique for secretly refreshing the fragments used by each party as their private key while maintaining the public key for multisig verification. [Background technology]

[0002] Multi-sig technology, which is used to approve cryptocurrency transactions, involves multiple parties working together to create an electronic signature using a secretly held fragment of the cryptocurrency as a private key.

[0003] Non-Patent Document 1 discloses a technology for realizing multisig by two parties. In this technology, two parties cooperate to generate a digital signature using the product of the fragments that each party possesses as a master private key, while keeping the fragments that each party possesses secret from others.

[0004] A master public key associated with a master private key is used to verify the digital signature, but both when generating the master public key and when verifying the digital signature, the secret fragments that each party possesses are kept secret from others during the process. [Prior art documents] [Non-patent literature]

[0005] [Non-Patent Document 1] J. Doerner, Y. Kondi, E. Lee and A. Shelat, "Secure Two-party Threshold ECDSA from ECDSA Assumptions", 2018 IEEE Symposium on Security and Privacy (SP), San Francisco, CA, USA, 2018, pp. 980-997, https: / / doi.org / 10.1109 / SP.2018.00036. https: / / ieeexplore.ieee.org / document / 8418649, 2018, (downloaded March 6, 2023) Summary of the Invention [Problem to be solved by the invention]

[0006] In multisig, from the viewpoint of security policy, it is sometimes desirable to actively refresh the fragments used as private keys by each party. Furthermore, it is often desirable to keep the master public key unchanged before and after the refresh.

[0007] The present invention solves the above-mentioned problems and aims to provide a technology that allows secretly refreshing the fragments used by each party as their private key while maintaining the public key for multisig verification. [Means for solving the problem]

[0008] The signature system according to the present invention comprises: A signature system in which a user terminal that secretly holds a user fragment and a signing server that secretly holds a server fragment cooperate to generate a signature for a message, wherein the signature is generated using a private key that is the product of the user fragment and the server fragment, without either the user terminal or the signing server having knowledge of the private key, The user terminal and the signature server perform a refresh process, The user terminal secretly generates a new user fragment from the user fragment; The signing server secretly generates a new server fragment from the server fragment. During the refresh process, The product of the new user fragment and the new server fragment is equal to the product of the user fragment and the server fragment Refresh processing is performed in cooperation with Configure it as follows. [Effects of the Invention]

[0009] According to the present invention, it is possible to provide a technique for secretly refreshing the fragments used by each party as their private key while maintaining the public key for multisig verification.

[0010] By applying this invention, it becomes possible to back up fragments that play an equivalent role in multisig to other devices while keeping the private keys that each person possesses secret. [Brief explanation of the drawings]

[0011] [Figure 1] 1 is an explanatory diagram illustrating a configuration of a signature system according to an embodiment of the present invention. [Figure 2] 10 is a flowchart showing a control flow of a refresh process executed in the signature system according to the embodiment of the present invention. [Figure 3] 10 is a flowchart showing the control flow of a backup process executed in the signature system according to the embodiment of the present invention. [Figure 4] 10 is a flowchart showing a control flow of a restore process executed in the signature system according to the embodiment of the present invention. [Figure 5] 10 is a flowchart showing a control flow of a preliminary process executed in the signature system according to the embodiment of the present invention. [Figure 6] 10 is a flowchart showing a control flow of a repair process executed in the signature system according to the embodiment of the present invention. [Figure 7] FIG. 1 is an explanatory diagram showing how secret information is distributed, held, and stored in a signature system according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0012] The following describes embodiments of the present invention. Note that these embodiments are for illustrative purposes only and do not limit the scope of the present invention. Therefore, those skilled in the art can adopt embodiments in which each or all of the elements of the present embodiments are replaced with equivalents. Furthermore, elements described in each example can be omitted as appropriate depending on the application. In this way, all embodiments constructed in accordance with the principles of the present invention are included in the scope of the present invention.

[0013] (Signature System) 1 is an explanatory diagram showing the configuration of a signature system according to an embodiment of the present invention. The following description will be made with reference to this diagram.

[0014] The signature system 11 according to this embodiment comprises a user terminal 13a and a signature server 14, which are connected via a computer communication network 12 such as the Internet. The signature system 11 may also comprise, as additional elements, a backup server 15 and a public key server 16. If a user loses the user terminal 13a, another user terminal 13b used by the same user may be used as a component in place of the user terminal 13a. Hereinafter, the user terminals 13a and 13b used by the users will be collectively referred to as the "user terminal 13" where appropriate.

[0015] Furthermore, in preparation for the loss or malfunction of the user terminal 13 itself, various information can be stored in the cloud server 17. By configuring the cloud server 17 to require biometric authentication or social login via the user terminal 13 in order to store and retrieve the various information in the cloud server 17, even if the user terminal 13a is lost or malfunctions, the various information can be returned to a new user terminal 13b.

[0016] In addition, after the various information obtained from the cloud server 17 is used on the user terminal 13, the various information can be immediately deleted from the user terminal 13, thereby preventing the leakage of the various information from the user terminal 13.

[0017] The user terminal 13, signature server 14, backup server 15, and public key server 16 that make up the signature system 11 are typically implemented by a computer running a program. The computer is connected to various output and input devices, and sends and receives information to and from these devices.

[0018] The programs executed by each computer can be distributed or sold via a web server or the like to which the computer is connected for communication. Alternatively, the programs can be recorded on a non-transitory information recording medium such as a CD-ROM (Compact Disk Read Only Memory), flash memory, or EEPROM (Electrically Erasable Programmable ROM), and the information recording medium can then be distributed or sold.

[0019] The program is installed on a non-transitory information recording medium such as a hard disk, solid state drive, flash memory, EEPROM, etc., which the computer has. Then, the user terminal and the server in this embodiment are realized by the computer.

[0020] Generally, a computer's CPU (Central Processing Unit) reads a program from an information storage medium into RAM (Random Access Memory) under the control of the computer's OS (Operating System), and then interprets and executes the code contained in the program. However, in architectures where the information storage medium can be mapped within a memory space accessible to the CPU, explicit loading of the program into RAM may not be necessary. Note that various information required during program execution can be temporarily stored in RAM.

[0021] It should be noted that the information processing device of this embodiment may be configured using a dedicated electronic circuit rather than a general-purpose computer. In this embodiment, the program may be used as a resource for generating wiring diagrams, timing charts, and the like for the electronic circuit. In this embodiment, an electronic circuit that meets the specifications defined in the program is configured using an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit), and the electronic circuit functions as a dedicated device that performs the functions defined in the program, thereby realizing the information processing device of this embodiment.

[0022] Typically, the user terminal 13 is configured by a smartphone. The smartphone performs the function of the user terminal 13 according to this embodiment by executing an application program downloaded from an app store and installed thereon.

[0023] Furthermore, signature server 14, backup server 15, and public key server 16 are configured as server computers that provide information storage services. In the signature system according to this embodiment, signature server 14, backup server 15, and public key server 16 can be configured as dedicated servers, but convenience for users can be maintained by configuring them as general-purpose online storage that allows social login.

[0024] For ease of understanding, the following description will be given assuming that the user terminal 13, signature server 14, backup server 15, and public key server 16 are realized by a computer executing a program.

[0025] (Basic configuration) In the signature system 11 according to this embodiment, The user terminal 13 receives the user fragment sk u kept secret, The signing server 14 sends the server fragment sk s keep secret This allows a user using the user terminal 13 to sign using multi-signature in cooperation with the signature server 14.

[0026] Here, "secretly" means "without being known to others." Therefore, in the signature system 11, the signature server 14 u The user terminal 13 does not know the server fragment sk s You will never know.

[0027] sk u , sk s is a finite field F based on a large prime number q. q The finite field F is an element of the finite field F, which is secretly generated by the user terminal 13 and the signature server 14. q In this case, the four arithmetic operations, such as the product of elements and the reciprocal of elements, are naturally defined.

[0028] The signature can be verified by the public key pk. This public key pk is the user fragment sk u and the server fragment sk s The secret key (sk u ·sk s ), and is linked to the user who uses the user terminal 13 and made public by the public key server 16. However, this private key itself (sk u ·sk s ) is configured so that neither the user terminal 13 nor the signature server 14 can know it.

[0029] Such a multi-sig signature can be realized by the DKLs18 protocol disclosed in Non-Patent Document 1, but the present invention can also be applied to other signature protocols.

[0030] In this way, by signing using multi-signature between the user terminal 13 and the signature server 14, security can be increased, and even if either one of them is attacked, damage can be limited.

[0031] As mentioned above, in the signature system 11, there are times when each party wants to proactively refresh the fragments they use as their private keys. The user terminal 13 receives the existing user fragment sk u A new user fragment sk that can replace u ', The signing server 14 uses the existing server fragment sk s A new user fragment sk that can replace s ' to get There are times when you may want to do this.

[0032] The public key pk associated with the user who uses the user terminal 13 has already been published by the public key server 16, etc., and is often already obtained by a third party who wants to verify the signature. Therefore, in this embodiment, the public key pk is maintained unchanged before and after the refresh. In this configuration, even if the fragments are refreshed, there is no need to notify third parties of this fact.

[0033] Therefore, in this embodiment, a new user fragment sk u ' and new server fragment sk s ' product (sk u '·sk s ') is the original user fragment sk u and the original server fragment sk s product of (sk u ·sk s ) so that it is equal to sk u '·sk s ' = sk u ·sk s

[0034] Then, the private key (sk u '·sk s The public key pk' corresponding to the private key (sk u ·sk s ) will match the public key pk corresponding to pk' = pk

[0035] To perform such a refresh, the user terminal 13 and the signing server 14 first generate a temporary random number r shared by the user terminal 13 and the signing server 14. That is, in the finite field F q One of the elements is randomly selected and set as the random number r. By using the Diffie-Hellman algorithm or other secret sharing techniques for generating and sharing this temporary random number r, it is possible to keep it secret from third parties.

[0036] Then, the user terminal 13 uses either the shared random number r or its inverse 1 / r as the user fragment sk u By multiplying by , a new user fragment sk u Here, since r is a random number, there is no loss of generality even if the former r is adopted as "one side." sk u ' = sk u ·r

[0037] On the other hand, the signature server 14 uses the shared random number r and its inverse 1 / r as the server fragment sk s By multiplying by , a new server fragment sk s Of r and 1 / r, "one" is the side being used by the user terminal 13, so "the other" is the side not being used by the user terminal 13. In the above example, the latter, 1 / r, becomes the "other". sk s ' = sk s (1 / r)

[0038] With this construction, the product of the user fragment and the server fragment is invariant: sk u '·sk s ' = sk u ·r·sk s (1 / r) = sk u r (1 / r) sk s = sk u ·sk s

[0039] In this configuration, the temporary random number r is shared, but each user uses the user fragment sk to calculate a new fragment. u There is no need to inform the signing server 14 of the server fragment sk s There is no need to inform the user terminal 13 of this.

[0040] Therefore, the user terminal 13 receives the new user fragment sk u ' secretly, and the signing server 14 can send the new server fragment sk s ' can be kept secret.

[0041] New user fragments generated from existing user fragments by refreshing can replace the existing user fragments and be immediately usable, or they can be used for backup, etc., as described below.

[0042] The temporary random number r is newly generated and shared each time a refresh is performed. In the following, r is used as the variable name for the temporary random number, but it is not intended to be used repeatedly while maintaining the same value. The variable name r is intended to generate a new value each time a process is performed.

[0043] (Refresh process) The following describes the refresh process executed by the user terminal 13 and the signature server 14 in cooperation with each other. Fig. 2 is a flowchart showing the control flow of the refresh process executed in the signature system according to the embodiment of the present invention.

[0044] The refresh process is generally initiated when communication between the user terminal 13 and the signature server 14 becomes possible and the user of the user terminal 13 performs a predetermined operation.

[0045] When the refresh process starts, the user terminal 13 and the signature server 14 generate a temporary random number r shared between them while keeping it secret from third parties using various known techniques such as the Diffie-Hellman method (step S201).

[0046] Next, the user terminal 13 receives the user fragment sk that it owns. u Multiplying by a shared temporary random number r, we get a new user fragment sk u ' is calculated (step S202), and the process on the user terminal 13 side is terminated.

[0047] On the other hand, the signing server 14 stores the server fragment sk s Multiply by the inverse of the shared temporary random number r (1 / r) to get a new server fragment sk s ' is calculated (step S203), and the processing on the signature server 14 side is terminated.

[0048] The new user fragment and the new server fragment thus obtained can be used secretly by the user terminal 13 and the signing server 14, respectively.

[0049] For example, if the user terminal 13 and the signature server 14 were to adopt new user fragments and new server fragments generated by the refresh process instead of the existing user fragments and existing server fragments, respectively, it would become possible to actively update the fragments.

[0050] The user fragment and the server fragment are confidential information that are required when a user issues a digital signature. The following describes how to configure these fragments so that they can be appropriately backed up and restored.

[0051] In this application, for ease of understanding, the backup and restoration of user fragments will be referred to as "backup processing" and "restore processing," and the backup and restoration of server fragments will be referred to as "preparatory processing" and "repair processing."

[0052] (Backup process for user fragments) 3 is a flowchart showing the control flow of backup processing executed in a signature system according to an embodiment of the present invention. The backup processing is for storing secret information for re-enabling signatures when user fragments are lost from the user terminal 13, outside the user terminal 13. The following description will be given with reference to this diagram.

[0053] When the backup process is started, the user terminal 13 and the signature server 14 execute refresh processes on the user fragments and server fragments held by them, respectively (step S301).

[0054] Here, the newly generated user fragment is called a user backup fragment, and the newly generated server fragment is called a server backup fragment.

[0055] Next, user terminal 13 authenticates cloud server 17 as necessary and acquires an encryption key stored as various information in cloud server 17 (step S302). Note that if the encryption key acquired from cloud server 17 that has been successfully authenticated is set to be retained by user terminal 13 for a certain period of time, and the encryption key is already retained in user terminal 13, authentication and acquisition of the encryption key from cloud server 17 may be omitted.

[0056] Next, the user terminal 13 encrypts the user backup fragment with the obtained encryption key (step S303), stores the encrypted user backup fragment in the backup server 15 (step S304), erases the user backup fragment and the encrypted user backup fragment from the user terminal 13 (step S305), and terminates processing on the user terminal 13 side.

[0057] On the other hand, the signing server 14 retains the server backup fragment as it is within the signing server 14 (step S306), and the processing on the signing server side ends.

[0058] The user fragment backup process The user terminal 13 holds user fragments, The backup server 15 stores the encrypted user backup fragments, The signing server 14 holds the server fragment and stores the server backup fragment. This will happen.

[0059] (Restore process related to user fragments) 4 is a flowchart showing the control flow of the restore process executed in the signature system according to the embodiment of the present invention. The restore process is executed when the user fragments are deleted from the user terminal 13 due to some circumstances, such as the deletion of an app due to an erroneous operation, or when the user terminal 13a is lost or broken down and a new user terminal 13b is to be used.

[0060] When the restoration process is started, the user terminal 13 performs authentication with the cloud server 17 as necessary, and acquires the decryption key stored as various information (step S401).

[0061] This decryption key corresponds to the encryption key obtained in step S302. For example, if a symmetric key cryptosystem is used, the decryption key and the encryption key will match. If a public key cryptosystem is used, the encryption key in step S302 corresponds to the public key of the key pair, and the decryption key in step S401 corresponds to the private key of the key pair.

[0062] Next, the user terminal 13 acquires the encrypted user backup fragment from the backup server 15 (step S402). Note that the order of the processes in steps S401 and S402 may be reversed.

[0063] Then, the user terminal 143 uses the acquired decryption key to decrypt the original user backup fragment from the acquired encrypted user backup fragment (step S403).

[0064] After this, the user terminal 13 and the signing server 14 perform a refresh process on the user backup fragment decrypted in step S403 and the server backup fragment stored in step S306 to generate a new user fragment and a new server fragment (step S404).

[0065] Then, the user terminal 13 updates the user fragment by holding the new user fragment as the user fragment to be used in subsequent signatures (step S405).

[0066] Meanwhile, the signature server 14 updates the server fragment by holding the new server fragment as the server fragment to be used in subsequent signatures, instead of the server fragment that has been used up until now (step S406).

[0067] After this, the user terminal 13 and the signature server 14 cooperate to again execute the backup process on the newly held user fragment and the newly held server fragment (step S407), and then this process ends.

[0068] In this way, by performing backup and restore processes on user fragments, even if a user fragment is lost from the user terminal 13, secret information for executing future signatures can be set up in the user terminal 13 and the signature server 14, and even if a user fragment is further lost from the user terminal 13 in the future, secret information for restoring the user fragment can be set up in the user terminal 13, the signature server 14, and the backup server 15.

[0069] In addition, The user backup fragment is lost from the user terminal 13, or The server backup fragment is lost from the signing server 14, or The user backup fragment was lost from the backup server. In this case, the secret information required for restoration can be set up in the user terminal 13, the signature server 14, and the backup server 15 by executing the backup process described above again.

[0070] Furthermore, since the user backup fragments stored in the backup server 15 are encrypted based on the authentication of the user of the user terminal 13, the user backup fragments themselves will not be leaked to the backup server 15 side.

[0071] In addition, even if the server backup fragment is lost from the signature server 14 or the encrypted user backup fragment is lost from the backup server 15, the storage state can be restored to the same state as described above by performing a backup process.

[0072] (Preliminary processing for server fragments) 5 is a flowchart showing the control flow of preliminary processing executed in the signature system according to an embodiment of the present invention. The preliminary processing is to store, outside the signature server 14, secret information for enabling signing again when the server fragment is lost from the signature server. The following description will be given with reference to this diagram.

[0073] When the preliminary process is started, the user terminal 13 and the signature server 14 execute refresh processes on the user fragments and server fragments that they respectively hold (step S501).

[0074] Here, the newly generated user fragment is called a user spare fragment, and the newly generated server fragment is called a generated server spare fragment.

[0075] Next, user terminal 13 performs authentication with cloud server 17 as necessary and acquires the encryption key stored in cloud server 17 (step S502).

[0076] Next, the user terminal 13 encrypts the user spare fragment with the acquired encryption key (step S503), stores the encrypted user spare fragment in the backup server 15 (step S504), and erases the user spare fragment and the encrypted user spare fragment from the user terminal 13 (step S505).

[0077] Meanwhile, the signing server 14 encrypts the server spare fragment so that it can be decrypted by the signing server 14 itself (step S506), sends the encrypted server spare fragment to the user terminal 13 (step S507) for storage, and erases the server spare fragment and the encrypted server spare fragment from the signing server 14 (step S508), thereby terminating processing on the signing server 14 side.

[0078] User terminal 13 receives the encrypted server spare fragment sent from signature server 14 (step S509), stores it within user terminal 13 (step S510), and the processing on the user terminal 13 side is completed.

[0079] The processes of steps S502-S505 and steps S509-S510 in the user terminal 13 can be executed in parallel or interleaved as appropriate.

[0080] The server fragment preparation process The user terminal 13 holds the user fragment and stores the encrypted server spare fragment; The backup server 15 stores the encrypted user spare fragments, The signing server 14 holds the server fragment. This will happen.

[0081] (Server fragment repair process) 6 is a flowchart showing the control flow of the restoration process executed in the signature system according to the embodiment of the present invention. The restoration process is executed when the server fragment stored in the signature server 14 is lost due to a natural disaster, a cyber attack, or the like.

[0082] When the restoration process is started, the user terminal 13 performs authentication with the cloud server 17 as necessary and acquires the decryption key stored in the cloud server 17 (step S601).

[0083] Next, the user terminal 13 acquires the encrypted user spare fragment from the backup server 15 (step S602). Note that the order of the processes in steps S601 and S602 may be reversed.

[0084] Then, the user terminal 13 uses the obtained decryption key to decrypt the original user spare fragment from the obtained encrypted user spare fragment (step S603).

[0085] Furthermore, the user terminal 13 sends the encrypted server spare fragment stored in the user terminal 13 to the signing server 14 (step S604).

[0086] The signature server 14 receives the encrypted server spare fragment sent from the user terminal 13 (step S605) and decrypts the original server spare fragment (step S606).

[0087] The processing of steps S601-S604 in the user terminal 13 and the processing of steps S603-S606 in the signing server 14 can be executed in parallel or in parallel. The processing of steps S601-S603 in the user terminal 13 and the processing of step S604 can be executed in parallel or in parallel or interleaved as appropriate.

[0088] After this, the user terminal 13 and the signature server 14 perform a refresh process on the user spare fragment decrypted in step S603 and the server spare fragment decrypted in step S606 to generate a new user fragment and a new server fragment (step S607).

[0089] Then, the user terminal 13 updates the user fragment by holding the new user fragment as the user fragment to be used in subsequent signatures (step S608).

[0090] Meanwhile, the signature server 14 updates the server fragment by holding the new server fragment as the user fragment to be used in subsequent signatures (step S609).

[0091] Thereafter, the user terminal 13 and the signing server 14 cooperate to again execute the preliminary processing on the newly held user fragment and the newly held server fragment (step S610), and then this processing ends.

[0092] In this way, by performing preliminary processing and repair processing on the server fragment, even if the server fragment is lost from the signing server 14, it can be set up in the user terminal 13 and the signing server 14, and even if another server fragment is lost from the signing server 14 in the future, secret information for restoring the server fragment can be set up in the user terminal 13, the signing server 14, and the backup server 15.

[0093] In addition, The server spare fragment is lost from the user terminal 13, or The user's spare fragment was lost from the backup server In this case, the secret information required for restoration can be set up in the user terminal 13, the signature server 14, and the backup server 15 by executing the above preliminary processing again.

[0094] Furthermore, since the user spare fragments stored in the backup server 15 are encrypted based on the authentication of the user of the user terminal 13, the user spare fragments themselves will not be leaked to the backup server 15 side.

[0095] Furthermore, since the server spare fragment stored in the user terminal 13 is encrypted by the signature server 14, the server spare fragment itself will not be leaked to the user terminal 13 side.

[0096] Furthermore, even if the encrypted server spare fragment is lost from the user terminal 13 or the encrypted user spare fragment is lost from the backup server 15, the state can be restored to the same state as above by performing a recovery process.

[0097] (Combination of backup, restore, backup and repair) It is desirable to employ both backup / restore of user fragments and spare / repair of server fragments.

[0098] FIG. 7 is an explanatory diagram showing how secret information is distributed and stored in a signature system according to an embodiment of the present invention. As shown in this figure, in an embodiment that employs both, The user terminal 13 holds the user fragment and stores the encrypted server spare fragment; The backup server 15 stores encrypted user backup fragments and encrypted user spare fragments, The signing server 14 holds the server fragment and stores the server backup fragment.

[0099] Here, when the user terminal 13a is lost or broken and a new user terminal 13b is started, first a restoration process is performed, and then a backup process is performed, thereby returning to a state in which the secret information is distributed and stored in the same manner as in Figure 7.

[0100] Furthermore, if the signature server 14 is attacked or otherwise loses all of its information, it can be restored to a state in which the secret information is distributed and stored in the same way as in Figure 7 by first performing a recovery process and then a backup process.

[0101] In addition, if the backup server 15 is attacked or otherwise loses all of its information, the backup process and the backup process can be performed in any order to restore the state in which the secret information is distributed and stored in the same way as in Figure 7.

[0102] In other words, according to this embodiment, the secret information used by the user terminal 13 and the signature server 14 to cooperate in creating an electronic signature is stored in a distributed manner among the three parties of the user terminal 13, the signature server 14, and the backup server 15. Therefore, even if the information stored by any one of the parties is lost, it can be restored to an equivalent state.

[0103] In this case, the fragments held and stored by the three parties are updated, but the public key for verifying the electronic signature remains unchanged and is maintained as is, so there is no need to update the information stored by the public key server 16, and the impact on others can be minimized.

[0104] The refresh process in this embodiment has so-called idempotence in that the public key managed by the public key server 16 for verifying the digital signature does not change no matter how many times it is applied.

[0105] therefore, You can perform a preliminary process following the restore process, You can perform a backup process following a repair process, You can run backup and backup processes in any order. When doing so, if the refresh processes are simply being executed consecutively, the processes can be combined into one process, or the number of times the refresh processes are executed can be increased.

[0106] (summary) The signature system according to the present embodiment described above, the user terminal 13, the signature server 14 in the signature system, the methods executed by the user terminal 13 and the signature server 14, and the programs will be described below.

[0107] (Appendix 1) The signature system according to this embodiment is a signature system in which a user terminal that secretly holds a user fragment and a signature server that secretly holds a server fragment cooperate to generate a signature for a message, and the signature is generated using a private key that is the product of the user fragment and the server fragment, without either the user terminal or the signature server having knowledge of the private key; The user terminal and the signature server perform a refresh process, The user terminal secretly generates a new user fragment from the user fragment; The signing server secretly generates a new server fragment from the server fragment. During the refresh process, The product of the new user fragment and the new server fragment is equal to the product of the user fragment and the server fragment Refresh processing is performed in cooperation with Configure it as follows.

[0108] In addition, in the signature system of this embodiment, In the refresh process, the user terminal and the signature server generate a temporary random number to be shared by the user terminal and the signature server; generating the new user fragment at the user terminal by multiplying the user fragment by one of the shared random number and its inverse; The signing server generates the new server fragment by multiplying the server fragment by the other of the shared random number and its inverse. It can be configured as follows.

[0109] In addition, in the signature system of this embodiment, The temporary random number is generated and shared using the Diffie-Hellman algorithm. It can be configured as follows.

[0110] In addition, in the signature system of this embodiment, The signature is performed according to the DKLs18 protocol It can be configured as follows.

[0111] In addition, in the signature system of this embodiment, (1) The user terminal and the signature server perform a backup process, By performing the refresh process on the user fragment and the server fragment, generating a user backup fragment at the user terminal; generating a server backup fragment at the signing server; The user terminal stores the user backup fragment in a backup server and deletes it from the user terminal; The signing server holds the server backup fragment. Backup processes are performed in cooperation with each other. (2) When the user fragment is lost from the user terminal, the user terminal acquires the user backup fragment from the backup server; The user terminal and the signing server execute the refresh process on the user backup fragment and the server backup fragment, generating new user fragments at the user terminal; generating a new server fragment at the signing server; The user terminal stores the new user fragment; the signing server holds the new server fragment in place of the server fragment; The user terminal and the signing server cooperatively perform the backup process again for the new user fragment and the new server fragment. It can be configured as follows.

[0112] In addition, in the signature system of this embodiment, The user backup fragments are encrypted by the user terminal and then stored in the backup server. It can be configured as follows.

[0113] In addition, in the signature system of this embodiment, The encrypted user backup fragment is decrypted on the condition that biometric authentication or social login of the user using the user terminal is successful. It can be configured as follows.

[0114] In addition, in the signature system of this embodiment, The user backup fragment is lost from the user terminal, or The server backup fragment is lost from the signing server, or The user backup fragment is lost from the backup server. If so, the backup process will be performed again. It can be configured as follows.

[0115] In addition, in the signature system of this embodiment, (3) The user terminal and the signing server perform a preliminary process, By executing the refresh process on the user fragment and the server fragment, generating user spare fragments at the user terminal; generating a server spare fragment at the signing server; The user terminal stores the user spare fragment in the backup server and deletes it from the user terminal; The signing server stores the server spare fragment in the user terminal and deletes it from the signing server. further collaboratively performing preliminary processing; (4) If the server fragment is lost from the signing server, The user terminal acquires the user spare fragment from the backup server, The signing server acquires the server spare fragment from the user terminal; The user terminal and the signature server execute the refresh process on the user spare fragment and the server spare fragment, generating new user fragments at the user terminal; generating a new server fragment at the signing server; The user terminal stores the new user fragment in place of the user fragment; The signing server maintains the new server fragment; The user terminal and the signing server cooperatively perform the backup process and the preliminary process again on the new user fragment and the new server fragment. It can be configured as follows.

[0116] In addition, in the signature system of this embodiment, The server spare fragment is encrypted by the signing server and then stored in the user terminal; The encrypted server spare fragment is obtained from the user terminal and then decrypted by the signing server. It can be configured as follows.

[0117] In addition, in the signature system of this embodiment, The server spare fragment is lost from the user terminal, or The user spare fragment is lost from the backup server If so, the preliminary process is performed again. It can be configured as follows.

[0118] The user terminal of this embodiment can be configured to be a user terminal in the above signature system.

[0119] The signing server of this embodiment can be configured to be the signing server in the signing system of this embodiment.

[0120] The signature system of this embodiment comprises: A signature system in which a user terminal that secretly holds a user fragment and a signing server that secretly holds a server fragment cooperate to generate a signature for a message, wherein the signature is generated using a private key that is the product of the user fragment and the server fragment, without either the user terminal or the signing server having knowledge of the private key, The user terminal and the signature server perform a refresh process, the user terminal secretly generating a new user fragment from the user fragment; the signing server secretly generating a new server fragment from the server fragment; Equipped with The product of the new user fragment and the new server fragment is equal to the product of the user fragment and the server fragment Refresh processing is performed in cooperation with Configure it as follows.

[0121] The user terminal program of this embodiment configures a computer to function as a user terminal in the signature system.

[0122] The signature server program of this embodiment configures a computer to function as a signature server in the signature system.

[0123] The present invention allows various embodiments and modifications without departing from the broad spirit and scope of the present invention. Furthermore, the above-described embodiments are intended to explain the present invention and do not limit the scope of the present invention. That is, the scope of the present invention is defined by the claims, not the embodiments. Various modifications made within the scope of the claims and the meaning of the invention equivalent thereto are considered to be within the scope of the present invention. [Industrial Applicability]

[0124] According to the present invention, it is possible to provide a technique for secretly refreshing the fragments used by each party as their private key while maintaining the public key for multisig verification. [Explanation of symbols]

[0125] 11 Signature System 12 Computer Communication Network 13, 13a, 13b User terminal 14 Signature Server 15 Backup Server 16 Public Key Servers 17 Cloud Server

Claims

1. A signature system in which a user terminal that secretly holds a user fragment and a signing server that secretly holds a server fragment cooperate to generate a signature for a message, wherein the signature is generated using a private key that is the product of the user fragment and the server fragment, without either the user terminal or the signing server having knowledge of the private key, The user terminal and the signature server perform a refresh process, The user terminal secretly generates a new user fragment from the user fragment; The signing server secretly generates a new server fragment from the server fragment. During the refresh process, The product of the new user fragment and the new server fragment is equal to the product of the user fragment and the server fragment Refresh processing is performed in cooperation with A signature system characterized by:

2. In the refresh process, the user terminal and the signature server generate a temporary random number to be shared by the user terminal and the signature server; generating the new user fragment at the user terminal by multiplying the user fragment by one of the shared random number and its inverse; The signing server generates the new server fragment by multiplying the server fragment by the other of the shared random number and its inverse.

2. The signature system of claim 1.

3. The temporary random number is generated and shared using the Diffie-Hellman algorithm.

3. The signature system according to claim 2.

4. The signature is performed according to the DKLs18 protocol 2. The signature system of claim 1.

5. 2. The signature system of claim 1, (1) The user terminal and the signature server perform a backup process, By performing the refresh process on the user fragment and the server fragment, generating a user backup fragment at the user terminal; generating a server backup fragment at the signing server; The user terminal stores the user backup fragment in a backup server and deletes it from the user terminal; The signing server holds the server backup fragment. Backup processes are performed in cooperation with each other. (2) When the user fragment is lost from the user terminal, the user terminal acquires the user backup fragment from the backup server; The user terminal and the signing server execute the refresh process on the user backup fragment and the server backup fragment, generating new user fragments at the user terminal; generating a new server fragment at the signing server; The user terminal stores the new user fragment; the signing server holds the new server fragment in place of the server fragment; The user terminal and the signing server cooperatively perform the backup process again for the new user fragment and the new server fragment. A signature system characterized by:

6. The user backup fragments are encrypted by the user terminal and then stored in the backup server.

6. The signature system according to claim 5.

7. The encrypted user backup fragment is decrypted on the condition that biometric authentication or social login of the user using the user terminal is successful.

7. The signature system according to claim 6.

8. The user backup fragment is lost from the user terminal, or The server backup fragment is lost from the signing server, or The user backup fragment is lost from the backup server. If so, the backup process will be performed again.

6. The signature system according to claim 5.

9. A signature system according to any one of claims 5 to 8, (3) The user terminal and the signing server perform a preliminary process, By executing the refresh process on the user fragment and the server fragment, generating user spare fragments at the user terminal; generating a server spare fragment at the signing server; The user terminal stores the user spare fragment in the backup server and deletes it from the user terminal; The signing server stores the server spare fragment in the user terminal and deletes it from the signing server. further collaboratively performing preliminary processing; (4) If the server fragment is lost from the signing server, The user terminal acquires the user spare fragment from the backup server, The signing server acquires the server spare fragment from the user terminal; The user terminal and the signature server execute the refresh process on the user spare fragment and the server spare fragment, generating new user fragments at the user terminal; generating a new server fragment at the signing server; The user terminal stores the new user fragment in place of the user fragment; The signing server maintains the new server fragment; The user terminal and the signing server cooperatively perform the backup process and the preliminary process again on the new user fragment and the new server fragment. A signature system characterized by:

10. The server spare fragment is encrypted by the signing server and then stored in the user terminal; The encrypted server spare fragment is obtained from the user terminal and then decrypted by the signing server.

10. The signature system of claim 9.

11. The server spare fragment is lost from the user terminal, or The user spare fragment is lost from the backup server If so, the preliminary process is performed again.

10. The signature system of claim 9.

12. A user terminal in the signature system according to claim 1.

13. A signature server in the signature system according to claim 1.

14. A signature system in which a user terminal that secretly holds a user fragment and a signing server that secretly holds a server fragment cooperate to generate a signature for a message, wherein the signature is generated using a private key that is the product of the user fragment and the server fragment, without either the user terminal or the signing server having knowledge of the private key, The user terminal and the signature server perform a refresh process, The user terminal secretly generates a new user fragment from the user fragment; the signing server secretly generating a new server fragment from the server fragment; Equipped with The product of the new user fragment and the new server fragment is equal to the product of the user fragment and the server fragment Refresh processing is performed in cooperation with A method characterized by:

15. A user program for causing a computer to function as a user terminal in the signature system according to claim 1.

16. A server program for causing a computer to function as a signature server in the signature system according to claim 1.

Images