System and method for generating a signature

Abstract

Systems and methods for digitally signing a message using multi-party computation.

Description

[0001] Cross Reference to Related Applications

[0002] This application claims priority to U.S. Provisional Application No. 62 / 881,729, filed August 1, 2019, U.S. Provisional Application No. 62 / 881,711, filed August 1, 2019, and U.S. Provisional Application No. 62 / 946,912, filed December 11, 2019, which are incorporated by reference herein in their entirety. TECHNICAL FIELD

[0003] The present invention relates generally to the field of cryptocurrencies, and more specifically to new and useful systems and methods for generating signatures. BACKGROUND

[0004] Several cryptocurrency protocols require transactions to be signed for operations related to the management of the cryptocurrency protocol. Such transactions are often separate from transactions for the transfer of cryptocurrency assets. Such transactions are typically signed using a private key. However, accessing such private keys and using them for transaction signing increases the likelihood that the private key will be accessed by an unauthorized entity.

[0005] There is a need in the field of computer networking for new and useful systems and methods for secure transaction signing. The present disclosure provides such new and useful systems and methods. BRIEF DESCRIPTION OF DRAWINGS

[0006] Figure 1 is a schematic representation of a system according to a variant.

[0007] Figures 2A-2D is a representation of a method according to a variant.

[0008] Figure 3 is a representation of a method according to a variant.

[0009] Figure 4 is a representation of a method according to a variant.

[0010] Figure 5 is a representation of a system according to a variant.

[0011] Figure 6 is a representation of an exemplary key distribution flow according to a variant.

[0012] Figure 7 is a representation of an exemplary signature flow according to a variant.

[0013] Figure 8 is a representation of a single message signature key and participant group key generation flow according to a variant.

[0014] Figure 9is a representation of a message signing process according to a variant that uses a single message of a single message signing key.

[0015] Figure 10 is a representation of proactive secret sharing according to a variant.

[0016] Figure 11 is a flowchart representation of an instance of the method. DETAILED DESCRIPTION

[0017] The following description of the embodiments is not intended to limit the scope of the claims to these embodiments but is intended to enable any person skilled in the art to make and use the embodiments described herein.

[0018] 1. OVERVIEW

[0019] The method for distributed signature generation is used to limit information about the private key such that the private key need not exist in plaintext outside of key generation. The system and method enable cryptographic signatures to be generated with t out of n participants without requiring the signature private key to be in plaintext (e.g., reconstructed) to perform the signature.

[0020] All or part of the method can be performed by a remote computing system, a local participant system, a combination thereof, and / or any other suitable system. Communications between the systems can be signed (e.g., with a private key of an asymmetric key pair, with a symmetric key), encrypted, and / or otherwise authenticated and / or secured.

[0021] In some variants, the quorum of signers (t out of n) must collaborate to produce a valid signature, and no malicious adversary group can obtain useful information about the private key without access to at least t signers and keyshare ciphertexts. In some variants, asynchronous signing is provided, where the default signer can be offline and only come online when an action is to be taken. Variants utilize a trusted key generation and keyshare issuance ceremony to distribute the secret to the signers and utilize an online centralized server to manage the protocol state. In some variants, the signing key (e.g., private key) is generated in an offline key generation ceremony.

[0022] In some variants, the signing system (e.g., 110) is used to sign transactions. In some variants, the signing system includes at least one of the following: an application programming interface (API) system (e.g., 113); an issuer system (e.g., 111); a message signing system (e.g., 112); and at least one participant system (e.g., 114a-114c). Figure 1 In some variants, the method (e.g., 100) is used to sign transactions. In some variants, the signing system (e.g., 110) is used to sign transactions. In some variants, the signing system includes at least one of the following: an application programming interface (API) system (e.g., 113); an issuer system (e.g., 111); a message signing system (e.g., 112); and at least one participant system (e.g., 114a-114c).

[0023] Figure 2A ​The illustrated 200) includes at least one of: generating a private key (e.g., S210); generating a signing secret using the generated private key (e.g., S220); and processing a signing request using the stored signing secret (e.g., S230). In some embodiments, at least one component of a signing system (e.g., 110) performs at least a portion of the method (e.g., 200).

[0024] In one example, the method can include, at an issuer system, generating a signing key (message signing key), splitting the signing key into encrypted secret shares to different participants, and uploading the encrypted secret shares to a message signing system. To sign a message, the method can include, with a first quorum of participants, generating a nonce for the message to be signed based on respective secret shares (e.g., using a distributed key generation method), splitting the nonce into encrypted nonce shares to different participants, and uploading the encrypted nonce shares to the message signing system; and at each of a second quorum of participants, generating a partial signature from the nonce share encrypted to the respective participant and uploading the partial signature to the message signing system; the partial signatures are then aggregated into a signature that is verified (e.g., by the participants, the message signing system, etc.) under an aggregated public key (PK), where the message can be signed with the signature and optionally sent to a respective blockchain network. Each participant of the first quorum can generate the nonce, partial nonce, or other data that is subsequently split, encrypted, and uploaded. Generating a partial signature at each participant of the second quorum can include: downloading and decrypting the encrypted nonce share to them; downloading and decrypting the encrypted signing key share to them; optionally verifying the validity of the encrypted data in total; combining the decrypted nonce shares into a single nonce share; and using the key and nonce share to create the partial signature. This example can be coordinated by a message signing system, which can serve as a shared data store and state machine coordinator, and can not see the private signing key and / or nonce values.

[0025] In a second example, the method includes generating a signing key sk and splitting sk into key shares using an n-of-t split construction; at each participant system of a first quorum of at least t participants, generating a nonce r i based on randomness and the key shares, and splitting the nonce into nonce shares using the same n-of-t split construction; at each participant system of a second quorum of at least t participants, retrieving the key shares of the at least t nonces and the nonce shares (from the first quorum), generating an aggregated nonce, and generating a partial signature based on a message, the key shares, and the aggregated nonce; and reconstructing a signature for the message based on the at least t partial signatures.

[0026] 2. Benefits

[0027] This approach can bring several benefits compared to traditional systems and methods.

[0028] Messages (e.g., cryptocurrency transactions) can be signed without exposing the private key of a cryptocurrency wallet. Instead, the private key is split into shares, which are used to generate partial signatures, and the partial signatures are combined to generate a signature for the message. The system that generates the partial signatures does not need to have access to the complete private key, and the system that combines the partial signatures does not need to have access to the shares of the private key or the complete private key to generate a complete signature for the message.

[0029] Messages can be signed by using an online system. Since the complete private key is not needed to sign a message, the signing can be performed by an online system that has access to the shares of the private key or the partial signatures. There is no need to reconstruct the private key in a secure offline environment to perform the signing. This also enables the private key to be reused for multiple signatures.

[0030] Security can be improved by distributing the signing process among multiple systems, rather than delegating the signing to a single trusted system.

[0031] Variations of the system and method enable valid signatures to be generated without message signing key reconstruction. In variations that utilize Shamir’s Secret Sharing (SSS) to split the message signing key, the message signing key can be reconstructed using a linear combination of the shares generated by SSS as long as t shares out of n are available. This allows any participant to construct a valid signature as long as t partial signatures out of n, generated using the same message (m) but different message signing key shares, are available. For signing protocols that require one or more pieces of additional signing data (e.g., ephemeral numbers), the additional signing data can be co-generated, especially when one or more participants each determine a respective piece of additional signing data from a respective private key share and / or the message (e.g., by generating data using a random value, hashing the private key share and the message, etc.). Furthermore, when the additional signing data itself is split using SSS (e.g., with the same t out of n configuration), its shards can also be linearly combined with shards of additional signing data generated using different message signing key shares, such that partial signatures generated using shards from multiple pieces of additional signing data (each generated from a different message signing key share) can be aggregated with other partial signatures (generated in the same manner) to generate a valid signature.

[0032] The systems and methods disclosed herein can provide additional benefits.

[0033] 3. System

[0034] The signature generation method is preferably performed with the signature system 110, but can alternatively be performed with a different system. The signature system 110 is preferably used to facilitate message signing. In a first variant, the signature system 110 is used to sign a message (e.g., a cryptocurrency transaction). In a second variant, the signature system 110 is used to coordinate signature generation for a message. For example, the signature system 110 can be used as a shared data store, as a state machine coordinator to verify a requesting or sending participant’s authorization key signature, or to perform other functions. The signature system is preferably blind to (e.g., does not know, cannot access) the message signing key (private signing key) and / or ephemeral value, but can alternatively be used as a participant or otherwise involved.

[0035] The message is preferably a blockchain message that is compatible and verifiable with the respective blockchain to which the signed message is sent, but can alternatively be data or other message. The message can be: a transaction message, a governance message (e.g., for staking, delegation, voting, etc.), and / or other message. The message can be generated by: a platform, a dApp (distributed application), an exchange, a client, and / or any other suitable system. The message can be associated with a signature verification key PK, an address generated from PK, and / or any other suitable address or message signing key identifier.

[0036] The signature system 110 is preferably used with a set of keys that can be used for authorization or verification, encryption, signing, or otherwise. Examples of keys used with the signature system 110 include: a message signing public key (PK) (signature verification key) used to verify a final signature (e.g., generated from a signing private key, paired with a signing private key (sk)); a message signing private key (sk); a key generation integrity key (PK KG ) or public-private key pair (PK KG , sk KG ) that can be used by a participant system to confirm an encryption key share provided by a known key generation system (e.g., an issuer system 111) or process; a server authentication key (AK S ) or public-private key pair (AK S , ak S ), where AK S can be used by a participant to verify they are communicating with the correct message signing system 112; a participant authentication key (AK Pi ) or public-private key pair (AK Pi , ak Pi ), where the public key AK Pi can be used to authenticate a participant system to servers and other participants; a participant encryption key (ENK Pi) or a public-private key pair (ENK Pi , enk Pi , respectively, of participant i Pi , enc Pi ), where the public key ENK Pi can be used by other participants to encrypt data to the receiving participant; one or more ephemeral issuer keys (EK I ) used to encrypt a share of the signing private key (sk) to each participant system; one or more participant ephemeral keys (EK P ) created by a participant system when encrypting data to another participant; and / or other keys.

[0037] Message signing keys (e.g., public and / or private keys) can be keys that conform to any suitable message signing format or protocol. Examples of cryptographic currency signing schemes that a signing key and / or resulting signature can be compatible with include: DSA signing schemes, ECDSA signing schemes, EdDSA signing schemes (e.g., Ed25519, Ed448, etc.), pairing-based schemes (e.g., BLS), Schnorr, RSA, ring signatures, and / or any other suitable cryptographic currency signing scheme (e.g., public key algorithm). Additional signing data is generated when a cryptographic currency signing scheme requires additional signing data in addition to a private key and a message (e.g., an ephemeral number). The signing system 110 can be compatible with one or more cryptographic currency signing schemes. When the signing system 110 is compatible with a single cryptographic currency signing scheme, the system can include a different signing system 110 implementation for each cryptographic currency signing scheme. In some variations, the message signing private key is a sequence of randomly generated bytes. In some variations, S210 includes extracting 32 bytes of random data from a cryptographically secure random data source.

[0038] In some variations, the keys PK KG , EK I , EK P are ephemeral keys. In some variations, the key PK is an Ed25519 key. In some variations, the keys PK KG , EK I , AK P , ENK P , EK P , and AK S are NIST-P256 keys.

[0039] In one variation, a platform account (e.g., an institution, an individual, etc.) can be associated with a participant group that includes n or more participant key sets (e.g., where a participant key set can include AK Pi , ak Pi, ENK Pi , enk Pi ), a set of participant keys held by participants (e.g., institution employees) to which the platform account belongs. A participant group (and / or platform account) can be associated with one or more message signing keys, where t participants out of n from the participant group can cooperatively sign a message that can be verified to a public message signing key (PK). Each message signing key can be associated with a key generation integrity key (PK KG ) associated with (and / or identifying) a key generation ceremony that generated the respective message signing key.

[0040] All or part of the keys can be generated by: an issuer system, a participant, and / or otherwise. When all keys are generated by a single system (e.g., an issuer system), the keys are preferably distributed to participants (e.g., users). The keys are preferably generated offline (e.g., in a system isolated from the internet or other communication networks), but can alternatively be generated online. The key distribution preferably occurs offline (e.g., an HSM with the keys is physically or manually delivered to the participant), but can alternatively occur online (e.g., transferred over a secure communication channel). The plaintext version of the keys are preferably destroyed after the keys are stored, but can alternatively be retained otherwise. The keys can be generated synchronously (e.g., during the same ceremony) or asynchronously (e.g., during different ceremonies). In a first instance, all keys are generated during the same ceremony. In a second instance, the message signing keys for a group of participants are generated after the authentication and encryption keys for the participants are generated. However, the keys can be generated otherwise.

[0041] The signing system 110 is preferably connected with one or more blockchain networks (e.g., via one or more blockchain nodes hosted by the signing system 110 or a connection system). The blockchain networks are preferably compatible with the message signing protocol supported by the signing system 110, but can alternatively be incompatible. Examples of blockchain networks include UXTO model protocols (e.g., Bitcoin, etc.); account model protocols (e.g., Ethereum, ERC20 tokens such as USDC, Litecoin, etc.); and / or other protocols.

[0042] The signing system 110 preferably includes at least one of: an issuer system 111; and a message signing system 112. In a variant, the message signing system 110 can optionally include: an application programming interface (API) system 113; at least one participant system 114 (examples 114a-c).

[0043] In variations, the issuer system 111 functions as a secure key generation system (e.g., for generating one or more of a message signing key pair, an authentication key pair, an encryption key pair, etc.). The issuer system is preferably a centralized processing system (e.g., a remote computing system, a cloud system, a server system, etc.), but can alternatively be a distributed computing system. The issuer system can be an offline system that is not affected by public communication networks.

[0044] In some variations, the issuer system 111 performs one or more offline key generation processes. Additionally or alternatively, the issuer system 111 can perform one or more online key generation processes. In some variations, the issuer system 111 is used to generate a signing private key during an offline key generation ceremony. In some variations, the issuer system 111 also generates a plurality of participant keys during the key generation ceremony. In some variations, the issuer system 111 provides the participant keys to the participant systems 114a-c (or users of the participant systems). Alternatively, the participant keys can be generated prior to the key generation ceremony, where the participant keys are provided to the key generation ceremony for use.

[0045] The issuer system 111 can generate (e.g., in one or more key generation ceremonies) one or more of the above-described keys. Alternatively, the keys can be generated by a different system. In some variations, the issuer system 111 provides each key AK P , ENK P to a respective participant system (e.g., 114a-c). In some variations, the issuer system 111 provides the key AK S to the message signing system 112.

[0046] In some variations, the message signing system 112 is used to coordinate and maintain protocol state, and to track data provided to participant systems for generating signatures. The message signing system 112 can: identify participants associated with a public signing key (PK), identify encryption signing key shards associated with the public signing key (c i ), receive encrypted ephemeral number shares from a first quorum of participants, distribute encrypted encrypted ephemeral number shares to requesting participants, aggregate partial signatures, sign a message or distribute partial signatures to participants for message signing, authenticate each message received from a participant, and / or perform other processes. The message signing system is preferably a centralized system controlled by a platform or centralized service, but can alternatively be a distributed system or other system.

[0047] Application Programming Interface (API) system 113 is used to receive pre-defined calls to signature system 110, which can then be sent to and completed by issuer system 112, participant system 114, and / or other systems. Examples of calls include key generation requests, message signing requests, and / or other requests.

[0048] The signature system 110 is preferably connected to a set of participant systems. Alternatively, the signature system 110 may include participant systems. Each participant system 114a to 114c is used to perform at least one process for generating a signature.

[0049] The participant system is preferably a remote computing device associated with (e.g., controlled by) a participant, but may alternatively be local and / or otherwise associated with the signature system 110. Examples of participant systems include: Hardware Security Modules (HSMs), secure cryptographic processor chips, laptops, smartphones, mobile devices, tablets, smartwatches, desktop computers, servers, and / or other computing systems. The participant system may include a processing system and memory (e.g., storing the participant's private key and other participants' public keys). In some embodiments, at least one participant system is a device with a persistent network connection (e.g., connected to the Internet) (e.g., an Internet-connected mobile device) and optionally includes a notification module for receiving asynchronous notifications (e.g., notifications of authorized input, etc.). In some embodiments, at least one participant system is a device with an intermittent network connection (e.g., connected to the Internet) (e.g., a laptop computer that connects to the network only when it is powered on and not in sleep mode).

[0050] Participants (e.g., users, personal accounts, etc.) are preferably part of a participant group, where the participant group is associated with a platform account (e.g., associated with an entity). A given participant may be associated with one or more participant groups.

[0051] Each participant system can store a set of participant keys, which may include: participant authentication keys (AK keys for participant i). Pi ak iPi ) and participant encryption keys (ENK of participant i respectively) Pi enk Pi Or respectively for participant i's ENC Pi enc pi However, it can also be associated with other keys, either additionally or alternatively. Participant systems may optionally store public keys for message signing systems (e.g., servers, central systems), issuers, and / or other systems.

[0052] In some variations, the participant system includes both a human-managed participant system and a server-managed participant system of the signature system 110. In some variations, the server-managed participant system is used to enhance security. By using a server-managed participant system, the person managing the human-managed participant system does not need to be trusted. Users of the server-managed participant system can prevent attacks (where a group of malicious human participants collude to attempt to reconstruct the signing private key). In some variations, for an attack to succeed, thresholds in both the human-managed and server-managed participant systems need to be broken.

[0053] In some variations, one or more of the system components are implemented as hardware devices (e.g., Figure 5 The device 500, as shown, includes one or more of a processor (e.g., 503a to 503n), a display device (e.g., 591), a memory (e.g., 522), a read-only memory (ROM) (e.g., 504), a storage device (e.g., 505), an audible output device, an input device (e.g., 581), an output device, and a communication interface (e.g., 511). In some variations, one or more components included in the hardware device are communicatively coupled via a bus (e.g., 501). In some variations, one or more components included in the hardware device are communicatively coupled to an external system via a communication interface.

[0054] The processor may include one or more of a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), an NPU (Neural Processing Unit), and any other suitable processing system for executing machine-readable instructions. In a variant, at least one of the processor and memory may be included in the processing unit (e.g., 599).

[0055] Communication interfaces are used to transfer data between hardware devices and other devices via networks (e.g., private networks, public networks, the Internet, etc.).

[0056] The storage device may include machine-executable instructions (and optionally data) for one or more of the operating system 530, application 513, and device driver 514.

[0057] In some variations, the storage device includes machine-executable instructions for performing at least a portion of the methods 200 described herein.

[0058] In some variations, at least one component of the system performs at least a portion of the method 200 described herein.

[0059] 4. Methods

[0060] Figures 2A-2Dis a flowchart representation of method 200. In some variations, method 200 includes at least one of: generating a private key S210; generating a signing secret by using the generated private key S220; and processing a signing request by using the stored signing secret S230. In some embodiments, at least one component of signing system 110 performs at least a portion of method 200. All or portions of the method can be performed automatically (e.g., without user input), manually, in response to user input (e.g., user approval, user connection of a respective participant system to the network, etc.), or otherwise.

[0061] The method can utilize verifiable secret sharing in one or more steps of the method. VSS can be used to provide proof (VSS) while providing secret sharing (e.g., secret sharing of a message signing key, secret sharing of a nonce), which allows a recipient to verify that it was fairly generated, and that the sender or system that generated the proof knows the shared secret. In variations, VSS can be used as a secret key proof of knowledge (KOSK), i.e., the system that generated the proof knows the discrete log of the public key for which it is creating the proof. In one instance, a signing secret share proof is a set of commitments to the coefficients of a sharing polynomial used to split a message signing key into shares, and is generated with {Vj = ajG}j∈[t]. To verify the proof, a verifier (e.g., a recipient) with a share (s i ) of the message signing key k i or nonce) checks for equality of the following equations: (For t participants), and / or verifies that the provided PK equals the free coefficient commitment V k，0 .

[0062] The method can utilize mutual authentication in one or more steps of the method. In variations, a recipient and a sender (e.g., a participant and a server) are able to authenticate each other by signing request and response payloads with respective authentication keys (e.g., ak Pi or ak S , respectively). In a particular instance, a participant making a request to a server must sign the full payload with its participant authentication key, where the server must verify that the signature is valid and belongs to a known participant before proceeding. In this instance, a response payload from the server must be signed with the server authentication key, where the participant must verify that the signature is valid and matches the known server authentication key before proceeding. Similarly, a recipient participant must verify that the sending participant’s signature is valid before proceeding. However, messages can be authenticated in other ways as well.

[0063] The method can utilize an authenticated key exchange (AKE) and / or authenticated encryption with associated data (AEAD) in one or more steps of the method (e.g., for all communications between the two parties). This can enable secret data (e.g., nonce, other signing secrets) to be shared with the participants such that only the sender and receiver know the plaintext content and can verify the participant that created it. In a particular instance, this can be achieved by deriving a shared secret with the AKE and encrypting the shared secret with the AEAD. However, this can also be achieved in other ways.

[0064] In an instance, for a sender P i and a receiver P j , the AKE can include:

[0065] DH1 = DH(AK Pi , EK Pj )

[0066] DH2 = DH(EK Pi , AK Pj )

[0067] DH3 = DH(EK Pi , ENK Pj )

[0068] secret encryption key = KDF(DH1 || DH2 || DH3)

[0069] where the secret encryption key is a symmetric key used to encrypt the message. The receiver can independently derive the secret encryption key (e.g., using the same method, with their information), and decrypt the ciphertext received from the sender. In this instance, (AK Pi , EK Pi ) can be the authentication key and the random nonce key for the message for participant i, respectively, and (AK Pi , EK Pi ) can be the authentication key and the encryption key for participant j, respectively. DH1, DH2, and DH3 can be generally represented as DH(PK1, PK2), where PK1 and PK2 are generic placeholders. DH(PK1, PK2) can represent a shared secret from the Elliptic Curve Diffie-Hellman (ECDH) function between keys (PK1, sk2) and (PK2, sk1) from (public, private) key pairs (PK1, sk1) and (PK2, sk2), and where KDF(k) computes a specified number of output bytes from an HKDF (Hash-based Key Derivation Function) that accepts an arbitrary size byte sequence as input, and where EK Piis a temporary key of the sending system. However, any other suitable key exchange method can also be used. Alternatively, a one-time key and / or a signed pre-key can be used. The key can be static (e.g., not rotated periodically, which minimizes the number of keys that participants need to keep track of and reduces the need to retain large numbers of keys, re-encrypt old data to new keys, and / or burn previously encrypted data at rotation) but can alternatively be rotated (e.g., using proactive secret sharing or another method).

[0070] When using AEAD, the ciphertext can include associated data of the plaintext. The associated data can include a public authentication key for simple identification of who the message is related to. The associated data can optionally include information about the message content (e.g., a type of ciphertext, such as an identifier of a nonce, a different identifier of a signing key, etc.; a protocol version), and / or other information. For example, a symmetric secret key generated using AKE can be used to encrypt the message: encrypt(sk, message, AK Pi ||AK Pj ).

[0071] The method can utilize a distributed signature data generation protocol (e.g., a distributed signature generation protocol, a distributed key generation protocol, a distributed nonce generation protocol, etc.) in one or more steps (e.g., additional data generation). This can include sending a share of secret data (e.g., a message signing key, a nonce) to other participants, where the other participants perform a computation, sharding, and encrypt the result to the other n participants and return the encrypted shards. For example, this can include having each participant generate a nonce and create a share thereof to send to the other participants.

[0072] Throughout the method, a plaintext version of some or all of the secret data (e.g., a message signing key, a message signing key share, a nonce, etc.) can be deleted or otherwise managed after encryption.

[0073] A private key S210 is generated for generating a message signing private key (sk). In a first variant, the issuer system 111 performs S210 (e.g., in a secure offline key generation ceremony). In a second variant, one or more systems perform a distributed key generation process (e.g., an online process, such as using a threshold signature method) to generate the message signing private key. However, the message signing private key can be generated in any suitable manner.

[0074] In some variations, the private key is converted to an extended private key (epk) (S211). In some embodiments, the extended private key is an extended private key of a key pair for Ed25519 signatures. Alternatively, the private key can be a private key of a key pair for any suitable type of signature. In some variations, converting the private key to the extended private key includes hashing the private key with SHA512 and extracting the first 32 bytes of the hash output as a digest; and altering some bits of the digest, where the altered digest is the extended private key. However, the key generated at S210 can conform to any suitable format or protocol.

[0075] In some embodiments, S210 includes generating a signature verification key (S212). In some embodiments, the signature verification key is a public key (PK) of a key pair including a message signing private key (sk), and the public key is used to verify a signature generated using the message signing private key.

[0076] In some embodiments, the extended private key (generated at S211) is used to derive the signature verification key (e.g., PK). In some embodiments, deriving the signature verification key includes performing scalar multiplication on the extended private key. In some embodiments, the scalar multiplication is performed using a base point according to the following equation: dG = Y, where d is the extended private key, G is the base point, and Y is the public key (PK). However, the signature verification key can also be generated in other ways.

[0077] S210 can be performed at a predetermined time or at any other suitable time when key generation is requested, in response to a key distribution request (e.g., as shown in Figure 6 Each instance of S210 is preferably performed for a particular group of participants, where the participant identities (e.g., the set of participant keys) and the split-reconstruction configuration (e.g., t and n for an n-of-t quorum; SSS parameters; etc.) are known prior to or generated during the key generation ceremony. In variations, S210 includes selecting a group of participants including n participants. The group of participants can be selected at any suitable time (e.g., prior to or after receiving the key distribution request). In some embodiments, the group of participants is selected based on one or more of user input, configuration information, or in any suitable manner. In some embodiments, the group of participants is identified based on a platform account (e.g., associated with the key distribution request). However, S210 can also be performed in other ways based on any other suitable data.

[0078] In some variations, as shown in Figure 6 the client system (e.g., Figure 1The illustrated external system 104) sends a request to a system (e.g., issuer 111, message signing system 112) to assign a message signing private key for a user account associated with a client system (e.g., cold storage system). In some embodiments, the key assignment request is signed by a private authentication key of the client system (e.g., 104). In some variations, in response, the system associates the message signing private key with an authentication public key of the client system that corresponds to the authentication private key. In some variations, the system can optionally provide a notification to the client system that the message signing key has been assigned to the authentication public key, provide the message signing public key to the client system, and / or provide any other suitable response. In some variations, further requests to use the assigned message signing private key are authenticated by verifying that the request was signed with the authentication private key of the client system. However, any other suitable process can also be used for key assignment.

[0079] The method can optionally include generating a communication key (e.g., an authentication key, an encryption key, an integrity key, etc.) (e.g., at S222, S223, and S224) that is used to securely provide the signing secret (and additional signing data) to the participants (via the participant systems 114a-c) and that is used to securely provide the additional signing data and the partial signature to the message signing system 112. In variations, the generated communication key is used to provide secure broadcast communication between the participant systems and the message signing system 112 (and optionally, the issuer system 111). In some embodiments, at least a portion of the communication key is generated during the generation of the signing secret S220. However, the communication key can also be generated at any suitable time (e.g., before receiving the message signing request, after receiving the message signing request but before splitting the message signing key into shares, after splitting the message signing key into shares, etc.). In some embodiments, the issuer system 111 generates at least a portion (e.g., all or some) of the communication key. However, any suitable system (or combination of systems) can also generate the communication key (e.g., at S222, S223, and S224).

[0080] The communication key can be securely distributed to one or more of the message signing system 112 and the participant systems 114a-c in any suitable manner. In some variations, at least a portion of the generated communication key (e.g., a private key or a corresponding public / private key pair) is injected into one or more HSM (hardware security module) devices. Such HSM devices can then be communicatively coupled (or electrically coupled) to the respective participant systems (or the message signing system 112). Additionally or alternatively, one or more communication keys can be encrypted with an import key for later import into a target system (e.g., a participant system, a message signing system).

[0081] In the variant, generating a communication key includes generating one or more of the following: generating an authentication key, generating an encryption key, and generating an integrity key.

[0082] In some implementations, generating the authentication key S222 includes generating a public key and a private key pair. In some implementations, S222 includes generating a public authentication key (AK) for the message signing system 112. s ) and private authentication key (ak) s The server authentication key pair. In some variants, the server's public authentication key (AK) is used. s ) and private authentication key (ak) s The message signature system 112 provides the message signature. In some implementations, S222 includes generating a public authentication key (AK) for each participant system p (e.g., 114a to 114c). p ) and private authentication key (ak) p The participant authentication key pair. In some variations, this includes the participant system public authentication key (AK). p ) and private authentication key (ak) p Each authentication key pair is provided to the associated participant system p (e.g., 114a to 114c).

[0083] In some variations, generating participant encryption keys S223 includes generating a public encryption key (ENK) for each participant system p (e.g., 114a to 114c). p ) and private encryption key (enk) p The participant's cryptographic key pair. In some variations, this includes the participant's system public cryptographic key (ENK). p ) and private encryption key (enk) p Each participant's encryption key pair is provided to the associated participant system p (e.g., 114a to 114c).

[0084] In some variations, generating an integrity key S224 includes generating a key generation integrity key. In these variations, the key generation integrity key can be used to verify the identification of the system (or multiple systems) that generated the message signing key (or key share). In a first instance, the key generation integrity key identifies the issuer system 111 as the source of the message signing private key (and key share). In a second instance, the key generation integrity key identifies the participants used during the distributed key generation ceremony used to generate the message signing private key (and key share). In these variations, the signature secret is considered valid if the corresponding ciphertext is decrypted using the key generation integrity key. In some implementations, S224 includes generating a key generation integrity key pair, which includes a public key generation integrity key (PK).KG ) and private key to generate integrity key (sk KG The key generation integrity key may be generated before or during the key generation ceremony (e.g., and used to encrypt message signature key shares during the key generation ceremony), or after the key generation ceremony.

[0085] The signature secret generation process S220 is used to generate signature key fragments, each of which is encrypted to a specific participant. In the first variation, the issuer system 111 performs S220. In the second variation, one or more systems perform a distributed process (e.g., an online process) to generate the signature secret. However, the message signature secret can be generated in any suitable manner.

[0086] Generating a signature secret may include splitting the message signature key S221 and encrypting the share S225, but may also include any other suitable process additionally or alternatively.

[0087] S220 may include S221, which is used to split the message signing key. In a first variation, splitting the message signing key includes splitting the message signing private key (sk) generated at S210. In a second variation, splitting the message signing key includes splitting the extended private key (epk) generated at S211.

[0088] In some variations, the message signing key is split into n shares or fragments (k1…k). n ), where t shares out of n are needed to recover the message signing key. In a variant, the number n is a predefined number (e.g., a configurable number, a hard-coded number, etc.). Alternatively or additionally, the number n can be specified in the key allocation request (e.g., as shown in the previous example). Figure 6 (As shown) or otherwise determined. The message signing key can be split using Shamir's Secret Share (SSS) or another secret share algorithm. In a specific instance, Shamir's secret share process is performed on a number (Z... q The operation is performed over a finite field of modulo, where the modulo is the order (q) of the base point (G) of the elliptic curve used to generate the public key (PK). However, the message signing key can be split in any suitable manner.

[0089] In some implementations, S221 includes generating a signature secret share proof for the message signing key share. The signature secret share proof is a set of data used to verify that the message signing key share is indeed a share of the message signing key. By using the signature secret share proof, the recipient of the signing secret (generated at S220) can verify that the share is a valid share of the message signing private key. Preferably, VSS is used to generate the proof, but any other suitable proof algorithm may also be used alternatively. Preferably, the message signing key (sk) or the extended signing key (epk) is used to generate the proof, but any other suitable data may also be used alternatively.

[0090] This proof can be generated simultaneously, before, or after splitting the message signing key using the same or different instances of the message signing key. In one instance, the signing key (sk or epk) is split into t shares out of n. The VSS proof, in which the secret signature proof is represented as:

[0091] In some implementations, the verifiable secret sharing process is carried out in a number (Z) q The process is performed over a finite field of the modulus, where the modulus is the order (q) of the base point (G) of the elliptic curve used to generate the public key (PK). In some implementations, the Verifiable Secret Share (VSS) procedure is a Pedersen-based verifiable secret share procedure. In some implementations, the Verifiable Secret Share (VSS) procedure is any suitable type of secret share procedure.

[0092] In some implementations, share (k) i …k n ) is encoded in big-endian bytes, such as s i =y i ||x i , where y is encoded using a fixed bit length in the range [0, q) and x is a single byte in the range [1, n+1], where "x||y" represents the concatenation of byte sequences x and y, and where q is the order of the base point (G) of the elliptic curve used to generate the public key (PK). However, shares can be encoded in any suitable manner.

[0093] Encryption share S225 is used to encrypt each message signing key share to a specific participant. The share can be encrypted to the participant in a 1:1, 1:m, or m:1 share:participant relationship, or any other suitable relationship. In some variations, encrypting the share at S225 includes encrypting the share (k1…k) generated at S221. n To generate encrypted shares (c1…c n Each encrypted share ci Preferably, it is encrypted to a different participant (e.g., where the group of participants includes n participants), but it can also be encrypted to a participant who shares it with another encrypted share.

[0094] The encrypted share S225 may include: identifying the participant to be encrypted; determining the participant key set (or its public key) associated with the identified participant; and using the participant key set to encrypt the message signing key share.

[0095] Participants can be identified in any suitable manner. In some implementations, this is based on configuration, hard-coded data, or via a key distribution request (e.g., Figure 6 The key distribution request shown receives one or more of the data to identify the participants.

[0096] In a variant, identifying participants includes identifying participant systems for each identified participant system (e.g., 114a to 114c). Identifying participant systems may include identifying one or more of the following for each participant system: message signature application endpoint identifier (e.g., an application layer identifier identifying a process running on the participant system), physical layer network address (e.g., MAC address), network layer address (e.g., IP address), port number (e.g., TCP port number), session identifier, communication link identifier (for persistent communication links), security token, participant identifier (e.g., username, login credentials, etc.), account identifier, etc. However, participant systems and participants may also be identified in other ways.

[0097] The participant key set can be retrieved from storage (e.g., local storage, remote storage), received from the participant, or otherwise determined.

[0098] In the variant, the participant key set includes the participant system public authentication key (AK) for each identified participant. p ) and public encryption key (ENK) p At least one of them.

[0099] In some implementations, the encrypted share includes, for each share, generating an integrity key (PK) using the participant's public authentication key, the participant's public encryption key, and the public key. KG (For example, as the sender's authentication key) Encrypt this share into participant i to generate an encrypted private key share (c i). In some variations, each share is encrypted to a particular participant. In some variations, each share is encrypted to a particular set of participants, where encrypting a share to a set of participants includes encrypting the share to each participant in the set of m participants (thereby generating m encrypted versions of the same share). The share can optionally be encrypted based on additional information, such as an identifier of the key share (e.g., a ciphertext type), a public key of a key generation integrity key, a public authentication key of a participant, a signing public key, a VSS proof, and / or any other suitable additional information. The additional information can optionally be used to verify or identify the encrypted private key share.

[0100] In some embodiments, encrypting the shares includes, for each share (s i ), encrypting the share by using a public authentication key (e.g., PK KG ) of a sending system (e.g., the issuer system 111) that sent the share, a public authentication key (e.g., AKpi) of a participant (e.g., participant p i ) that received the share, a public encryption key (e.g., ENK pi ) of the participant, and optionally a public ephemeral encryption key (e.g., EK i ) generated by the sending system. In an example, the foregoing keys are used to generate an encryption key (e.g., a symmetric key) that is shared between the sending system and the respective participant. In an example, each share is encrypted to a particular participant using AKE and AEAD, but can also be encrypted in any other suitable manner.

[0101] In a particular example, generating an encryption key that is shared between the sending system and the respective participant includes performing an Elliptic Curve Diffie-Hellman (ECDH) procedure by using the public key generation integrity key (PK KG ) as a public key of the issuer system 111 and by using the public authentication key (AK p ) generated for the participant system at S222, thereby deriving the encryption key.

[0102] In some embodiments, generating an encryption key that is shared between the sending system and the respective participant is performed as follows:

[0103] DH1 = DH(PK KG , ENK P )

[0104] DH2 = DH(EK I , AK p )

[0105] DH3 = DH(EK I, ENK P )

[0106] Shared encryption key = KDF(DH1||DH2||DH3)

[0107] In some embodiments, PK KG , ENK P , EK I , and AK p are all public keys known to the sending system and the respective participant, while the private key corresponding to each of PK KG and EK I is known only to the sending system, and the private key corresponding to each of ENK p and AK p is known only to the participant (and optionally, the system generating the private key corresponding to each of ENK p and AK p ).

[0108] In some embodiments, the sending system (e.g., 111) computes DH1 by using ENK p and the private key corresponding to PK KG , and the participant system of participant p computes DH1 by using PK KG and the private key of ENK p .

[0109] In some embodiments, the sending system computes DH2 by using AK p and the private key corresponding to EK I , and the participant system of participant p computes DH2 by using EK I and the private key of AK p .

[0110] In some embodiments, the sending system computes DH3 by using ENK p and the private key corresponding to EK I , and the participant system of participant p computes DH3 by using EK I and the private key of ENK p .

[0111] In some embodiments, encrypting the shares includes, for each share (k i ), encrypting the share k i as described herein to generate share ciphertext (c i ), and combining the resulting encrypted share c i with the association data (e.g., where the association data can be provided as plaintext). In this variant, the association data can be included as part of the encryption process, or in ki The encrypted is appended.

[0112] In some embodiments, the encrypted share comprises: for each share (k i ), combining the share k i with the associated data, and encrypting the combined data (as described herein) to generate the encrypted share c i .

[0113] In some embodiments, the encrypted share comprises: for each share (k i ), encrypting the share k i under a shared encryption key (e.g., generated as described herein) to generate the encrypted share c i (e.g., share ciphertext c i ) and combining the encrypted share with the associated data.

[0114] In some embodiments, the associated data comprises a public key that generates an integrity key (PK KG ) and an authentication key AK p of the participant. In some embodiments, the associated data comprises a signature verification key PK. In some embodiments, the associated data comprises a signature secret share proof (e.g., VSS proof generated at S221). In some embodiments, the associated data comprises a participant broadcast round identifier that identifies the secret share as being broadcast to each participant in at least a first broadcast round.

[0115] In a particular instance, a share (of a private message signature key) can be encrypted using the following equation:

[0116]

[0117] However, c i may also be generated in other ways.

[0118] In variations, the signature secret generated at S220 (e.g., the encrypted share c i encrypted at S225, and optionally, the associated data) is stored at S226. In some variations, the sending system (e.g., the issuer system 111) stores the encrypted signature secret (signature key share ciphertext) (c i ) (and optionally, the associated data) in association with the signature verification key PK generated at S212. Additionally or alternatively, the signature secret (c i ) can be stored in association with the respective participant (p i ). In some variations, the sending system stores the encrypted signature secret (c i) stored at the message signing system 112, or in a repository accessible to the message signing system 112. In some variants, the sending system stores the cryptographic signing secret (c i ) at the respective participant system p i . The cryptographic signing secret (c i ) is preferably stored online (e.g., in a storage repository connected to the internet or to the outside), but can alternatively be stored offline (e.g., in a cold storage repository or the like), in geographically distributed storage repositories, or in other ways.

[0119] In some variants, the sending system stores information at the message signing system 112 associating the participant system i with a particular share (c i ) of the cryptographic message signing key. For example, each cryptographic message signing key share portion (c i ) can be stored at the message signing system 112 in association with the public authentication key AK i associated with the key share portion (c p ). Additionally or alternatively, the message signing system 112 can store information identifying each participant system having an associated message signing key share (c i ). However, the message signing key share (c i ) can be associated with the participant and / or participant system 114a-c in any suitable manner, such that during message signing, the message signing system 112 can broadcast the message signing key share (c i ) to the appropriate participant system (e.g., during the first broadcast round). In variants, the message signing system 112 can store information associating an index with each participant, such that the message signing system 112 can identify the index i of a partial signature received from a participant system based on the authentication identity of the participant system providing the partial signature. For example, if the public authentication key AK pi is associated with the index i at the message signing system 112, and the partial signature (s pi ) provided by the participant p; is signed using the associated private authentication key ak i , then the message signing system can identify the partial signature (s pi ) as the i-th partial signature by verifying the signature with the public authentication key AK i .

[0120] In variants, the signing secret (c i) to improve security. For example, to prevent a number of compromised threats in the participant systems, the signing secret can be updated so that any information obtained by an attacker from a compromised system will no longer be useful to message signing. In some variations, to prevent such attacks, the signing secret can be updated (e.g., re-encrypted to a new participant key; reconstituted, re-split, and re-encrypted; funds transferred to another PK, etc.). The signing secret can be updated periodically (c i ), in response to detecting a threat, in response to a command, or in response to any suitable trigger or event.

[0121] Updating the signing secret can include accessing (or recovering) the message signing private key generated at S210 and re-splitting the message signing private key into shares as described herein for S221. The shares can be encrypted to a set of participants as described herein for S225. The set of participants can be the same set of participants as before. Alternatively, the shares can be encrypted to a different set of participants (e.g., a set of participants excluding participants that are believed to have been compromised). Once encrypted, the encrypted updated shares can be stored at the message signing system 112 as described herein for S226. The old signing secret can be deleted, deprecated, or otherwise excluded from message signing operations at the message signing system 112. In this way, the data required to perform message signing can be updated so that compromised data becomes invalid without needing to rotate the message signing private key. In this way, the message signing private key can still be used without needing to be rotated. Alternatively, the signing secret (c i ) can be re-encrypted using new participant keys assigned to the participants of the respective participant group. However, the signing secret (c i ) can also be updated in other ways.

[0122] In variations, the participants can perform proactive secret sharing to prevent security threats (e.g., at S240) without needing to access the message signing private key.

[0123] In some variations, the issuer system 111 performs at least a portion of S221-S226. In some variations, a local system of a participant (e.g., a user device, an HSM, etc.) performs at least a portion of S221-S226.

[0124] Figure 8 is an example of a single message signing key and key generation flow for a group of participants according to variations. As Figure 8As shown, the extended private key (esk) is split (S210), an authentication key (S222) and an encryption key (S223) are generated for multiple participant systems, the private key share is encrypted to a specific participant (S225), and the encrypted private key share is stored (S226). Optionally, the private key share can be encrypted to the key generation ceremony instance (or otherwise associated with the key generation ceremony instance) via the integrity key of the key generation ceremony.

[0125] The signature request S230 is processed by using the stored signature secret to generate signatures for messages in a distributed manner in a cooperative manner. Figure 7 It is a representation of an exemplary signature process based on a variant. Figure 9 It is a representation of the message signing process for a single message using a single split (or fragment) message signing key, based on a variant.

[0126] like Figure 11 As shown, processing a signature request S230 may include one or more of the following: receiving a signature request for a message S231; accessing a stored signature secret S232; providing the corresponding signature secret to each of a group of participants in the system S233; accessing additional signature data (e.g., a temporary number share) generated by other participants S234; generating a signature based on the additional signature data (e.g., encrypted to the receiving participant) S235; and providing the generated signature S236.

[0127] Additionally or alternatively, processing a signature request S230 may include: optionally receiving a signature notification; requesting a message and an encrypted signature secret encrypted to the participants; decrypting the encrypted signature secret S310; optionally verifying the validity of the signature secret, and aborting if verification fails S320; generating additional signature data S330; splitting the additional signature data into additional signature data shares S340; encrypting each additional signature data share to a different participant (e.g., a group of participants) S350; and storing the additional signature data shares S360 (e.g., at message signing system 112), such as Figure 3 As shown. Processing the signature request S230 may additionally or alternatively include: after the additional signature data has been obtained with the first quorum, at the participant system of the participant group: accessing the participant's cryptographic signature secret c i (S410); Decrypt the participant's encrypted signature secret c i (S420); Verify the validity of the signature secret (abort if verification fails) (S430); Access the system p by one or more other participants i Encryption to participant system p j Additional signature data share b ij (S440); Decrypt each encrypted appended signature data share b ij(S450); aggregating the decrypted additional signature data shares (e.g., nonces ii ) (S460); generating a partial signature using the decrypted additional signature data shares (nonces ij ) (S470); and optionally, providing the partial signature (e.g., to the message signing system 112) (S480), as shown in Figure 4 , where in S235, a threshold number of partial signatures are aggregated into a valid signature.

[0128] However, the signing request can also be processed in other ways. All or part of S230 can be performed by the message signing system 112 (e.g., S231-S236), the participant system (e.g., S310-S360, S410-S480), and / or any other suitable system.

[0129] S231 receives a signing request for signing a message (m). The signing request can be received by the message signing system 112, the participant system 114, and / or any other suitable system. The signing request can be received from an external system (e.g., 104) via the API system 113, received from a client of the message signing system 112, generated by the message signing system 112, or received from any other suitable endpoint. The external system can be a digital wallet, a cold storage computing system (CSS), or any suitable type of system. The signing request can include or identify: the message m to be signed, a signature verification key (PK) (e.g., such that the request is for a signed message that can be verified by the signature verification key (PK)), a blockchain to which the message should be sent, an expiration time, other metadata (e.g., message source, message generation time, etc.), and / or any other suitable information.

[0130] S232 accesses a stored cryptographic signature secret (c i ) associated with the signing request. In some embodiments, the message signing system 112 stores a single signature secret for a signature verification key PK, and all of the signature secrets stored by the message signing system 112 are associated with the single verification key PK. In some embodiments, the message signing system 112 stores signature secrets for multiple signature verification keys (PK), the signature system 112 storing the signature secrets in association with the respective verification keys PK; accessing the stored signature secret includes accessing the signature secret stored in association with the signature verification key PK identified in the signing request.

[0131] S232 accesses a signature secret for the signing request received at S231. In some variations, each signature secret c i is encrypted to a participant p i , and for each signature secret c iThe server will combine the participant information from the relevant participant systems (e.g., 114a to 114c) with the signature secret c. i Stored together. In some implementations, the message signature system 112 uses the stored participant information to store each signature secret. i Provided to the relevant participants p i The participant system.

[0132] In some variations, for each signature secret corresponding to a signature request, S233 includes setting the signature secret c i Together with the signature verification key PK and the message m associated with the signature request, it is provided to the relevant participant system p. i In some implementations, the message signature system 112 uses the server's private authentication key (ak). s (Generated at S222) Each signature secret c is included in the signature payload. i Provided to the corresponding participant system. In some implementations, providing the signature secret to the participant system at S233 is the first broadcast round (e.g., the signature round) in the signing process, which includes multiple broadcast communication rounds for sending data from the message signing system to the participant system.

[0133] In some variations, a proof of the signature secret sharing (e.g., a VSS proof) is provided to the participant system along with the signature secret. In some variations, additional information about the signature secret is provided to the participant system along with the signature secret. In some variations, the index i of the signature secret is provided to the participant system along with the signature secret.

[0134] The participant system 114a receiving the signing secret at S233 may include: a human-managed participant system, and a participant system managed by the server of the signing system 110 (e.g., a server participant; a system server acting as a participant and holding the participant authentication key and / or the participant encryption key; etc.), and / or a participant system managed by any other suitable entity or system. The server participant may be centralized, distributed, or otherwise associated. In some variations, the total number (h) of human-managed participant systems is selected; the minimum number (q) of desired human-managed participant systems is selected (where h ≥ q); the number of server-managed participant systems is calculated based on h and q; the minimum number (t) of shares used to reconstruct the message signing private key is calculated based on q and s; and the total number (n) of shares is calculated based on h and s.

[0135] In some variations, s is calculated as follows: s = h - q + 1.

[0136] In some variations, t is calculated as follows: t = q + s.

[0137] In some variations, n is calculated as follows: n = h + s.

[0138] However, s, t, and n can also be determined in other ways. Variations of the system and method using server participants can automatically determine: the number of server participants, the shares required for reconstruction, and the total number of required shares (e.g., based on the number of human participants and a user-specified or automatically determined quorum); and can optionally automatically split the message signing key (e.g., in S220) and / or generate authentication and encryption keys for humans and server participants based on the above automatically determined values.

[0139] S234 is used to access additional signature data generated by at least t participants out of n. The additional signature data is preferably data related to a nonce (e.g., a nonce share), but alternatively, the additional signature data can also be related to a cryptographic seed required for the signature protocol or any other suitable additional signature data. In variations, one or more participant systems generate a portion of the additional signature data (e.g., an additional signature share) by using information sent by the message signing system 112 to the participants in the current broadcast round (e.g., an encrypted share c i , a decrypted share s i , a signature verification key, a key share secret sharing proof, a message to be signed, etc.). The participant systems can generate the additional signature data in response to user input (e.g., input identifying user authorization) or automatically (without user input to authorize generation of the additional data).

[0140] In some variations, the participant system of participant p i generates the additional signature data (e.g., a nonce share) by using the signature secret c i , the signature verification key PK, and the message m provided by the server 111 at S233. In variations, a random nonce seed is also used to generate the additional signature data. Any set of t participants out of n can perform nonce generation.

[0141] In some embodiments, the participant system of participant p i generates the additional signature data by using a signed payload received from the message signing system 112. The signed payload is signed by a private authentication key (ak s ) of the message signing system (generated at S222) and includes the signature secret c i , the signature verification key PK, and the message m (and optionally, additional information and / or a key share secret sharing proof). In some embodiments, the participant system of participant p i uses a public authentication key (AK sto verify that the signature of the payload is valid. If the signature is not valid, then p i aborts the message signing process.

[0142] Generating the additional signature data can include decrypting the encrypted signature secret c i by the participant system p i (S310); optionally verifying the validity of the signature secret (aborting if verification fails) (S320); generating additional signature data (S330); splitting the additional signature data into additional signature data shares (S340); encrypting the additional signature data shares (S350); and storing the additional signature data shares (S360), as shown in Figure 3 However, the additional signature data can also be determined in other ways. In some embodiments, storing the additional signature data shares (S360) includes storing encrypted ephemeral number shares b ij at the message signing system 112. In some variations, steps S310-S360 are performed by the participant system 114. The process is preferably performed by at least t participant systems (e.g., simultaneously, within a predetermined time threshold), but can also be performed by fewer participant systems instead. However, S310-S360 can also be performed in other ways.

[0143] Decrypting the signature secret S310 by the participant system p i may include decrypting the encrypted signature secret using a private authentication key (ak pi ) associated with a public authentication key (AK pi ) associated with the encrypted signature secret (e.g., identified by the association data of the signature secret). In variations, the participant system p i decrypts the encrypted signature secret using one or more of a private signature key (enk pi ) of the participant Pi, a public key generation integrity key PK KG , and / or a public issuer ephemeral key (EK i ).

[0144] Decrypting the signature secret S310 can include deriving a shared encryption key used at step S225 (e.g., by using the AKE) and decrypting the signature secret using the derived encryption key. In some variations, the decrypted signature secret includes the message signing key share generated at S221. In some variations, S310 includes accessing the key share secret sharing proof generated at S221 and using the key share secret sharing proof to verify the decrypted signature secret (e.g., verifying that the share is in fact a share of the message signing private key). In some variations, the decrypted signature secret includes additional information of the signature secret.

[0145] In some variations, deriving the shared encryption key includes: computing DH1 using EK KG (stored in a trusted data source accessible to the participant system) and the private key of AK p (stored securely for the participant system); computing DH2 using EK I (stored in a trusted data source accessible to the participant system) and the private key of AK p (stored securely for the participant system); computing DH3 using EK I and the private key of ENK p ; generating a byte sequence by concatenating DH1 || DH2 || DH3; and deriving the encryption key as a result of KDF(DH1 || DH2 || DH3).

[0146] In some variations, the key-share secret sharing proof is a VSS proof, and verifying the validity of the signing secret (S320) includes verifying the VSS proof against the decrypted signing secret In some variations, each Vj of the VSS proof is a commitment value, and each a j is a jth coefficient of a sharing polynomial used to split the message signing key into shares, and G is a base point of an elliptic curve used to generate the signature verification key. In some variations, verifying the validity includes verifying the signing secret k i : j e [t]:

[0147] V j · i j = (a0G · i 0 ) + (a1G · i 1 ) +... + (a t-1 G · i t-1 ),

[0148] wherein the values of a0G, a1G,..., a t-1 G are provided by the VSS proof, and wherein i is an index of the signing secret associated with the participant system (e.g., by information stored at the message signing system 112, and optionally provided to the participant system by the message signing system 112). In some variations, verifying the validity includes verifying that the signature verification key PK is equal to the free coefficient commitment V j，0 in.

[0149] In a first variation, generating the additional signature data (S330) includes generating a random number (e.g., a nonce).

[0150] In a second variant, generating additional signature data (S330) includes generating data by performing a distributed key generation process.

[0151] In a third variant, generating additional signature data (S330) includes generating additional signature data based on the signing secret k i and / or the signing secret with additional information. In a particular instance, the additional signature data is generated by generating a random nonce seed (e.g., a 32-bit nonce seed, using r i ← $ {0, 1} 32 generation), and computing a nonce:

[0152] r i = HKDF (signing secret || nonce seed, broadcast round identifier || PK || m)

[0153] where the broadcast round identifier (e.g., “2”) can be different from the message signing key broadcast round identifier (e.g., “1”). In a variant, the broadcast round identifier identifies a broadcast round in which the generated additional signature data is broadcast from the message signing system to other participant systems.

[0154] In some variants, generating additional signature data (S330) includes generating a nonce public key pair including the generated nonce and a nonce public key R. In some embodiments, generating the nonce public key R includes performing a scalar multiplication of the nonce with a base point G used to generate the signing verification key (at S212) (e.g., R = nonce G).

[0155] In some variants, generating additional signature data (S330) includes generating a random number and multiplying the random number by one of the two challenges to produce a nonce.

[0156] In some variants, participant subsets (of a set of participants) each generate different additional signature data (e.g., based on decrypted key shares k i , based on the message m, etc.), where respective additional signature data shares r i are encrypted to each participant (p j ) of the set of participants to generate encrypted additional signature data shares (b n ) of each participant (b1…b j). In variants, the security-based distributed key generation protocol generates the additional signature data (e.g., such that additional signature data generated by different participants within the same group of participants is correlated), but any other suitable method can also be used to generate the additional signature data. The additional signature data can be: randomly generated, generated using a Monte Carlo method (e.g., an LDS method), deterministically generated, or otherwise generated.

[0157] In some variants, the additional signature data (e.g., r i ) is split into shares (e.g., nonce shares). The additional signature data is preferably split using the same t-of-n configuration as used when splitting the message signing key (e.g., where the split configuration can be predetermined or sent to the participants), but the additional signature data can also be split in other ways. For example, splitting the additional signature data into shares (S340) includes splitting the additional signature data into n shares (e.g., nonce i …nonce n ), where t-of-n shares are required to recover the message signing key (as described herein for S221). In some variants, splitting the additional signature data into shares (S340) includes generating a signature secret share proof that can be used to verify that the shares are in fact shares of the additional signature data. In variants, the proof is a VSS proof generated by the VSS process used to split the additional signature data into n shares (nonce i …nonce n ), such as described above for S221.

[0158] In some variants, encrypting the additional signature data shares (S350) includes: for each participant system of participant P i , encrypting the associated additional signature data share (e.g., nonce j ) to participant P j . In some embodiments, encrypting the shares includes: for each share (p i ), encrypting the share by using a public authentication key (e.g., AK i ) of the sending system (e.g., participant P Pi ) that sent the share, a public authentication key (e.g., AK Pj ) of the participant that received the share, a public encryption key (e.g., ENK Pj ) of the receiving participant, and optionally a public ephemeral encryption key (e.g., EK i ) generated by the sending participant P Pi . In instances, the foregoing keys are used to generate an encryption key (e.g., a symmetric key) that is shared between the sending participant and the respective participant.

[0159] In some implementations, the encrypted shares include: for each share (p i The share is encrypted using a shared encryption key. In some variations, the participant system P generates the additional signed data share. i Export the data used to encrypt it into the participant system P using the following method. j Shared encryption key: by using AK pi (Participant System P) i (authentication key) and ENK pj (Participant System P) j DH1 is calculated using the private key of the public encryption key; by using EK pi (Participant System P) i (temporary key) and AK pj (Participant System P) j DH2 is calculated using the private key of the authentication key; by using EK pi and ENK pj The private key is used to calculate DH3; a byte sequence is generated by concatenating DH1||DH2||DH3; and the encryption key is derived as the result of KDF(DH1||DH2||DH3).

[0160] In some implementations, the cryptographic additional signature data shares include: for each share (e.g., nonce) i The share (e.g., nonce) is encrypted using a shared encryption key (e.g., generated at S350). i ), and the resulting encrypted share b j It can be combined with associated data (e.g., where the associated data may be provided as plaintext). In this variation, the associated data may be included as part of the encryption process or appended after encryption.

[0161] In some implementations, the encrypted additional signature data share includes: for each additional signature data share (e.g., nonce) i ), will share (e.g., nonce) j The data is combined with associated data and encrypted using a shared encryption key (e.g., generated at S350) to generate an encrypted share b. j .

[0162] In some implementations, the encrypted shares include: for each share (e.g., nonce) i Encryption (e.g., nonce) under a shared encryption key (e.g., generated at S350). j To generate encrypted share b j And combine the encrypted shares with the associated data.

[0163] Associated data may include: ciphertext type (e.g., temporary number), AK pi (Participant System P) i (authentication key) and AK pj (Participant System P) j The authentication key, signature verification key PK, message m, signature secret sharing certificate generated at S340, and / or any other suitable information.

[0164] Each encrypted share b ij By participant system p i For each participant system p j Generation. In one instance, the following equation is used to generate cryptographic temporary number shares:

[0165]

[0166] In some implementations, storing the additional signature data share (S360) includes encrypting the additional signature data share b. ij Stored at message signing system 112 (e.g., appending signature data share b) i1 …b in Send to message signing system 112 for storage). Preferably, the entire share is uploaded (e.g., including the share b encrypted to the generating participant). ii Alternatively, only the encrypted shares are uploaded to other participants.

[0167] In some implementations, server S112 stores each cryptographic temporary number share b in association with the corresponding message m and signature verification key PK. ij .

[0168] In some implementations, S360 includes a participant system p i The payload, including the additional signed data share, is signed, and the signed payload is authenticated by the participant's system's private authentication key (ak). pi (Generated at S222) is signed. In some implementations, the message signature system 112 uses a participant system p i Public Authentication Key (AK) pi (Generated at S222) to verify the validity of the payload signature.

[0169] In some implementations, the additional signature data share generated by participants at a threshold number (e.g., t, quorum) during access (and optionally authentication) is in the form of a quorum of participants. Figure 2D After point S234 (as shown), the broadcast round begins (e.g., the second broadcast round).

[0170] Returning to Figure 2D , the signature S235 is generated for the signature request (received at S231) by generating a signature using the stored signing secret.

[0171] In some variations, the signature is an Ed25519 signature. In some embodiments, the signature is a signature according to the EdDSA signature scheme. In some embodiments, the signature is parameterized to SHA-512 and curve 25519. However, the signature can be any suitable type of signature, including but not limited to Boneh-Lynn-Shacham (BLS) signatures, Schnorr signatures, and the like.

[0172] In some variations, S235 includes two or more participant systems that produce partial signatures for a message identified in the signature request. In some embodiments, at least t participant systems must produce partial signatures since the message signing private key is split into n shares, where t shares are required for signing. The set of participant systems that provide partial signatures for the message signing can be a different set of participant systems that generated the ephemeral number at S330.

[0173] In a first variation, generating the partial signatures is performed after a first broadcast round (e.g., the first round in which the encrypted signing secret is broadcast by the message signing system to each participant system). In a second variation, generating the partial signatures is performed after two or more broadcast rounds. In each broadcast round prior to the partial signature generation round, one or more participant systems receive data from the message signing system 112, generate data (e.g., using data provided by the message signing system 112 in the current round or in a previous round), and provide data generated by the participant system in that round to the message signing system. This data can then be broadcast by the message signing system 112 to all other participant systems in the signature generation round or in further data generation rounds. In variations, the number of rounds can be based on security constraints, signature protocol requirements, availability constraints, efficiency constraints, and network connectivity constraints, among any other suitable type of constraint.

[0174] In some variations, S235 includes the message signing system 112 initiating a second broadcast round by providing each participant system p i with the following information: the message m to be signed; the signature verification key (PK); their respective encrypted signing secret c i ; and an encrypted additional signature data share b i encrypted to the participant p i (through the participant system of p j and each of the other participants p ijAlternatively, the second broadcast round can be initiated by a participant or another system. In some implementations, at S235, the message signing system 112 uses the message signing system's private authentication key (ak) s (Generated at S222) In the signed payload to p i The participant system provides the message m, the signature verification key (PK), and their corresponding cryptographic signature secret c. i In some implementations, each participant system uses the server's public authentication key (AK). s (Generated at S222) to verify the validity of the payload signature. Figure 4 (S410 shown). In some variations, the encrypted appended signature data share b ij It is included in the signed payload.

[0175] In some variations, p i The participant system can generate partial signatures in response to user input (e.g., recognizing user-authorized input) or automatically (without requiring user input to authorize the generation of partial signatures).

[0176] In some variations, p i The participant system generates a partial signature that includes at least one of the following: access to the participant's cryptographic signature secret c i (S410); Decrypt the participant's encrypted signature secret c i (S420); Verify the validity of the signature secret (abort if verification fails) (S430); Access the participant system p i Other participants p j Each of the encryptions in the participant system p i encrypted additional signature data share b ij (S440); Decrypt each encrypted appended signature data share b ij (S450); The additional signature data share of the aggregated decryption (e.g., nonce) ij (S460); by using the decrypted additional signature data share (nonce) ij Generate a partial signature (S470); and provide the partial signature (e.g., to message signature system 112) (S480), such as Figure 4 As shown. In some variations, steps S410 to S480 are performed by participant system 114. This process is preferably performed by at least t participant systems (e.g., simultaneously, within a predetermined time threshold), but may alternatively be performed by fewer participant systems. The t participant systems generating the partial signature may be the same as or different from the participant systems generating the temporary number.

[0177] Decrypting the participant's cryptographic signature secret c i (S420) includes decrypting the encrypted signature secret c i (For example, using AKE; as described herein with respect to S310; etc.).

[0178] Verifying the validity of the signature secret (aborting if verification fails) (S430) includes: verifying the validity of the signature secret (e.g., using VSS; as described herein with respect to S320; etc.).

[0179] Access by participant system P j Encryption to participant system P i Additional signature data share b ij (S440) is used to extract at least t additional signature data shares (e.g., ciphertext of temporary number shares, encrypted temporary number shares), each additional signature data share being generated by a different participant (e.g., including or excluding the transient participant P). i The additional signature data share can be retrieved from the message signing system 112, from other participants, and / or any other suitable source. Retrieval or receipt of the additional signature data share can occur: after verification of the signature secret; in response to a request to the message signing system; retrieved or received with the encrypted signature secret; and / or at any other suitable time.

[0180] Use P i The participant system decrypts each encrypted additional signature data share b ij (S450) includes using a public authentication key (AK) associated with the cryptographic signature secret (e.g., identified by associated data of the signature secret). pi ) private authentication key (ak) pi To decrypt the encrypted appended signature data share. At S450, P i The participant system can additionally or alternatively use participant P i Private encryption key (enk) Pi ), and the public authentication key (AK) associated with the participant who generated the encrypted data. Pj ), and public participant temporary keys (EK) j (Associated with one or more of the participants who generated the encrypted data) to decrypt the encrypted data.

[0181] Decrypt the additional signature data share b ij This may include exporting the shared encryption key used in step S350, and using the exported encryption key to decrypt the encrypted additional signature data share b. ij It can be based on b ij Related data (e.g., ciphertext type, AK) 发送者 AK 接收者The shared encryption key can be derived from data such as PK, m, proof, etc. and / or other data.

[0182] In some variations, the encrypted additional signature data share b ij Includes additional signature data shares generated at S340 (e.g., nonce). ij In some variations, the signed secret-sharing proof generated at S340 is accompanied by an encrypted additional signature data share b. ij Provided together.

[0183] In some variants, deriving the shared encryption key used at S350 includes: using AK pj (Public authentication key pj of the participant system) and ENK pi (Participant system p) j DH1 is calculated using the private key of the encryption key (EK); pj (Participant system p) j (public temporary key) and AK pi (Participant system p) i DH2 is calculated using the private key of the authentication key; by using EK pj and ENK pi The private key is used to calculate DH3; a byte sequence is generated by concatenating DH1||DH2||DH3; and the shared encryption key is derived as the result of KDF(DH1||DH2||DH3).

[0184] In some variations, S450 includes verifying the validity of each additional signature data share (e.g., nonceij) by verifying the signature secret share proof included along with the decrypted temporary number. This is preferably performed after the additional signature data share is decrypted, but can alternatively occur beforehand. In the variations, the signature secret share proof is a VSS proof (V = {V k =a k G} k∈[t] ={a0G, a1G, ..., a t-1 G}). In some implementations, each Vk proved by VSS is a commitment value, and each a k It is used to attach signature data (e.g., nonce). j ) split into shares (nonce) ij The shared polynomial of is the k-th coefficient, and G is the base point of the elliptic curve used to generate the temporary number public key. In some variations, verifying validity includes verifying the additional signature data share by checking the equality of the following equation: k∈[t]:

[0185] V k ·ik = (a0G · i 0 ) + (a1G · i 1 ) +... + (a t-1 G · i t-1 )

[0186] where a0G, a1G,..., a t-1 G are values provided by the VSS proof, and where i is an index of an additional signature data share (e.g., nonce j ) associated with the participant system (e.g., by information stored at the message signing system 112, and optionally provided to the participant system by the message signing system 112). Verifying validity can optionally include verifying that there are no duplicate VSS proofs.

[0187] In some variants, verifying validity includes the participant system P i verifying that the t additional signature data shares (e.g., t ephemeral number share ciphertexts) have been provided to the participant system P i .

[0188] In some variants, verifying validity includes verifying that there are no two additional signature data shares with the same sender public authentication key (AK pj ) (e.g., each share should be from a different participant system, and if the authentication information indicates that one participant system generated two or more of the received ephemeral number shares, the process should be aborted).

[0189] In some variants, verifying validity includes verifying that all additional signature data shares have the participant system’s public authentication key (AK pi ) as the receiver authentication key (meaning that all received additional signature data shares are intended for the participant system P i ).

[0190] In some variants, if any of the verification steps fail, the process is aborted. On the other hand, if the verifications are successful, the verified and decrypted additional signature data shares (from different participant systems, respectively) are aggregated at S460.

[0191] The aggregated decrypted additional signature data shares (e.g., nonce ji ) are used to generate aggregated additional signature data for partial signing (S460). The aggregated additional signature data is preferably specific to P ibut can alternatively be shared among the participants. The aggregated additional signature data is preferably different from the additional signature data generated in S330, but can alternatively be the same. The aggregated additional signature data shares (e.g., decrypted ephemeral number shares) can include computing aggregated signature data shares according to the following equation:

[0192]

[0193] where is the aggregated additional signature data (e.g., aggregated ephemeral number) of P i , and p j is the additional signature data share from each p j encrypted to P i . However, the aggregated additional signature data can be determined in other ways.

[0194] Aggregating the decrypted additional signature data shares can optionally include aggregating the public keys of the additional signature data shares. In one instance, this includes aggregating the ephemeral number share public keys R. In particular instances, R can be determined using the following equation:

[0195]

[0196] where Rj is the public key of the additional signature data share from each p j . In particular instances, S460 can output a tuple (k i , R, PK) that can be used for partial signature generation.

[0197] Generating partial signatures S470 is for generating signature fragments that are individually invalid, but once a threshold number of partial signatures (e.g., t partial signatures) are combined, become valid under PK (e.g., for m). S470 is preferably performed by the participant systems p i , but can alternatively be generated by other systems. The partial signatures are preferably generated based on the aggregated additional signature data (e.g., aggregated ephemeral number), the public aggregated additional signature data key (R), PK, the message, the decrypted signature secret (e.g., the decrypted signature key share k i ), and / or other data. The partial signatures are preferably generated after the aggregated additional signature data is generated (e.g., immediately after, delayed after), but can alternatively be generated at a time after other participants have generated their respective aggregated additional signature data, after a predetermined event occurs, and / or at any suitable time. In particular instances, each participant P i (e.g., each of the t participants, a portion of the second quorum, a portion of the second broadcast round) computes where q is the order of the base point G used to generate the signature verification key PK, and the partial signature is determined as σ i : = R || s i where the partial signature (s i ) can be uploaded to the message signing system 112 along with an identifier of P j . However, partial signatures can be generated in other ways as well.

[0198] In variations, several broadcast rounds are performed to generate the signature, and in each round, the message signing system 112 broadcasts information to each participant system. In some embodiments, after at least a predetermined number (e.g., t, the number of partial signatures needed to generate the signature) of participants return additional signature data to the message signing system 112, the message signing system initiates another broadcast round (e.g., to receive further additional signature data from the participant systems, or to receive partial signatures from the participant systems). In some embodiments, the additional signature data generated in at least one of the broadcast rounds is used to generate partial signatures.

[0199] In variations, the participant system p i generates a partial signature S470 by signing the message (to be signed) using the decrypted signing secret at S310 and the aggregated additional signature data shares (e.g., nonce ji shares).

[0200] At S480, the participant system P i provides the generated partial signature to the message signing system 112. In variations, the participant system P i provides the partial signature in a signed payload that is signed by the participant system’s private authentication key (ak pi ) (generated at S222). In some embodiments, the message signing system 112 verifies that the signature of the payload is valid by using the participant system P i ’s public authentication key (AK pi ) (generated at S222). In some variations, the signed payload also includes the aggregated nonce public key R.

[0201] Generating a signature S235 based on the additional signature data is used to generate a valid signature from the partial signatures. S235 can include aggregating the t partial signatures received from the participant systems, which are used to generate a signature that verifies under the signature public key PK. S235 can be performed by the message signing system 112 (e.g., where the message signing system 235 receives the partial signatures from the t participant systems), the participant systems, and / or any other system. In some variations, aggregating the t partial signatures includes aggregating the partial signatures into a Shamir share. In some variations, the message signing system 112 stores information associating each message signing key share index i with a participant system, and the key share index i is used to aggregate the partial signatures using a Shamir sharing reconstruction process as shown below:

[0202]

[0203] In some variations, the aggregated partial signature s together with the ephemeral number public key R is a valid signature of the public key PK. In some variations, the message signing system 112 verifies the signature (R, s) with the message m and PK, and verifies that the ephemeral number value R has not been used previously. Prior to aggregation, the message signing system 112 can optionally verify that each partial signature uses the same R value.

[0204] S236 is used to provide the generated signature (and / or the signed message) to at least one system (e.g., the external system 104, a blockchain network associated with the message, etc.) as a response to the signature request.

[0205] In variations, the method 200 includes performing proactive secret sharing S240 to improve security (e.g., as shown in FIG. 3B). In some variations, performing proactive secret sharing includes each participant updating the additional signature data share generated by the participant, and replacing the existing additional signature data share (stored at the message signing system 112) with the updated share. Figure 10

[0206] In variations, the message signing system 112 initiates proactive secret sharing by sending a request to each participant system to update their additional signature data share (S241). The update request can be signed by using an authentication private key of the message signing system.

[0207] In some variations, in response to the update request, the participant systems (e.g., 114a-c) split a zero (0) value into n shares (zero value shares), encrypt the zero value shares to each of the participants, and store the zero value shares at the message signing system 112 (S242). In some embodiments, the zero value is split as described herein for S340, encrypted as described herein for S350, and stored as described herein for S360. ​

[0208] In response to the zero-value shares from at least the threshold number of participants (e.g., t participants), at S243, the message signing system 112 provides each participant system with an encrypted additional signature data share and an encrypted zero-value share (from each participant).

[0209] The encrypted zero-value shares and encrypted additional signature data shares are decrypted as described herein for S450. Each zero-value share is matched with a corresponding additional signature data share (e.g., according to the participant that generated the share), and the two shares are combined (e.g., added) S244. The combined share is encrypted to each of the participants S245 and stored at the message signing system 112 S246. In some embodiments, the combined share is encrypted as described herein for S350 and stored as described herein for S360. In some embodiments, the message signing system 112 replaces the old additional signature data share with the encrypted combined share S247. Since the valid aggregated zero-value shares sum to zero, the aggregate value of the updated additional signature data share is unchanged. However, if a malicious system does not have a zero-value share, then the malicious system will not be able to produce a valid partial signature (e.g., a partial signature that can be combined with other partial signatures to form a valid complete signature).

[0210] However, proactive secret sharing can also be performed in other ways.

[0211] Embodiments of systems and / or methods can include every combination and permutation of the various system components and the various method processes, wherein one or more instances of the methods and / or processes described herein can be performed asynchronously (e.g., sequentially), synchronously (e.g., in parallel), or in any other suitable order by and / or using one or more instances of the systems, elements, and / or entities described herein.

[0212] As will be recognized by those of skill in the art in light of the preceding detailed description of the application and the drawings and claims, modifications and alterations can be made to the preferred embodiments of the application without departing from the scope of the application as defined in the following claims.

Claims

1. A method for digitally signing a message, comprising: with a secure key generation system, securely providing, to a message signing system, an encrypted message signing key share and a key share secret sharing proof; with the message signing system, in a first broadcast round, securely providing, to each of a plurality of participant systems, a message to be signed, the key share secret sharing proof, and the encrypted message signing key share to a message signing participant of the participant system, wherein each participant system of a first group of message signing participants generates an encrypted additional signature data share based on the encrypted message signing key share includes: decrypting and verifying the encrypted message signing key share of the participant system, generating a nonce seed, and generating a nonce by using the nonce seed and the verified and decrypted message signing key share of the participant system; with the message signing system, from each participant system of the first group of message signing participants: securely receiving the encrypted additional signature data share and a corresponding signature secret sharing proof; with the message signing system, in response to receiving encrypted additional signature data shares from a threshold number of participant systems: in a subsequent broadcast round, securely providing, to each of the plurality of participant systems, the message, the key share secret sharing proof, each signature secret sharing proof, the encrypted message signing key share to the participant of the participant system, and each encrypted additional signature data share to the participant; with the message signing system, from each participant system of a second group of the message signing participants: securely receiving a partial signature; and with the message signing system, in response to receiving partial signatures from the threshold number of participant systems, generating a complete signature for the message by aggregating the received partial signatures.

2. The method of claim 1, further comprising, with the secure key generation system: generating a message signing key pair, a plurality of participant authentication key pairs, and a plurality of participant encryption key pairs, each key pair including a private key and a corresponding public key; securely providing, to respective participant systems, authentication private keys of at least the participant authentication key pairs and encryption private keys of the participant encryption key pairs, splitting a message signing private key of the message signing key pair into a plurality of message signing key shares and generating the key share secret sharing proof for the message signing private key; and generating each encrypted message signing key share by encrypting each message signing key share to a different participant, wherein encrypting a key share to a participant includes encrypting the key share by using at least an encryption public key of the participant and an authentication public key of the participant.

3. The method of claim 2, Also included are: selecting a group of participants, wherein generating each encrypted message signing key share includes encrypting each message signing key share to a different participant included in the selected group of participants.

4. The method of claim 3, wherein, in response to receiving a message signing request identifying the message, the message signing system initiates the first broadcast round.

5. The method of claim 4, further comprising: With the message signing system, receiving, from at least a threshold number of participants of the group of participants, an updated version of the encrypted additional signature data share that has been generated by a proactive secret sharing process.

6. The method of claim 3, further comprising: With the secure key generation system: For each participant in the group of participants, A shared symmetric key is generated by using: A private authentication key of the secure key generation system, An encryption public key of the participant, A private ephemeral encryption key of the secure key generation system, and An authentication public key of the participant; And 7. The method of claim 1, wherein, The participant's message signing key share is encrypted with the generated shared symmetric key.

8. The method of claim 7, wherein, The secure key generation system is an offline system that is not affected by a public communication network, and wherein at least one participant system is a mobile device that has a persistent connection to the public communication network.

9. The method of claim 1, wherein, In response to at least one authorization input received from a participant via a user interface, the message signing system receives the encrypted additional signature data share and the partial signature.

10. The method of claim 1, wherein, The complete signature is an ED25519 signature, and wherein the encrypted additional signature data share is an encrypted share of an ephemeral number.

11. The method of claim 1, wherein, The complete signature is one of a Boneh-Lynn-Shacham (BLS) signature and a Schnorr signature. The key share secret sharing proof is a verifiable secret sharing (VSS) proof, and wherein the signature secret sharing proof is a VSS proof.

12. A method for digitally signing a message, comprising: With a secure key generation system, securely providing an encrypted message signing key share to a message signing system; With the message signing system, in a first broadcast round, securely providing each of a plurality of participant systems with a message to be signed, and the encrypted message signing key share of a message signing participant encrypted to the participant system; With each participant system of a first group of message signing participants: Generating an encrypted additional signature data share based on the encrypted message signing key share, comprising: Decrypting and verifying the encrypted message signing key share of the participant system, Generating an ephemeral number seed, and Generating an ephemeral number by using the ephemeral number seed and the verified and decrypted message signing key share of the participant system; and Securely providing the encrypted additional signature data share to the message signing system; With the message signing system, in response to receiving encrypted additional signature data shares from a threshold number of participant systems: in a subsequent broadcast round, securely providing each of the plurality of participant systems with the message, the encrypted message signing key share of the participant encrypted to the participant system, and each encrypted additional signature data share encrypted to the participant; With each participant system of a second group of the message signing participants: Generating a partial signature by using the message, the encrypted message signing key share encrypted to the participant, and each encrypted additional signature data share encrypted to the participant, and Securely providing the partial signature to the message signing system; and With the message signing system, in response to receiving partial signatures from the threshold number of participant systems, a complete signature is generated for the message by aggregating the received partial signatures.

13. The method of claim 12, Further comprising: With the secure key generation system, securely providing a key share secret share proof to the message signing system; and With the message signing system, in the first broadcast round, securely providing the key share secret share proof to each of the plurality of participant systems, wherein decrypting and verifying the encrypted message signing key share of the participant system of the first set of message signing participants includes: decrypting the encrypted message signing key share using at least the participant's associated encrypted private key and the participant's associated authentication private key, and verifying the decrypted message signing key share using the key share secret share proof; wherein generating, with the participant systems of the first set of message signing participants, an encrypted additional signature data share further includes: splitting the additional signature data into a plurality of additional signature data shares, and generating a signature secret share proof of the additional data; and generating each encrypted additional signature data share by encrypting each additional signature data share to a different participant, wherein encrypting an additional signature data share to a participant includes encrypting the additional signature data share using at least the participant's encrypted public key and the participant's authentication public key, wherein the participant system provides the signature secret share proof to the message signing system.

14. The method of claim 13, Also included are: With the message signing system, in the subsequent broadcast round, securely providing the key share secret share proof to each of the plurality of participant systems, and each signature secret share proof, wherein generating, with a participant system in the subsequent broadcast round, a partial signature includes: decrypting the encrypted message signing key share using at least the participant's encrypted private key and the participant's authentication private key; verifying the decrypted message signing key share using the key share secret share proof; for each encrypted additional signature data share, decrypting the encrypted additional signature data share using at least the participant's encrypted private key and the participant's authentication private key, and verifying the additional signature data share using the signature secret share proof; generating the partial signature using the message and the verified and decrypted message signing key share and each verified and decrypted additional signature data share.

15. The method of claim 14, further comprising: With the secure key generation system, for each participant: generating a shared symmetric key using: a private authentication key of the secure key generation system, an encrypted public key of the participant, a private ephemeral encryption key of the secure key generation system, and an authentication public key of the participant; and encrypting the participant's message signing key share using the generated shared symmetric key.

16. The method of claim 15, further comprising: The encrypted additional signature data shares are updated by performing a proactive secret sharing process with at least a threshold number of participants.

17. The method of claim 15, Also included are: each participant system is utilized in the first broadcast round to: generate the shared symmetric key by using: a public authentication key of the secure key generation system, the encrypted private key of the participant of the participant system, a public ephemeral encryption key of the secure key generation system, and the authentication private key of the participant, wherein the participant system uses the generated shared symmetric key to decrypt the message signing key share of the participant associated with the participant system; each participant system is further utilized in the first broadcast round to: generate a shared symmetric key between the participant of the participant system and each other participant, wherein the shared symmetric key between the participant and another participant is generated by using: the private authentication key of the participant, an encrypted public key of the other participant, a private ephemeral encryption key of the participant, and an authentication public key of the other participant; and wherein the participant system encrypts the additional signature data share to another participant by using a corresponding shared symmetric key; each participant system is further utilized in the subsequent broadcast round to: generate the shared symmetric key for an encrypted additional signature data share by using: a public authentication key of a sending participant of the encrypted additional signature data share, the encrypted private key of the participant, a public ephemeral encryption key of the sending participant, and the authentication private key of the participant; and wherein the participant system decrypts the encrypted additional signature data share in the subsequent broadcast round with the generated shared symmetric key.

18. The method of claim 12, wherein, The ephemeral number seed is randomly generated.

19. A system configured to perform the method of any one of the preceding claims.

20. The system of claim 19, comprising at least one of: a remote computing system; and a set of local participant systems.

21. The system of claim 20, wherein, The remote computing system comprises at least one of: an issuer system; and a message signing system. The message signing system comprises at least one of: a remote computing system; and a set of local participant systems.

Images