Techniques for single round multi-party computation for digital signatures

Abstract

A system and method for digitally signing data. A method includes generating, by a first device, at least one first secret share based on a secret key selected by the first device, wherein the first device is offline with respect to a second device; partially signing, by the first device, data using the at least one secret share, wherein the data is received from the second device without establishing direct communication between the first device and the second device; and sending the partially signed data from the first device to the second device, wherein the second device generates signed data using the partially signed data, wherein the signed data corresponds to a public key generated based on the at least one first secret share and at least one second secret share generated by the second device.

Description

[0001] Cross Reference to Related Applications

[0002] This application claims the benefit of U.S. non-provisional application No. 17 / 019,807, filed on September 14, 2020, the contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure relates generally to cryptographic digital signatures, and more specifically to multi-party computations used for cryptographic digital signatures. Background Technology

[0004] In cryptography, digital signatures are typically implemented using keys. A digital signature is a set of algorithms and protocols used to verify the authenticity of message content. Each entity's identity is determined by the public key of a private / public key pair. Only the owner of the private key can sign a message. As digital assets become an increasingly important part of modern life, the use of digital signatures is growing.

[0005] The increasing use of digital currencies and other technologies leveraging blockchain technology presents evolving demands. A blockchain is a growing, distributed electronic ledger comprised of blocks of data. A copy of the blockchain is maintained by peer-to-peer devices in a network typically consisting of thousands of peers and used by millions of potential users participating in transactions. Because a copy of the entire blockchain is maintained by each peer, a single centralized system is not required to maintain the records.

[0006] Many blockchain applications involve digitally signing transaction data to be recorded on the blockchain. Therefore, ensuring the security of digital signature technology is becoming increasingly important. Furthermore, as these applications become more regulated, the need for flexibility in the aforementioned implementation methods will become even more crucial.

[0007] Several solutions exist that involve offline devices. These solutions face challenges in terms of flexibility. As an example of typical digital currency implementations, "cold" wallets (i.e., wallets whose private keys cannot be accessed via the internet or similar networks) are less vulnerable to cyberattacks than "hot" wallets (i.e., wallets whose private keys can be accessed via the internet). However, because cold wallet private keys cannot be accessed via the internet, users must have physical access to the system storing the private keys in order to sign transactions before they are transmitted to the blockchain. In enterprise environments, this also requires granting access to cold wallets to certain trusted employees. However, mismanagement of this access can lead to losses.

[0008] As the demand for digital signatures increases, the need for flexibility in deploying digital signature mechanisms also grows. Beyond user preferences and needs, the various real-world scenarios in which digital signatures operate are constantly evolving. Regulatory, licensing, reporting, and other requirements can alter the demands on digital signature mechanisms. For example, some countries have established appropriate requirements for institutions using digital assets, detailing how a balance must be struck between online assets (e.g., assets whose keys are accessible via the internet) and offline assets (e.g., assets whose keys are not accessible via the internet).

[0009] Offline storage reduces the likelihood of assets being improperly accessed by malicious external entities such as hackers. However, offline systems are more difficult to control and ensure are up-to-date. Therefore, keeping assets offline introduces new operational risks.

[0010] Therefore, it would be beneficial to provide solutions that overcome the aforementioned challenges. Summary of the Invention

[0011] The inventive summary of several exemplary embodiments of this disclosure is provided below. This inventive summary is provided to facilitate the reader in providing a basic understanding of such embodiments and does not necessarily limit the scope of this disclosure. This inventive summary is not an exhaustive overview of all contemplated embodiments and is neither intended to identify key or essential elements of all embodiments nor to describe the scope of any or all aspects. Its sole purpose is to present some concepts of one or more embodiments in a simplified form as a prelude to the more detailed description that follows. For convenience, the terms "some embodiments" or "certain embodiments" may be used herein to refer to a single embodiment or multiple embodiments of this disclosure.

[0012] Some embodiments disclosed herein include a method for digitally signing data. The method includes: a first device among a plurality of devices generating at least one first secret share based on a secret key selected by the first device, the plurality of devices including the first device and a second device, wherein the first device is offline at least relative to the second device; the first device partially signing the data using the at least one secret share, wherein the data is received from the second device without establishing direct communication between the first device and the second device; and sending the partially signed data from the first device to the second device without establishing direct communication between the first device and the second device, wherein the second device generates signature data using the partially signed data, wherein the signature data corresponds to a public key, wherein the public key is generated based on a plurality of secret shares including at least one first secret share and at least one second secret share, wherein the at least one second secret share is generated by the second device.

[0013] Some embodiments disclosed herein also include a non-transitory computer-readable medium storing instructions that cause processing circuitry to perform a process comprising: generating at least one first secret share by a first device among a plurality of devices based on a secret key selected by the first device, the plurality of devices including the first device and a second device, wherein the first device is offline at least relative to the second device; partially signing data by the first device using the at least one secret share, wherein the data is received from the second device without establishing direct communication between the first device and the second device; and sending the partially signed data from the first device to the second device without establishing direct communication between the first device and the second device, wherein the second device generates signature data using the partially signed data, wherein the signature data corresponds to a public key, wherein the public key is generated based on a plurality of secret shares including at least one first secret share and at least one second secret share, wherein the at least one second secret share is generated by the second device.

[0014] Some embodiments disclosed herein also include a system for digitally signing data. The system includes: processing circuitry; and a memory containing instructions that, when executed by the processing circuitry, configure the system to: generate at least one first secret share based on a secret key selected by the system, wherein the system is a first device among a plurality of devices, including a first device and a second device, wherein the first device is offline at least relative to the second device; partially sign data using the at least one secret share, wherein the data is received from the second device without establishing direct communication between the first device and the second device; and send the partially signed data to the second device without establishing direct communication between the first device and the second device, wherein the second device generates signature data using the partially signed data, wherein the signature data corresponds to a public key, wherein the public key is generated based on a plurality of secret shares including at least one first secret share and at least one second secret share, wherein the at least one second secret share is generated by the second device. Attached Figure Description

[0015] The subject matter disclosed herein is specifically pointed out and expressly claimed in the claims appended to this specification. The foregoing and other objects, features, and advantages of the disclosed embodiments will become apparent from the following detailed description taken in conjunction with the accompanying drawings.

[0016] Figures 1A-1B This is a network diagram used to describe various disclosed embodiments.

[0017] Figure 2 This is a sequence diagram illustrating a method for signing a portion of offline transactions according to a disclosed embodiment.

[0018] Figure 3This is a flowchart illustrating a method for signing data using a single-round multi-party computation protocol according to an embodiment.

[0019] Figure 4 This is a flowchart illustrating a method for protecting digital signatures via multi-party computation according to an embodiment.

[0020] Figure 5 This is a schematic diagram of the participant device according to an embodiment. Detailed Implementation

[0021] It is important to note that the embodiments disclosed herein are merely examples of the many advantageous uses of the inventive teachings herein. Generally, the statements made in the specification of this application do not necessarily limit any embodiment of the respective claimed embodiments. Furthermore, some statements may apply to some inventive features but not to others. Generally, unless otherwise stated, singular elements may be plural and vice versa, without loss of generality. In the drawings, the same reference numerals refer to the same parts in multiple views.

[0022] Various disclosed embodiments include methods and systems for single-round multi-party computation for digital signatures. More specifically, data is partially signed by an offline device during a single-round signature operation. One or more other devices each partially sign the data, thereby completing the signature and generating signed data that can be uploaded, for example. Therefore, the amount of interaction with the offline device involved in the signing process is minimized. Furthermore, some disclosed embodiments can support the use of stateless protocols by the offline device.

[0023] In one embodiment, a digital signature includes a key generation phase and a signing phase. During the key generation phase, the parties involved in the digital signature interact to generate a new public key. During the signing phase, the parties interact to sign the data using their respective shares. In another embodiment, the digital signature also includes a preprocessing phase. During the preprocessing phase, the parties interact to generate relevant data to be used in the signing phase (wherein a packet is stored for each future signing operation). This preprocessing phase can be performed multiple times as needed.

[0024] In one embodiment, one or more parties signing the data are offline devices relative to one or more networks; that is, the offline devices are not connected to the Internet or other networks (e.g., air-gap devices). More specifically, the offline devices are offline at least relative to networks accessible to at least some of the other participants in share generation and digital signing. Interactions with the offline devices during the signing phase occur during a single round of interaction. In a single round of interaction, another participating device sends data to the offline device, performs calculations on the offline device based on the sent data to partially sign the data, and sends the partially signed data from the offline device to other participating devices.

[0025] According to the disclosed embodiments, when a device is not directly or indirectly connected to a network via other systems or devices, the device is offline relative to the network. When the first device and the second device are not communicatively connected via any network or network combination, the first device is offline relative to the second device.

[0026] In one example implementation, an offline device is offline relative to the Internet and to any network accessible to devices connected to the Internet. In another example implementation, multiple offline devices may be interconnected, and each offline device is offline relative to other online devices. In yet another example implementation, all devices participating in the MPC may be offline relative to the Internet, and at least some devices are offline relative to each other.

[0027] In various embodiments, the disclosed embodiments can be applied to keyless multi-party computation protocols, such as, but not limited to, the protocol for securing digital signatures using multi-party digital signatures as described in U.S. Patent Application No. 16 / 404,218, assigned to a co-assignee, the contents of which are incorporated herein by reference. Compared to key-based solutions, such embodiments maximize flexibility while improving security.

[0028] The disclosed embodiments offer the benefits typically associated with using "cold" wallets or their keys offline for other digital assets, without at least some of the common drawbacks of such methods. Because the disclosed embodiments are compatible with multi-party computation methods for digital signatures, they provide usability while minimizing security risks. More specifically, the disclosed single-round protocol allows for the digital signing of offline assets, thereby protecting digital assets from unauthorized access attempts. Furthermore, assets can be signed at the user's location, eliminating the need for signing using third-party services.

[0029] Furthermore, the disclosed embodiments provide a multi-party computation protocol that minimizes the number of rounds required to securely sign data. As mentioned above, implementations involving "cold" devices (i.e., devices storing keys that cannot be accessed directly or indirectly via the Internet) require manual interaction with the cold device. This can be time-consuming and laborious, making frequent use of cold devices undesirable. Therefore, the disclosed embodiments mitigate this challenge by reducing the number of times offline devices need to participate in multi-party computations.

[0030] Figure 1AAn example network diagram 100A is shown for describing various disclosed embodiments. In example network diagram 100A, online device 140 communicates with online platform 150 via network 110. Network 110 may be, but is not limited to, wireless networks, cellular or wired networks, local area networks (LANs), wide area networks (WANs), metropolitan area networks (MANs), the Internet, the World Wide Web (WWW), similar networks, and any combination thereof.

[0031] Each of the online device 140 and the offline device 120 can be, but is not limited to, a personal computer, laptop, tablet computer, smartphone, wearable computing device, or any other device capable of receiving and displaying notifications. The offline device 120 can be configured with any kind of software involved in digital signatures, such as, but not limited to, server-side and client-side software. The data stored in the offline device 120 can be stored in a hardware security module (not shown), i.e., a storage module without a central processing unit.

[0032] In one example implementation, to facilitate transmission to offline device 120, the data to be signed is transmitted from online device 140 to intermediate data storage (DS) device 130.

[0033] Intermediate data storage device 130 stores information and allows data to be transferred to or from offline device 120. Therefore, intermediate data storage device 130 is any data transfer mechanism that does not require connection to network 110 to transfer such data. Intermediate data storage device 130 can be, but is not limited to, external hard drives, memory cards, Quick Response (QR) codes, Universal Serial Bus (USB) keys, Uniform Resource Locators (URLs), sound producers (e.g., modems configured to emit sound), unidirectional links (e.g., optical, digital, or analog unidirectional links), printing paper and cameras, scanners, combinations thereof, etc. Intermediate data storage device 130 does not otherwise communicate with network 110 and only communicates with online device 140 when not communicating with offline device 120. In some embodiments, multiple intermediate data storage devices (not shown) may be utilized.

[0034] In various embodiments, intermediate data storage device 130 is configured for one-way communication with a receiving device (i.e., the device to which data is transmitted). As a non-limiting example, such one-way communication can be implemented using a half-duplex system (not shown). Alternatively or consequentially, intermediate data storage device 130 can be configured for bidirectional communication, for example, but not limited to, using Bluetooth or other wireless technology standards. Specifically, intermediate data storage device 130 can utilize one-way communication when communicating with an offline device.

[0035] In some implementations, all data transmitted from online device 140 to offline device 120 according to the disclosed embodiments is partially signed or encrypted using a public key known to offline device 120. To this end, in one embodiment, offline device 120 is configured to attempt to decrypt or verify incoming communications using the public key. In another embodiment, incoming data transmitted from online device 140 may include the hash of the last message received from offline device 120. To this end, offline device 120 may be configured to check the hash in the incoming data against the hash of the most recent data transmitted to online device 140 to confirm that the incoming data was received from the same device. Including the hash of previous messages allows verification that the message was received from the same sender and is therefore secure. Specifically, this can be performed when key generation involves multiple rounds of communication.

[0036] It should be noted that in some embodiments, all devices participating in the signing protocol may be offline relative to a network such as the Internet. In such embodiments, the signed transaction data can be uploaded, for example via an intermediate storage device, by transferring the signed transaction data from one of the offline devices to an online device.

[0037] Figure 1B Example network diagram 100B is shown, illustrating a potential network configuration that can be used with multiple offline devices. In example network diagram 100B, offline device 120 is offline relative to one or more participant devices 160, and online device 140 is configured to upload signature data to online platform 150, but is not necessarily a participant signing the signature.

[0038] Participant device 160 is for other participants who sign. For this purpose, data is transferred between offline device 120 and one or more participant devices 160 via intermediate data storage device 130. Any or all participant devices 160 may be offline relative to network 110.

[0039] It should be noted that, for the sake of simplicity, Figure 1B A single intermediate data storage device 130 is shown, but in other embodiments, different intermediate data storage devices may be used to transfer data between the offline device 120 and each participant device 160, and the participant device 160 may transfer signature data to the online device 140 via different intermediate data storage devices, or both.

[0040] It should also be noted that Figures 1A-1BThe arrangement of components depicted is merely an example for illustrative purposes, but the disclosed embodiments can be equally applied to other arrangements of components. For example, in some embodiments, offline device 120 may be connected to some networks (e.g., a private local network) instead of other networks (e.g., the Internet). Specifically, according to the disclosed embodiments, offline device 120 is not connected to any network accessible to at least some other devices participating in the signing protocol. Therefore, in some embodiments, device 120 does not need to be an air-gap device.

[0041] In the various disclosed embodiments, the offline device 120 is not directly or indirectly connected to the Internet or otherwise exposed to one or more networks accessible to the online device 140, but the disclosed embodiments are not necessarily limited to this implementation. Furthermore, the offline device communicates indirectly with at least some of the other devices participating in the signing; that is, no direct communication or other connection to those online devices is established. To this end, in the various disclosed embodiments, one or more intermediate data storage devices are used to transfer data to and from the offline device.

[0042] Furthermore, it should be noted that, according to the disclosed embodiments, multiple online devices, multiple offline devices, or both can be participants in the disclosed digital signature process. Similarly, without departing from the scope of this disclosure, data can be transferred between offline devices and online devices via multiple intermediate data storage devices. A single online device, a single offline device, and a single intermediate data storage device are shown only for simplicity.

[0043] The above text is about Figure 1A The described interactions between components are now about Figure 2 Further explanation. Figure 2 This is a timing diagram illustrating the communication between offline device 120, intermediate data storage device 130, online device 140, and online platform 150.

[0044] At 210, offline device 120 is configured to perform relevant portions of the disclosed embodiments. Specifically, offline device 120 is configured to participate in secret generation (e.g., key, share, or both) and the single-round digital signature described herein. In an example implementation, the configuration at 210 may include installing software on offline device 120.

[0045] A process requiring a digital signature is initiated between online device 140 and online platform 150. As a non-limiting example, this process could be a transaction, such as one to be added to the blockchain, and the data could be transaction data. The data is checked to ensure it conforms to one or more signature policies. The process may also need to determine if the signature satisfies one or more signature policies.

[0046] At 230, when the data meets all applicable signature policies, the data is transferred to intermediate data storage device 130. At 240, the data is transferred from intermediate data storage device 130 to offline device 120. At 250, the data is verified and partially signed on offline device 120. At 260, the partially signed data is transferred to intermediate data storage device 130.

[0047] At 270, the partially signed data is transferred from intermediate data storage device 130 to online device 140. At 280, the partially signed data is uploaded by online device 140 to online platform 150. At 290, the partially signed data is stored, recorded, or otherwise finalized via online platform 150. In some embodiments, 290 includes adding the partially signed data to a distributed ledger such as a blockchain (not shown).

[0048] It should be noted that, Figure 2 For illustrative purposes only, communication between devices is not limited to... Figure 2 The specific communication illustrated above. As stated above, the disclosed signing process can occur between all offline devices (e.g., all devices offline regarding the internet or other networks). In these and other implementations, the device initiating the process requiring a digital signature may not actually participate in the signing process, but may simply act as a conduit for uploading the signature data.

[0049] Figure 3 This is an example flowchart 300 illustrating a method for signing data using a single-round multi-party computation protocol according to an embodiment. In one embodiment, the method is performed by devices participating in the signing, such as... Figures 1A-1B One of the 160 participants' devices, or one of the 120 offline devices and one of the 140 online devices.

[0050] In S310, select the first device secret key sk A In one embodiment, S310 may further include setting the key based on the first device secret key sk. A The calculated value sk A ·G's commitment, the first device secret key sk A The non-interactive zero-knowledge proof (NIZKPoK) or both are sent to the other participants who sign. Each other participant chooses a secret key. In one embodiment, the secret key chosen by the participants is selected from the same group.

[0051] Each signing party selects a unique "session ID" for share generation. The session ID can be represented as a function of a random string chosen by the participating participants' devices. When any participant needs a random oracle during share generation, it can instantiate a random oracle using functions such as, but not limited to, the HMAC function. The function used to instantiate the random oracle can be based on the session ID and a string unique to the protocol used.

[0052] In one embodiment, at least one participant signing is offline relative to the other participants signing. As a non-limiting example, such a participant could be... Figures 1A-1B Offline device 120. Offline device 120 is offline relative to the other participants in the signing, making it impossible for offline device 120 to communicate with the other participants in the signing via one or more networks (e.g., but not limited to the Internet). For this purpose, in one embodiment, the commitment is sent via, for example, one or more intermediate storage devices.

[0053] In S320, another participant in the data signing receives a second secret key sk selected by that other participant. B The calculated value of the promise and the second secret key sk B The NIZKPoK. As a non-limiting example, such an NIZKPoK can be created using the Fiat-Shamir heuristic. Participants interact to set up a secure multiplication protocol, for example, based on unintentional transmissions or homomorphic encryption. In one embodiment, commitments are received via, for example, one or more intermediate storage devices.

[0054] In S330, the first secret key sk will be used for... A The calculated value of decommitment and the first secret key sk A The NIZKPoK is sent to another participant who signed the data. This other participant stores the result of the secure multiplication protocol settings. In one embodiment, the release of the commitment and the NIZKPoK are sent via, for example, one or more intermediate storage devices.

[0055] In S340, the public key and secret share are stored. This public key is the same as the public key generated by other participants in the data signing process and can be computed as, for example, sk. A ·sk B ·G or (sk) A +sk B The secret share includes the secret output set by the secure multiplication protocol and the offline device secret key sk. A .

[0056] Each public key is generated by one party based on its corresponding secret share, thereby partially signing data using the secret share corresponding to the public key. Due to this correspondence, the secret share has the following property: if the secret share is to be assembled by a single system (which, according to various published embodiments, is impossible because the share is not exposed between systems), the secret share can be verified using the public key.

[0057] In S350, the data is partially signed using the secret share generated in S340. In one embodiment, the signature may follow the following... Figure 4 The process is described further. The data is partially signed such that one or more offline devices provide a portion of the overall signature, wherein the overall signature includes signature portions corresponding to the respective secret shares of each participating party.

[0058] In another embodiment, the signature protocol may further allow support for a deterministic key derivation process, such as BIP32 non-hardened derivation. To this end, in such an embodiment, the signature generated by each party to the digital signature is further generated based on a value δ determined via a deterministic key generator, where the value δ is known to all parties. In some implementations, S350 may include using the derived public key (as a predetermined function of the original public key) to check the resulting signature in order to verify, according to the disclosed embodiments, that the public key was generated using data from one or more offline devices. Any or all other parties to the signature can perform a similar check to independently verify the public key. The derived public key may be calculated, for example, as sk A·skB·G+δ·G or (sk A·sk B)·G+δ·G, where δ is defined according to the BIP32 standard.

[0059] It should also be noted that, in one embodiment, the secret share can be rotated in a manner consistent with the public key. This rotation can be performed between any two or more parties who wish to update their secret shares. Rotation involves creating new shares by rotating shares by each party; these new shares collectively form the same private key as shares previously created by that party, and may include, but is not limited to, generating derived shares or generating new shares independently.

[0060] It should also be noted that, for the sake of simplicity, Figure 3 The steps are described as a single process, but at least some steps can be performed separately in time from the other steps. Specifically, the data signing in S350 can occur at a time separate from the other steps S310 to S340.

[0061] In addition, in some implementation methods... Figure 3At least some steps can be performed multiple times in a chain or in parallel. For example, when multiple other participants are involved in the digital signature, the steps for determining the key and secret share can be performed multiple times, thus determining multiple secret shares. In this regard, it should also be noted that each party generates its own secret share, and no party knows the entire set of shares that will be used to sign the data. As a non-limiting example, if the customer SDK and MPC service provider systems will store shares, at least two shares are created. As another non-limiting example, if four systems will store shares, at least four shares are created. Each party's system creates one or more shares individually and independently of the other systems.

[0062] Figure 4 This is an example flowchart 400 illustrating a method for protecting digital signatures via MPC according to an embodiment. In one embodiment, participants and execution Figure 4 One of the methods in the system is offline device 120.

[0063] In S410, a request to sign a message is received. This request can be received from, for example, a user equipment. The request includes at least the data to be signed.

[0064] In S420, it is determined whether the requirements of the signature policy have been met. If so, proceed to S430; otherwise, terminate (not shown) or continue to S410 (shown). The signature policy includes rules for verifying authenticity. If the signature is approved, the verifier's (e.g., the service provider's) system will use its respective share to sign the transaction. The signature policy may also include additional requirements as described above. For this purpose, S440 may include communication with other systems to, for example, prompt other users to provide authentication and approval for the transaction.

[0065] In S430, the secret share is used to sign the data. In one embodiment, as described above... Figure 3 As mentioned above, a secret share is created.

[0066] The signing process involves using shares to run the MPC protocol as part of an interactive signing process. This interactive signing process involves each system running the MPC protocol using its own share. In one embodiment, each system partially signs the data using a distributed implementation of a digital signature algorithm (e.g., ECDSA / EdDSA / Schnorr), ensuring that the complete private key is never reconstructed on any one system. In another embodiment, during signing, no part of each system's share is exposed to other systems. As a non-limiting example, such a digital signature algorithm could be ECDSA, Edwards Curve Digital Signature Algorithm (EdDSA), Schnorr, etc. The security of the protocol can be proven based on cryptographic assumptions (e.g., discrete logs). To this end, the digital signature algorithm can utilize additional homomorphic encryption schemes and efficient zero-knowledge proofs to prove statements about elements from different finite groups without conveying other information about the elements.

[0067] In another embodiment, S430 further includes performing key derivation as part of the signing step without deriving the actual key separately. In this case, the parties can sign the message using a share of the key derived directly from a share of the original key.

[0068] In one embodiment, one or more systems participating in the signing are offline at least relative to other systems (i.e., not connected to a network, or more specifically, not connected to one or more networks used by other systems), and only one round of interaction is required during the signing of a portion of the signature from an offline system. It is important to note that even if the system storing the share is online, the share can be stored offline. For example, the share can be stored locally on the system in a location inaccessible via the network, making the share unavailable over the network.

[0069] Therefore, in another embodiment, S430 includes: receiving a message containing data required for offline device signing, signing the data using the offline device's secret share, and sending the message to one of the other participants to complete the signing (e.g., by adding another party's signature, uploading the signed data to an online platform, both, etc.). This signing by the offline device is performed in a single round, i.e., one message is transmitted to the offline device while another message is transmitted from the offline device. As described above, the transmission of data to and from the offline device can be accomplished by using an intermediate data storage device.

[0070] Performing partial signatures in a single round using one or more offline parties allows for minimizing offline device interactions, minimizing the exposure of offline shares, or both. Furthermore, by utilizing intermediate storage devices to communicate with offline devices, the data required for the interactive signature process can be transferred without exposing offline devices to the same network as other devices.

[0071] In some embodiments, one of the systems is offline, except during a limited number of interaction rounds (e.g., below a predetermined threshold). During those rounds, the offline system receives aggregated messages from the other systems. Each aggregated message includes information for a distributed implementation of the digital signature algorithm provided by all the other systems. The result of the interaction rounds can be used for multiple signature operations, each requiring only a single round of interaction with the offline device. In other words, by sending aggregated messages containing all the information needed by the offline system, the offline system can participate in signing without multiple rounds of interaction. As mentioned above, such rounds of interaction are particularly cumbersome when dealing with offline devices because data must be transmitted indirectly (e.g., via intermediate data storage devices).

[0072] The disclosed embodiments can also be used to provide such verified encrypted backups. To this end, in one embodiment, each party encrypts its secret share using a public-key cryptography scheme (e.g., RSA) and uses zero-knowledge proofs to prove that it has encrypted the correct value. As a non-limiting example, parties can use additional shares to generate a signing key, as follows: the i-th party selects a number xi and publishes xiG, where G is a generator in an elliptic curve for the digital signature. Note that x is hidden given xG, based on the security of the digital signature used. The public key for the digital signature will be x1G + x2G + ... = (x1 + x2 + ...)G. Furthermore, the i-th party encrypts xi using the public key encrypted in the backup and uses zero-knowledge proofs to prove that xiG and the encrypted backup use the same xi.

[0073] It should be noted that, in one embodiment, no part of any share is exposed to any system outside the system that generated those shares at any time. In other words, each system maintains its own shares and does not provide or otherwise expose them to other participating systems or other external systems. Because the shares are not exposed to other systems, the underlying private key cannot be reconstructed and used to fraudulently sign transactions.

[0074] It should be noted that the same key can be used to repeat this method, because the same key can be used to sign multiple messages.

[0075] Figure 5 This is an example schematic diagram of a participant device 500 according to an embodiment. The participant device 500 includes processing circuitry 510 coupled to a memory 520 and a storage device 530. In one embodiment, components of the participant device 500 may be communicatively connected via a bus 540. According to the disclosed embodiments, the offline device 120 of FIG1, the online device 140 of FIG1, or both may be configured as the participant device 500.

[0076] The processing circuit 510 can be implemented as one or more hardware logic components and circuits. For example, but not limited to, illustrative types of hardware logic components that can be used include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), graphics processing units (GPUs), tensor processing units (TPUs), general-purpose microprocessors, microcontrollers, digital signal processors (DSPs), and any other hardware logic components that can perform calculations or other manipulations on information.

[0077] The memory 520 may be volatile (e.g., random access memory, etc.), non-volatile (e.g., read-only memory, flash memory, etc.) or a combination thereof.

[0078] In one configuration, software for implementing one or more embodiments disclosed herein may be stored in storage device 530. In another configuration, memory 520 is configured to store such software. Software should be interpreted broadly as any type of instruction, whether referring to software, firmware, middleware, microcode, hardware description language, or others. Instructions may include code (e.g., source code format, binary code format, executable code format, or any other suitable code format). When executed by processing circuitry 510, these instructions cause processing circuitry 510 to perform the various processes described herein.

[0079] Storage device 530 may be a magnetic storage device, an optical storage device, etc., and may be implemented as, for example, flash memory or other memory technologies, optical disc-read-only memory (CD-ROM), digital multifunction disc (DVD), or any other medium that can be used to store the required information.

[0080] It should be understood that the embodiments described herein are not limited to those described herein. Figure 5 The specific architecture shown can be used in conjunction with other architectures without departing from the scope of the disclosed embodiments. Specifically, Figure 5 The offline device 120 shown is an air-gap device without any network interface. However, in some embodiments, the offline device 120 may include a network interface.

[0081] The various embodiments disclosed herein can be implemented as hardware, firmware, software, or any combination thereof. Furthermore, the software is preferably implemented as an application tangibly embodied in a program storage unit or computer-readable medium, which comprises some or some devices and / or combinations of devices. The application can be uploaded to and executed by a machine including any suitable architecture. Preferably, the machine is implemented on a computer platform having hardware such as one or more central processing units (“CPUs”), memory, and input / output interfaces. The computer platform may also include an operating system and microinstruction code. The various processes and functions described herein may be part of the microinstruction code or part of the application, or any combination thereof, which can be executed by the CPU, regardless of whether such a computer or processor is explicitly shown. Furthermore, various other peripheral units may be connected to the computer platform, such as additional data storage units and printing units. Additionally, a non-transitory computer-readable medium is any computer-readable medium other than transient propagating signals.

[0082] All examples and conditional language cited herein are intended for pedagogical purposes to aid the reader in understanding the principles of the disclosed embodiments and the concepts contributed by the inventors to advance the field, and should be construed as not being limited to such specifically cited examples and conditions. Furthermore, all statements herein listing the principles, aspects, and embodiments of the disclosed embodiments and their specific examples are intended to cover both their structural and functional equivalents. Moreover, such equivalents are intended to include both currently known equivalents and future-developed equivalents, i.e., any developed element that performs the same function regardless of its structure.

[0083] It should be understood that any reference to elements in this document using names such as "first," "second," etc., generally does not restrict the number or order of those elements. Rather, these names are generally used in this document as a convenient way to distinguish two or more elements or instances of elements. Therefore, referring to the first element and the second element does not mean that only two elements can be used there or that the first element must somehow precede the second element. Furthermore, unless otherwise stated, a group of elements includes one or more elements.

[0084] As used herein, the phrase “at least one” followed by a list of items means that any of the listed items may be used alone, or any combination of two or more of the listed items may be used. For example, if a system is described as including “at least one of A, B, and C”, then the system may include only A; only B; only C; 2A; 2B; 2C; 3A; combinations of A and B; combinations of B and C; combinations of A and C; combinations of A, B, and C; combinations of 2A and C; combinations of A, 3B, and 2C; and so on.

Claims

1. A method for digitally signing data, comprising: A first device among a plurality of devices generates at least one first secret share based on a secret key selected by the first device, the plurality of devices including the first device and a second device, wherein the first device is offline at least relative to the second device; The first device partially signs the data using the at least one first secret share, wherein the data is received from the second device via at least one first intermediate data storage device, without establishing direct communication between the first device and the second device; and Partially signed data is sent from the first device to the second device via at least one second intermediate data storage device without establishing direct communication between the first device and the second device, wherein the second device uses the partially signed data to generate signature data, wherein the signature data corresponds to a public key, wherein the public key is generated based on a plurality of secret shares including at least one first secret share and at least one second secret share, wherein the at least one second secret share is generated by the second device.

2. The method according to claim 1, wherein, In a single round of interaction with other devices among a plurality of other devices, the first device partially signs the data.

3. The method according to claim 1, wherein, Since the data is partially signed by the first device without revealing any part of the at least one first secret share to the second device, and since the signed data is generated by the second device without revealing any part of the at least one second secret share to the first device.

4. The method according to claim 1, wherein, The at least one second secret share is generated by the second device based on a secret key selected by the second device.

5. The method according to claim 1, wherein, The data is partially signed using a digital signature, and the method further includes: The digital signature is generated based on the data, the at least one first secret share, and a value determined via a deterministic key derivation process, wherein the value determined via the deterministic key derivation process is known for each of the plurality of devices.

6. The method according to claim 1, wherein, The first device is an air gap device that lacks a network interface.

7. The method according to claim 1, further comprising: The at least one first secret share is stored in the hardware security module.

8. The method according to claim 1, wherein, Each intermediate data storage device is any of the following: external hard disk drive, memory card, Fast Response Code, Universal Serial Bus key, Uniform Resource Locator, and sound.

9. A non-transitory computer-readable medium storing instructions thereon to cause processing circuitry to execute a process, the process comprising: A first device among a plurality of devices generates at least one first secret share based on a secret key selected by the first device, the plurality of devices including the first device and a second device, wherein the first device is offline at least relative to the second device; The first device partially signs the data using the at least one first secret share, wherein the data is received from the second device via at least one first intermediate data storage device, without establishing direct communication between the first device and the second device; and Partially signed data is sent from the first device to the second device via at least one second intermediate data storage device without establishing direct communication between the first device and the second device, wherein the second device uses the partially signed data to generate signature data, wherein the signature data corresponds to a public key, wherein the public key is generated based on a plurality of secret shares including at least one first secret share and at least one second secret share, wherein the at least one second secret share is generated by the second device.

10. A system for digitally signing data, comprising: Processing circuitry; as well as A memory containing instructions that, when executed by the processing circuitry, configure the system to: At least one first secret share is generated based on a secret key selected by the system, wherein the system is a first device among a plurality of devices, the plurality of devices including the first device and a second device, wherein the first device is offline at least relative to the second device; The data is partially signed using the at least one first secret share, wherein the data is received from the second device via at least one first intermediate data storage device, without establishing direct communication between the first device and the second device; and Partially signed data is sent to the second device via at least one second intermediate data storage device without establishing direct communication between the first device and the second device, wherein the second device uses the partially signed data to generate signature data, wherein the signature data corresponds to a public key, wherein the public key is generated based on a plurality of secret shares including at least one first secret share and at least one second secret share, wherein the at least one second secret share is generated by the second device.

11. The system according to claim 10, wherein, In a single round of interaction with other devices among a plurality of other devices, the first device partially signs the data.

12. The system according to claim 10, wherein, Since the data is partially signed by the first device without revealing any part of the at least one first secret share to the second device, and since the signed data is generated by the second device without revealing any part of the at least one second secret share to the first device.

13. The system according to claim 10, wherein, The at least one second secret share is generated by the second device based on a secret key selected by the second device.

14. The system according to claim 10, wherein, The data is partially signed using a digital signature, and the system is further configured to: The digital signature is generated based on the data, the at least one first secret share, and a value determined via a deterministic key derivation process, wherein the value determined via the deterministic key derivation process is known for each of the plurality of devices.

15. The system according to claim 10, wherein, The first device is an air gap device that lacks a network interface.

16. The system according to claim 10, wherein, The system is also configured to: The at least one first secret share is stored in the hardware security module.

17. The system according to claim 10, wherein, Each intermediate data storage device is any of the following: external hard disk drive, memory card, Fast Response Code, Universal Serial Bus key, Uniform Resource Locator, and sound.

Images