Secure dynamic threshold signature scheme employing trusted hardware

Abstract

This invention provides an enhanced security solution using cryptographic techniques. It also includes a method and apparatus for generating an elliptic curve digital signature algorithm signature (r, w). The method comprises: i) forming a signature group with other nodes by a node; ii) obtaining, by the node,: a) the multiplicative inverse of the secure random number; and b) a first signature component r, wherein the first signature component is determined based on the secure random number and an elliptic curve generator point; iii) determining a portion of the signature by the node based on a private secret share, the multiplicative inverse of the secure random number, and the first signature component; iv) receiving the portion of the signature from other nodes in the signature group by the node; and v) generating a second signature component w by the portion of the signature determined and received by the node.

Description

[Technical Field]

[0001] This invention generally relates to computer security technologies, including the use of cryptographic signatures to ensure and enhance the security of resources exchanged or transmitted over computer networks. This invention also relates to distributed ledger (blockchain) technology, and more specifically, to methods and systems for providing decentralized control through exchanges or transmissions associated with or performed via a digital ledger. This invention is particularly suitable for, but not limited to, allowing a limited number of members of a group to generate valid cryptographic signatures on behalf of that group. [Previous Technology]

[0002] In this document, we use the term "blockchain" to encompass all forms of computer-based electronic decentralized ledgers. These ledgers include, but are not limited to, blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. The most widely known application of blockchain technology is the Bitcoin ledger, but other blockchain implementations have been proposed and developed. While Bitcoin may be mentioned herein for convenience and illustrative purposes, it should be noted that this invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are within the scope of this invention.

[0003] A blockchain is an electronic ledger based on consensus. It is implemented as a decentralized, computer-based system composed of blocks, each consisting of transactions and other information. In the case of Bitcoin, each transaction encodes the data structure controlling the transfer of digital assets between participants in the blockchain system and includes at least one input and at least one output. Each block contains the hash of previous blocks, making these blocks linked together to create a permanent, immutable record of all transactions written to the blockchain from the beginning. Transactions contain small programs called instruction codes embedded in their inputs and outputs, specifying how and by whom the transaction's outputs can be accessed. On the Bitcoin platform, these instruction codes are written using a stack-based instruction code processing language.

[0004] To write a transaction to the blockchain, it must be "verified." Some network nodes act as miners and perform the work of ensuring that each transaction is valid, with invalid transactions rejected by the network. For example, a software client installed on a node performs this verification work on transactions that reference Unused Transaction Outputs (UTXOs). Verification can be performed by executing lock and unlock commands for the transaction. If the execution of the lock and unlock commands evaluates to true, and if certain other conditions are met, the transaction is valid and can be written to the blockchain. Therefore, for a transaction to be written to the blockchain, it must i) be verified by the node that receives the transaction if it is verified, and that node relays the transaction to other nodes in the network; and ii) be added to a new block built by the miner; and iii) be mined, that is, added to the public ledger of past transactions. When a sufficient number of blocks are added to the blockchain to make the transaction practically irreversible, the transaction is considered confirmed.

[0005] Blockchain protocols sometimes provide multi-signature features, which require signatures from several nodes or parties before removing the encumbrance on an Unused Output (UTXO). For example, Bitcoin's multi-signature feature provides this functionality. A multi-signature command can set conditions where at least M private keys, each associated with one of the N public keys and recorded in the locking command, must provide signatures to release the encumbrance, i.e., unlock the UTXO. Such signature methods offer significant security benefits and provide enhanced control over UTXOs by enabling finer and more complex control over the locking or unlocking of UTXOs. However, known multi-signature technologies offer limited functionality because they do not allow the parties required to generate the signature to change their configuration after the locking command has been set. Therefore, improved security mechanisms are needed for controlling electronic resources, such as those transmitted via blockchains and other networks.

[0006] Therefore, according to the present invention, a method as defined in the appended claims is provided. [Summary of the Invention]

[0007] As will be described in more detail below, the dynamic multi-party qualifier signature method allows control over resources (e.g., blockchain transaction outputs UTXOs) shared among a group of participants under a single public key, but with each group member holding a private secret. A qualifying subset of participants is required to jointly sign the output for its use. Advantageously, a digital signature method is described that allows the generation of valid signatures without requiring any of the participants facilitating the signature to reveal their individual private secrets. A trusted execution environment can be used to provide security to the qualifier signature method.

[0008] Advantageously, techniques are described for enabling participants to log in and out in a manner that allows a single public key used for the group to remain consistent. A trusted execution environment is used to enable secure modifications to group members without having to change the single public key used for the group.

[0009] Therefore, according to the present invention, a computer-implemented method can be provided. It can be described as a security or control method. The method can be configured to secure or control resources. The method can be configured to control access to resources. The controlled resource can be an electronic resource, entity, or item stored on or transmitted via a computer or network. In some cases, the resource may be referred to as a "digital asset," "output," "part of cryptocurrency," or "UTXO." The present invention can be configured to control access to or transmission of the resource. The present invention can be configured to lock or unlock access to or control of the resource. In some cases, the term "spend" can be used to refer to unlocking a resource, that is, granting control or access to the resource.

[0010] This method may be a cryptographic compilation strengthening method. Alternatively, it may be described as a method for generating an elliptic curve digital signature algorithm signature. The signature may include a first signature component r and a second signature component w. This method may be implemented by one or more nodes in a network such as a blockchain network.

[0011] The method may include: i) forming a signature group with other nodes by means of a node; ii) obtaining by the node: a) a multiplicative inverse element of the secure random number; and b) a first signature component r, wherein the first signature component is determined based on the secure random number and an elliptic curve generator point; iii) determining a portion of the signature by means of the node based on a private secret share, the multiplicative inverse element of the secure random number and the first signature component; iv) receiving the portion of the signature from other nodes in the signature group by means of the node; and v) generating a second signature component w by means of the node based on the determined and received portion of the signature.

[0012] The method may include using signature control to access or transfer a resource over a network via a computer. This network may be a blockchain network.

[0013] In some implementations, obtaining includes generating the multiplicative inverse element and the first signature component. The method may also include sending the multiplicative inverse element to the other nodes.

[0014] In some implementations, a designated address space (enclave) associated with one of the trusted execution environments (TEEs) of the node is obtained to generate the secure random number.

[0015] In some implementations, the acquisition includes receiving the multiplication inverse element and the first signature component from one of the other nodes.

[0016] In some implementations, the method includes sending a message before forming the signature group to participate in the decentralized signature generation.

[0017] In some implementations, the partial signature is determined within a specified address space associated with a trusted execution environment of one of the nodes.

[0018] In some implementations, this signature is determined by performing Lagrange interpolation.

[0019] In some implementations, the second signature component is generated in a designated address space associated with a trusted execution environment, and the method further includes sending an elliptic curve digital signature algorithm from the designated address space to a host portion of the node after the second signature component is generated.

[0020] In some implementations, the method further includes adding the signature to a blockchain transaction and broadcasting it to a blockchain network.

[0021] In some implementations, the method further includes obtaining the secret share based on secret share data received from a plurality of existing members of a group before forming the signature group.

[0022] In some implementations, the secret share is determined within a designated address space associated with a trusted execution environment of one of the nodes.

[0023] In some implementations, the signature vi is determined as: where is a Lagrange interpolation coefficient, is the multiplicative inverse element of the secure random number, is the secret share, r is the first signature component and p is an order.

[0024] According to the present invention, an electronic device may be provided. Any features described above with respect to the methods of the present invention may also be applied to a device configured according to the present invention. The device may be configured to implement or perform any embodiment of the methods described above. The electronic device includes an interface device, a processor coupled to the interface device, and a memory coupled to the processor. The memory may have computer-executable instructions stored thereon, which, when executed, configure the processor to perform the methods described herein.

[0025] According to the present invention, a computer-readable storage medium may be provided. The computer-readable storage medium includes computer-executable instructions that, when executed, configure a processor to perform the methods described herein.

Implementation Method

[0026] This invention relates to improved security solutions. These solutions can be used to enhance the security of controlled resources on computer networks. In the following illustrative embodiments, we use a blockchain network, such as Bitcoin, as our example network. Blockchains can be used to transfer control over electronic resources, such as tokens or cryptocurrencies, between nodes on a network. For convenience only, we may refer to the controlled resources below as "digital assets." However, this should not be considered limiting in any way and should not be interpreted as meaning any particular type of asset. This invention has benefits and applications beyond those related to blockchain transactions and is not limited to uses related to financial content contexts, but has a broader applicability. The blockchain examples provided below are provided for illustrative purposes only.

[0027] Blockchain Network

[0028] Referring first to Figure 1, which illustrates an example blockchain network 100 associated with a blockchain in block diagram form. The blockchain network may be a public blockchain network, which is an open peer-to-peer membership network that anyone can join without invitation or consent from other members. Decentralized electronic devices that execute the blockchain protocol upon which the operation of blockchain network 100 is based can participate in blockchain network 100. Such decentralized electronic devices may be referred to as nodes 102. For example, the blockchain protocol may be the Bitcoin protocol.

[0029] The electronic device that runs the blockchain protocol and forms the node 102 of the blockchain network 100 can be of various types, including, for example, computers, such as desktop computers, laptop computers, tablet computers; servers; mobile devices, such as smartphones; wearable computers, such as smartwatches; or other electronic devices.

[0030] Nodes 102 of the blockchain network 100 are coupled to each other using suitable communication technologies, including wired and wireless communication technologies. This communication follows the protocols associated with the blockchain. For example, in the case of a Bitcoin blockchain, the Bitcoin protocol can be used.

[0031] Node 102 maintains a (potentially global) ledger of all transactions on the blockchain. This ledger is a decentralized ledger. Each node 102 can store a complete or partial copy of the global ledger. In the case of a blockchain secured by proof-of-work, transactions made by node 102 that affect the global ledger are verified by other nodes 102, thus maintaining the validity of the global ledger. When the blockchain is based on proof-of-work, blocks are also verified by checking the proof-of-work submitted with the block.

[0032] At least some of the nodes 102 operate as miners 104 of the blockchain network 100. The blockchain network 100 in Figure 1 is a proof-of-work blockchain, in which miners 104 perform expensive computations to facilitate transactions on the blockchain. For example, a proof-of-work blockchain may require miners to solve a cryptographic problem. In Bitcoin, miner 104 finds a temporary random number such that the block header is hashed by SHA-256 to a number less than the value defined by the current difficulty. The hashing power required by the proof-of-work algorithm means that after a certain number of blocks have been mined on a transaction, the transaction is considered practically irreversible. Miner 104, having solved the cryptographic problem, creates a new block for the blockchain and broadcasts the new block to the other nodes 102. The other nodes 102 confirm that miner 104 has indeed solved the cryptographic problem and therefore has demonstrated sufficient proof-of-work before accepting that the block should be added to the blockchain. The block is added to the blockchain (i.e., to the decentralized global ledger) through consensus among the nodes 102.

[0033] The block created by miner 104 includes transactions (TX) that have been broadcast to the blockchain by node 102. For example, the block may include a transaction from an address associated with one of the nodes 102 to an address associated with another of the nodes 102. In this way, the block acts as a record of a transfer from one address to another. Request transactions include one party in the block proving its authorization to initiate a transfer by signing the request using a private key corresponding to its public key (e.g., spending an output in the case of Bitcoin). A transfer may only be added to the block if the request is validly signed.

[0034] In the case of Bitcoin, there is a one-to-one correspondence between public keys and addresses. That is, each public key is associated with a single address. Therefore, any references herein to transferring controlled resources (e.g., digital assets) to or from a public key (e.g., making payments to or from a public key) and to transferring digital assets to or from an address associated with that public key refer to joint operations.

[0035] Some of nodes in node 102 may not operate as miners and may instead participate as validator nodes. Transaction verification may involve checking signatures, confirming references to valid UTXOs, etc.

[0036] The example in Figure 1 includes six nodes 102, three of which participate as miners 104. In practice, the number of nodes 102 or miners 104 may differ. In many blockchain networks, the number of nodes 102 and miners 104 can be much greater than the number shown in Figure 1.

[0037] As will be explained below, various nodes 102 can collaborate to form a group 110, which can collaboratively generate digital signatures using the provisional signature method. In the illustrated example, three nodes 102 are shown as participants in group 110. However, the actual number of members in group 110 can be much larger.

[0038] The techniques used for joining, leaving and participating in group 110 will be discussed in more detail below.

[0039] Electronic device as a node operation

[0040] Figure 2 is a block diagram illustrating the components of an example electronic device 200 that can serve as a node 102 (Figure 1) in a peer-to-peer blockchain network 100 (Figure 1). The example electronic device 200 may also be referred to as a processing device. The electronic device may take various forms, including, for example, desktop computers, laptops, tablets, servers, mobile devices such as smartphones, wearable computers such as smartwatches, or another type of form.

[0041] Electronic device 200 includes processor 210, memory 220, and interface device 230. These components may be directly or indirectly coupled to each other and may communicate with each other. For example, processor 210, memory 220, and interface device 230 may communicate with each other via bus 240. Memory 220 stores computer software programs containing machine-readable instructions and data for performing the functions described herein. For example, memory may include processor-executable instructions that, when executed by processor 210, cause the electronic device to perform the methods described herein. Processor-executable instructions may include instructions that, when executed by processor 210, cause the electronic device to implement a protocol associated with blockchain network 100 (FIG. 1). For example, such instructions may include instructions for implementing the Bitcoin protocol.

[0042] Memory 220 can store the global ledger of blockchain network 100 (Figure 1) or a portion thereof. That is, memory 220 can store all blocks of the blockchain or a portion of such blocks, such as the most recent block or a portion of the information in some blocks.

[0043] Although memory 220 is illustrated as a single block in Figure 2, in practice, electronic device 200 may include multiple memory components. Memory components may be of various types, including, for example, RAM, HDD, SSD, flash drive, etc. Different types of memory may be suitable for different purposes. In addition, although memory 220 is described as separate from processor 210, processor 210 may include embedded memory.

[0044] As illustrated in Figure 2, processor 210 may include a secure area such as a Trusted Execution Environment (TEE) 250. TEE 250 is an isolated execution environment that provides additional security to electronic device 200, such as isolated execution, integrity of trusted applications, and asset confidentiality. TEE 250 provides execution space that ensures the confidentiality and integrity of computer instructions and data loaded within TEE 250. TEE 250 can be used to protect the integrity and confidentiality of important resources such as keys. TEE 250 is implemented at least partially at the hardware level to protect instructions and data executed within TEE 250 from access and manipulation by the remainder of electronic device 200 and external parties such as the owner of the electronic device. The security of data and computation within TEE 250 is ensured to prevent operation by a party that operates node 102, including TEE 250.

[0045] The TEE 250 is operable to perform individualized enclaves of a specified address space, and then add pages of memory one at a time, while accumulating hashes. Similar operations can also be performed on remote machines (which could be the developer's machine or another machine), allowing the remote machine to determine and store the expected hash. Therefore, the contents of the specified address space can be verified by any remote machine to ensure that the specified address space is running an approved algorithm. This verification can be performed by comparing hashes. When the specified address space is fully enclave, it is locked. It is possible to run code in the TEE 250 and send a secret to the code, but the code cannot be altered. The final hash can be signed with an authentication key, and the final hash can be used by the data owner to verify the hash before the data owner sends any secrets to the specified address space.

[0046] The designated address space is securely protected from access via the host system architecture (including the host system's system memory, BIOS, and operating system). Therefore, the designated address space allows software to be securely and verifiably executed on a remote computer owned and controlled by an untrusted party. The memory of a program executing in the designated address space is accessible only to that program and only while the software in the designated address space is running. If memory contents are transferred from the designated address space to the remote computer or the host system itself, the memory contents are encrypted. Decryption of designated address space data relies on a key that can only be used to hash code to a specific value. If the designated address space code is modified, it will no longer be able to access these keys. Therefore, it is impossible to modify the designated address space code to access its data.

[0047] Additionally, TEE 250 enables remote authentication, which can be used by node 102 (FIG. 1) to prove to other nodes 102 that TEE 250 is reliable and is executing approved computer-executable instructions for the protocol implemented by group 110. Remote authentication can be provided by TEE 250 by executing a specific code segment and sending a hash of the code within a specified address space, signed with an internal authentication key for that specified address space. Effectively, remote authentication allows a specified address space of TEE 250 to prove to any remote system that the specified address space is executing computer-executable instructions hashed to a specific value.

[0048] Remote authentication enables code running in a secure designated address space to obtain a signed credential from that designated address space: the code is being executed in that designated address space using a given hash of the designated address space page cache. The hash of the designated address space page cache may be called a quote, and the designated address space page cache is a protected memory segment in which the specified code and data exist during the execution of this code.

[0049] The TEE 250 may be equipped with a secure random number generator located within a designated address space of the TEE 250. This secure random number generator can be used to generate private keys, random challenges, or other random data. The TEE 250 can also be configured to read data from external memory and can be configured to write data to external memory. This data can be encrypted using a secret key that remains only within the designated address space. ("Random" can be interpreted herein as including "pseudo-random").

[0050] For example, Intel Software Protection Extensions (SGX) can be used to implement TEE 250. SGX supports remote authentication. Third-party authentication services such as Intel Certification Services (IAS) can verify that such signed claims originate from reliable CPUs that conform to SGX specifications.

[0051] Electronic device 200 acts as node 102 (Figure 1) in blockchain network 100 (Figure 1) and can join and otherwise participate in group 110 (Figure 1). As will be explained below, group members (who may also be referred to herein as participants or nodes) collaborate to generate valid signatures, thereby releasing the burden of locking associated with the group public key.

[0052] Temporary Signature

[0053] Group 110 may be a permitted or unpermitted group. Any node 102 (Figure 1) in blockchain network 100 (Figure 1) (that is, any node that monitors and stores at least a portion of the information in the blockchain) may join group 110.

[0054] Group 110 is associated with a public key, which may be referred to as the group public key. This group public key controls access to and holds resources such as tokens and cryptocurrencies that are transmitted to the group public key. For example, a transaction's locking code can use the group public key to lock resources, preventing such resources from being transmitted or "spend" without the approval of Group 110.

[0055] Group 110 can operate according to the preliminary signature method. More specifically, resources controlled (burdened) by the group's public key can be unlocked (i.e., the burden can be removed) when at least a preliminary number of nodes that are members of the group collaborate to produce a valid signature. This signature is valid under the Elliptic Curve Digital Signature Algorithm (ECDSA). ECDSA is a cryptographic algorithm used in Bitcoin and other blockchain networks to ensure that resources can be spent only by their rightful owners, and the preliminary signature method described herein allows a preliminary number of nodes in the group to produce a valid ECDSA signature.

[0056] To enable group members to collaboratively generate valid signatures, member nodes hold private secrets generated in a decentralized manner (i.e., private secrets generated at the node itself). As will be described in more detail below, these private secrets can be used to generate valid signatures for transactions without the member nodes revealing their private secrets to other member nodes. Therefore, an improved security mechanism for controlling access to resources is provided.

[0057] A provisional signature method that allows member nodes to join and leave a group without changing the group's public key will now be described. A plurality of nodes 102 (Figure 1) in a blockchain network 100 (Figure 1) may implement the provisional signature method protocol as described herein. These nodes 102 may include computer-executable instructions for implementing the provisional signature method protocol stored in memory 220 (Figure 2). When executed by processor 210 (Figure 2), these instructions cause the nodes 102 (such as, see, an electronic device 200 of the type described in Figure 2) to perform one or more methods of the provisional signature method protocol. These methods may include any or a combination of the group initialization method 300, login method 400, member removal method 500, and instance method 600 for generating ECDSA signatures as shown in Figures 3 through 6. These methods can be executed by a node in coordination with other nodes associated with other group members.

[0058] Group Initialization

[0059] Referring now to Figure 3, a method 300 for initializing a group is illustrated. The group is initialized for use with the provisional signature method. That is, the group is initialized to allow member nodes to collaboratively generate valid digital signatures, thereby removing the burden of digital assets. The burden removed by the valid digital signature is based on the burden of the group's public key.

[0060] Figure 3 illustrates a method performed by a plurality of nodes cooperating with each other. More specifically, each node, as a member of a group, performs the operation of the group initialization method 300 described below. These nodes may be referred to as participants Pi or members in the following description. Initially, the group initialization method 300 involves a group U with n participants (i.e., i = 1, 2, ..., n). In the illustrated example, the group is formed by three nodes (i.e., n = 3). However, different numbers of nodes can be used to form a group. Each node performing the group initialization method 300 includes a proven TEE that implements the SGX-specified address space Ei.

[0061] Before executing the initialization group method 300, the nodes 102 to be formed into the group establish a secure communication channel with each other and agree on a signature threshold (t+1). Each node and its designated address space can communicate privately point-to-point after establishing a secure channel (e.g., using a Diffie-Hellman exchange) and can also securely broadcast information to other participants. The participants also jointly determine the elliptic curve generator point G and the order p. The operations described below are performed using this elliptic curve generator point G and the order p. For example, the reference description of mod p is a modulo operation performed based on this order p. After the communication setup, the nodes then perform dealerless polynomial generation according to the initialization group method 300 described below.

[0062] At step 302, each of the participants Pi deploys its designated address space Ei to generate a random degree t polynomial fi(x), where x is a variable of the polynomial function. The random degree t polynomial is a polynomial of degree t (mod P in a finite field of integers), where each of the coefficients of the polynomial is arbitrarily chosen.

[0063] At step 304, authentication is performed such that each designated address space acknowledges to each of the other designated address spaces that it is running the approved set of initialization instructions. During authentication, each designated address space may send references to each of the other designated address spaces, and each designated address space thus receives references from each of the other designated address spaces. Each of these received references is evaluated to determine whether the authentication was successful.

[0064] At step 304, each designated address space Ei securely transmits point fi(j) mod p to each of the other designated address spaces Ej, where j = 1, ..., n. Therefore, at step 304, each designated address space Ei receives a point from the other designated address spaces.

[0065] At step 306, each designated address space determines a secret share si. More specifically, at step 306, each designated address space sums over all received points to determine a common polynomial f(x). That is, the common polynomial is the sum of polynomials arbitrarily generated by all participants. The secret share is then determined to be a point on the polynomial (i.e., the point where x = i), where is the coefficient of a term in the polynomial (a constant term and a common secret), and x is a variable in the polynomial.

[0066] Therefore, each secret share is determined to be the sum of points (i.e., values) of the random polynomials of all other participants. Each participant has only different points on the shared polynomial, and therefore the polynomial and the shared secret can be reconstructed (by interpolation) from t+1 points.

[0067] At step 306, each secret share is secured in its respective designated address space. Each designated address space can also authenticate with other designated address spaces that it has executed approved instructions to generate the secret share. Therefore, remote authentication can be performed at step 306 to ensure that the secret share is generated properly.

[0068] Once the secret share is generated, a group public key (which is an elliptic curve public key) can be generated at step 308. At step 308, Lagrange interpolation can be used to determine the group public key corresponding to the shared secret. More specifically, each participant in the group deploys its designated address space to calculate its individual public key share based on the Lagrange interpolation coefficients, the elliptic curve generator points, and its secret share. That is, the public key share can be calculated as, where are the Lagrange interpolation coefficients, which are determined by, G is the elliptic curve generator point, and si is the secret share for participant Pi (i.e., a point on the shared polynomial).

[0069] During step 308, the public key share is broadcast to all other participants by the participants. Remote authentication can be used to confirm that the public key share has been properly generated.

[0070] After receiving all public key shares (i.e., after receiving public key shares from each of the other participants), each participant may calculate the group public key A based on the public key shares received. More specifically, the group public key can be determined as the sum of all public key shares:

[0071] It is noteworthy that the initialization phase is performed in an untrusted manner and there is no single point of failure because there is no trusted distributor. The polynomial generation and subsequent processing performed within the specified address space protect the secret shares that are allowed to be removed (described below with reference to Figure 5).

[0072] Join the group after the group has already started.

[0073] Referring now to Figure 4, login method 400 is explained. Login method 400 can be executed to allow a node to join a pre-existing group that has been initialized for use with the provisional signature method without issuing a new group public key. Login method 400 is executed after the group has been initialized (this initialization can be performed according to method 300 of initializing the group in Figure 3).

[0074] Figure 4 illustrates a method performed by a plurality of nodes cooperating with each other. More specifically, nodes that are members of an existing group perform at least some of the operations of login method 400 described below, and expected members perform at least some of the operations of login method 400. The expected member (which may be designated as Pn+1) is the node attempting to log in to the group.

[0075] Before executing login method 400, at least one group of participants (t+1) sends a message to each other indicating their desired login member. These participants form a login group UE. The nodes forming the login group establish a secure communication channel with the desired member. The desired member can also authenticate itself to the nodes of the login group.

[0076] In the example of Figure 4, the login group UE includes three nodes (i.e., n=3). However, a different number of nodes can be used to form a login group, as long as the number of nodes forming the login group is at least the threshold number of nodes (t+1). In the illustrated example, the expected member Pn+1 is represented as P4. Each node performing the login method 400 includes a proven TEE that implements the SGX-specified address space Ei.

[0077] At step 402, the expected member P4 provides an authentication reference to all members of the login group UE to confirm that the expected member is running an authenticated protocol. This authentication reference is received by the login group members, and each member of the login group evaluates the authentication reference to confirm that the expected member is running an approved protocol.

[0078] In step 404, each member of the logged-in group splits their own secret share into multiple parts. More specifically, each participant deploys their designated address space to multiply their secret share by a Lagrange interpolation coefficient determined by a new point (i.e., the modified secret share can be determined as follows:

[0079] Each designated address space then generates secure random numbers to split each into several parts (such that the sum of all such parts is 1), which may be called secret share parts:

[0080] In Figure 4, the subscript s (e.g., ss,1) is used to indicate that the share si has been split into t+1 parts.

[0081] Each designated address space retains a secret share portion and exchanges the remaining secret share portion with other designated address spaces of the login group, such that each designated address space then has the following secret share portion:

[0082] Each designated address space then adds all the secret share portions received from all its other members to the secret share portion held by that designated address space to obtain a total secret share:

[0083] At step 406, each designated address space then sends the secret share data to the designated address space of the intended member. More specifically, at step 406, each of the logged-in group participants then deploys its associated designated address space to privately transmit the sum of this secret share to the designated address space of the intended member. The intended member's designated address space receives the sum of these secret shares from all logged-in group members and then (at step 408) constructs a new secret share by determining the sum of all received secret share sums.

[0084] In the example described, since n equals 3, the new secret share is indicated as s4.

[0085] Therefore, it is expected that the member has obtained a new secret share based on secret share information received from a plurality of existing members of the group. More specifically, it is expected that the member has obtained a new secret share based on secret share information from at least a threshold number of existing members of the group.

[0086] As an additional confirmation step, step 308 of the group initialization method 300 can be executed after step 406 of the login method 400 to generate a group public key. Participants can then confirm that the group public key has not been changed from its previous value (i.e., the value implemented before the login method 400 in Figure 4).

[0087] Removed from group

[0088] Group members may occasionally be removed from the group. As used herein, removal means the release or removal of a member from the group. This removal can occur upon request by the member to be removed or upon request by other members (e.g., if the member to be removed has not yet participated in group activities according to defined criteria). Referring now to Figure 5, a method 500 for removing a member is illustrated. This method can be performed by node 102 in coordination with other nodes 102 in the group. This method can be used to remove a member without modifying the group's public key. Therefore, the present invention provides an improved cryptographic security method that provides enhanced control over resources compared to methods that may have been previously performed in the prior art.

[0089] To perform a removal, the threshold value (n-1) existing group members cooperate to execute the member removal method 500 of Figure 5. More specifically, all group members remaining in the group participate in the member removal method 500 of Figure 5. However, the group member to be removed does not participate in this method. In some cases, more than one group member can be removed at a time, provided that the number of removers is less than or equal to the difference between the number of existing group members and the threshold value used for the threshold signature method, i.e., ...

[0090] That is, the number of group members who do not leave the group must be at least equal to the threshold value t+1 used for the threshold signature method.

[0091] In the example of Figure 5, the existing groups of the four members will be modified to exclude one of the participants, P4, so that only three group members are retained.

[0092] Before executing the method 500 of removing a member as shown in Figure 5, the participants communicate with each other to reach a consensus on revoking the share of the group participants and form a removal group. Remote authentication is used to ensure that all designated address spaces in the removal group are operating the approved set of removal instructions. More specifically, each member of the removal group confirms that the other members of the removal group are operating the approved set of removal instructions.

[0093] At step 502, each participant in the expulsion group performs polynomial generation and sharing. More specifically, each participant in the expulsion group deploys its designated address space to generate a random-degree polynomial, wherein...

[0094] At step 502, each designated address space () then securely sends each point j of its new random polynomial to each other designated address space (). Each of the designated address spaces authenticates the other designated address spaces by remote authentication.

[0095] At step 504, each designated address space generates a new secret share. More specifically, each designated address space then adds all received points to its initial secret share to determine the new secret share. For example, the new secret share can be determined as:

[0096] As an additional confirmation step, step 308 of the method 300 for initializing the group can be executed after step 504 of the method 500 for removing members to generate a group public key. Participants can then confirm that the group public key has not been changed from its previous value (i.e., the value before the method 500 for removing members in Figure 5).

[0097] At step 504, the previous secret share can be overwritten with the new secret share, thereby effectively invalidating the secret share in the designated address space of the participant to be removed. Therefore, the member is now removed from the group.

[0098] It is noteworthy that during the method 500 of removing a member, the security of the method depends solely on the individual participant, who verifiably overwrites their expired key share with a new value. Therefore, it is necessary to breach the threshold value () specified address spaces before security is affected. Even if the removed participant (who now has nothing to lose) is able to breach their own specified address space to recover their key share, that share is useless in a conspiracy attack as long as at least 1 specified address space operates correctly.

[0099] Signature generated

[0100] Secret shares held by group members can be used to allow the generation of a valid ECDSA signature for a transaction. More specifically, at least a limited number of secret shares can be used to allow group participants to generate a valid signature. This signature can be applied to transactions that spend digital assets previously held by the group's public key. That is, a valid signature removes the burden previously placed on the resource. An ECDSA signature consists of two components: a first component r and a second component w.

[0101] Referring now to Figure 6, an instance method 600 for generating an ECDSA signature is illustrated. The instance method 600 for generating an ECDSA signature can be executed by node 102 in collaboration with other nodes 102 that have previously formed a group. The members of the group (i.e., the nodes that collaboratively execute the instance method 600 for generating an ECDSA signature) may have been defined previously using the techniques described above.

[0102] Before executing this method, multiple participants (i.e., members) in the group can send messages to other participants expressing their desire to participate in the decentralized signature generation to authorize a specific transaction Tx. That is, a node can send a message expressing its intention to participate in the decentralized signature generation for transaction Tx. Transaction Tx is a transaction that will spend the output burdened by the group's public key. In other words, the effect of the transaction will be the removal of the burden based on the group's public key from the output. For example, transaction Tx can be proposed by one of the group participants.

[0103] Once the threshold number of participants has sent their participation intentions, a signature group is formed by one node in collaboration with the other nodes. In the illustrated example, the signature group includes three participants (i.e., three nodes). However, a signature group may include a different number of nodes.

[0104] At step 602, a hash z is determined for transaction Tx by the signature group. This hash is determined as: , where H represents the hash function. This hash is determined by the consensus of the signature group. For example, the hash may be proposed by one of the participants in the signature group, and other members may confirm their agreement with the hash.

[0105] At step 604, the nodes forming the signature group obtain, based on the secure random number k,: a) the multiplicative inverse of the secure random number; and b) the first signature component r. The first signature component r is determined based on the secure random number k and the elliptic curve generator point G. More specifically, at step 604, each of the participants, for example, deploys its designated address space (which is associated with the trusted environment of the node as a participant) to generate a secure random number and calculate the multiplicative inverse of this secure random number, and also calculates the first signature component r. The first signature component r can be determined as:

[0106] At step 604, the designated address space of the multiplicative inverse of the secure random number and the first signature component r is calculated, and this equivalent (e.g., the multiplicative inverse of the secure random number and the first signature component r) is sent to designated address spaces associated with other participants in the signature group. The designated address space sending this equivalent remotely authenticates the integrity of the equivalent and confirms that the equivalent was generated using an approved instruction set. The designated address space that did not generate this equivalent receives the equivalent from the designated address space that generated it and confirms the integrity of the equivalent (e.g., by confirming that the instruction set used to generate this equivalent is an approved instruction set).

[0107] In step 606, each node of the signature group determines a partial signature based on a private secret share, the multiplicative inverse of a secure random number, and a first signature component. The partial signature is generated within a designated address space for each node. For example, the designated address space () for the signature group calculates the partial signature as: , where is the Lagrange interpolation coefficient, which is determined as , is the multiplicative inverse of a secure random number, is the secret share for participant Pi (which has previously been obtained using the technique described above), r is the first signature component, and p is the order.

[0108] Therefore, the determination of partial signatures may involve performing Lagrange interpolation.

[0109] At step 606, each of the designated address spaces () used for the signature group securely broadcasts its partial signature vi to the other designated address spaces used for the signature group, such that each node (and more specifically, each designated address space) receives the partial signature from the other nodes of the signature group.

[0110] At step 608, each node in the signature group (and more specifically, each designated address space) may generate a second signature component w based on the partial signature determined and received at step 606. For example, the second signature component may be determined as: , where z is the transaction hash.

[0111] At step 608, each node of the signature group may send an ECDSA signature, including the first signature component and the second signature component, from its designated address space to the host portion of the node (i.e., the node is not part of the designated address space), and the node may verify the signature based on the transaction hash z and the group public key A.

[0112] Any participant in the signature group may then add a signature to the corresponding transaction and broadcast it to the blockchain network.

[0113] The security of the signature method described above depends on the value of the temporary private key, which is a secure random number generated from a designated address space and secretly distributed to other designated address spaces in the signature group, remaining hidden. If this value is extracted by breaking through only one of the designated address spaces, the shared private key can be used to sign completely different transactions after the transaction signature is determined. However, the impact of this operation is minimal because the physical breach of the designated address space must occur within a very small time window: the confirmation time of the transaction on the blockchain.

[0114] It should be noted that the embodiments mentioned above are illustrative and not limiting of the invention, and those skilled in the art will be able to devise many alternative embodiments without departing from the scope of the invention as defined by the appended claims. Any reference numerals placed in parentheses in the claims should not be considered as limiting the scope of the claims. The terms "comprising" and "comprises" and similar terms do not exclude the presence of elements or steps other than those listed in their entirety in any claim or specification. In this specification, "comprising" means "including or consisting of". A singular reference to an element does not exclude a plural reference to such an element, and vice versa. The invention can be implemented by means of hardware comprising several dissimilar elements and by means of a suitably programmed computer. In an apparatus claim listing several components, several of these components may be embodied by the same item of hardware. The mere factual description of certain measures in mutually dissimilar subsidiary claims does not indicate that a combination of such measures cannot be advantageously used. [Simplified Explanation of the Diagram]

[0115] Figure 1 illustrates a block diagram of an example blockchain network. Figure 2 illustrates a block diagram of an example electronic device that can act as a node in a blockchain network. Figure 3 is a signal diagram of a method for initializing a group. Figure 4 is a signal diagram of a method for joining a previously initialized group. Figure 5 is a signal diagram of a method for removing a member from a group. Figure 6 is a signal diagram of a method for generating a signature for a group.

Claims

1. A computer security implementation method using a secure dynamic quasi-signature with trusted hardware, comprising the following steps: generating an elliptic curve digital signature algorithm signature comprising a first signature component r and a second signature component w, the generation step comprising: forming a signature group by a node and other nodes; obtaining by the node: a) a multiplicative inverse element k-1 of the secure random number; and b) the first signature component r, wherein the first signature component is determined based on the secure random number and an elliptic curve generator point; determining a portion of the signature vi by the node based on a private secret share, the multiplicative inverse element of the secure random number, and the first signature component; receiving the portion of the signature from other nodes in the signature group by the node; and generating the second signature component w by the node based on the determined and received portion of the signature.

2. A computer implementation method for secure dynamic quasi-signature using trusted hardware as described in claim 1, wherein the obtaining step includes generating the multiplicative inverse element and the first signature component, and wherein the method further includes sending the multiplicative inverse element to the other nodes.

3. A computer implementation method for secure dynamic quasi-signature using trusted hardware as described in claim 2, wherein the obtaining step includes deploying a designated address space associated with a trusted execution environment of one of the nodes to generate the secure random number.

4. A computer implementation method for secure dynamic quasi-limited signature using trusted hardware as described in any one of claims 1 to 3, wherein the obtaining step includes receiving the multiplicative inverse element k-1 and the first signature component r from one of the other nodes.

5. The computer implementation method for secure dynamic quasi-limited signature using trusted hardware as described in claim 1, further comprising the intent to participate in distributed signature generation before forming the signature group.

6. The computer implementation method for secure dynamic quasi-signature using trusted hardware as described in claim 1, wherein the signature vi is determined by performing Lagrange interpolation.

7. A computer implementation method for secure dynamic quasi-limited signature using trusted hardware as described in claim 1, wherein the second signature component w is generated in a designated address space associated with a trusted execution environment, and wherein the method further includes, after generating the second signature component, sending an elliptic curve digital signature algorithm from the designated address space to a host portion of the node.

8. The computer implementation method of secure dynamic provisional signature using trusted hardware as described in claim 1, further comprising adding a signature to a transaction and broadcasting it to a blockchain network.

9. The computer implementation method of secure dynamic quasi-signature using trusted hardware as described in claim 1, further comprising, prior to forming the signature group, obtaining a secret share si based on secret share data received from a plurality of existing members of the group.

10. A computer implementation method for secure dynamic pre-limited signature using trusted hardware as described in claim 9, wherein the secret share is determined within a designated address space associated with a trusted execution environment of one of the nodes.

11. The computer implementation method for secure dynamic pre-limited signature using trusted hardware as described in claim 1, wherein the partial signature vi is determined as: vi = k-1rbisi mod p, where bi is a Lagrange interpolation coefficient, k-1 is the multiplicative inverse element of the secure random number, si is the secret share, r is the first signature component, and p is an order.

12. A computer-readable storage medium comprising computer-executable instructions that, when executed, configure a processor to perform a computer implementation method of secure dynamic provisional signature using trusted hardware as described in any one of claims 1 to 11.

13. An electronic device comprising: an interface device; a processor coupled to the interface device; and a memory coupled to the processor, the memory having computer-executable instructions stored thereon, the instructions, when executed, configuring the processor to perform a computer implementation method of secure dynamic pre-limited signature using trusted hardware as described in any one of claims 1 to 11.

14. The electronic device as described in claim 13, wherein the processor includes a trusted execution environment, and wherein the computer-executable instructions are executed within the trusted execution environment.