Methods, storage media, and electronic devices for secure dynamic threshold signature schemes
The dynamic multiparty threshold signature scheme with a TEE enables secure and flexible management of electronic resources by allowing group member changes without altering the public key, enhancing security and control in blockchain systems.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- NCHAIN LICENSING AG
- Filing Date
- 2024-08-13
- Publication Date
- 2026-05-20
AI Technical Summary
Existing multi-signature technologies in blockchain systems do not allow parties to change after the lock script has been set, limiting flexibility and security in controlling electronic resources.
A dynamic multiparty threshold signature scheme using a trusted execution environment (TEE) allows secure changes in group members without modifying the group's public key, enabling collaborative signature generation without revealing private secrets.
Provides enhanced security and control over resource access by allowing dynamic membership changes in signature groups, ensuring secure and flexible management of electronic resources.
Smart Images

Figure 0007863140000011 
Figure 0007863140000012 
Figure 0007863140000013
Abstract
Description
[Technical Field]
[0001] The present invention relates to computer security technologies that generally include utilizing cryptographic signatures to protect and enhance the security of resources exchanged or transmitted over computer networks. The present invention also relates to distributed ledger (blockchain) technology, and more particularly to methods and systems that provide distributed control over exchanges and / or transfers associated with and / or performed by a digital ledger. The present invention is particularly suited to, but not limited to, allowing a threshold number of members of a group to generate valid cryptographic signatures on behalf of the group. [Background technology]
[0002] In this document, the term “blockchain” is used to include all forms of electronic, computer-based, distributed ledgers. These include, but are not limited to, blockchain and transaction chain technologies, authorized and unauthorized ledgers, shared ledgers, and their variations. 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 the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols also fall within the scope of the present invention.
[0003] A blockchain is a consensus-based electronic ledger, implemented as a computer-based, distributed system composed of blocks consisting of transactions and other information. In the case of Bitcoin, each transaction is a data structure that encodes the transfer of control of digital assets among participants in the blockchain system, and includes at least one input and at least one output. Each block contains the hash of the preceding block to which the block is chained together, creating a persistent and immutable record of all transactions written to the blockchain since its inception. A transaction contains a small program known as a script embedded in its input and output, which specifies who can access the transaction's output and how. On the Bitcoin platform, these scripts are written using a stack-based scripting language.
[0004] For a transaction to be written to the blockchain, it must be verified. Several network nodes act as miners, performing tasks to ensure that each transaction is valid, and invalid transactions are rejected from the network. For example, a software client installed on a node performs this verification task for transactions that reference unspent balances (UTXOs). Verification can be performed by executing transaction lock and unlock scripts. If the execution of the lock and unlock scripts evaluates to TRUE and 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 be i) verified by the node receiving the transaction (if the transaction is valid, the node relays it to other nodes in the network); ii) added to a new block constructed by a miner; and iii) mined, i.e., added to the public ledger of past transactions. A transaction is considered approved when a sufficient number of blocks have been added to the blockchain, making the transaction effectively irreversible. [Overview of the project]
[0005] Blockchain protocols often provide multi-party signing capabilities that require signatures from multiple nodes or parties before an encumbrance can be removed from an unspent balance (UTXO). Bitcoin's multi-signature functionality, for example, provides such a feature. A multi-signature script can set conditions under which N public keys are recorded in the lock script, and each of the N public keys must provide a signature to release the encumbrance, i.e., to unlock the UTXO, with at least M public keys associated with each of the N public keys. Such a signing scheme offers advantageous security benefits and provides enhanced control over UTXOs by enabling more granular and sophisticated control over the locking / unlocking of UTXOs. However, known multi-signature technologies offer limited functionality because they do not allow the parties who must contribute to signature generation to change after the lock script has been set. Therefore, there is a need for improved security mechanisms to control electronic resources such as those transferred over blockchains and other networks.
[0006] Thus, the present invention provides a method as defined in the appended claims.
[0007] As will be explained in more detail below, a dynamic multiparty threshold signature scheme allows control of a resource (e.g., blockchain transaction output, UTXO) to be shared among a group of participants under a single public key, but with each group member holding a private secret. A threshold subset of the participants is required to collectively sign the output to use it. Conveniently, a digital signature scheme is described that allows a valid signature to be generated without requiring any participant contributing to signature generation to reveal their private secret. A trusted execution environment may be used to provide security for the threshold signature scheme.
[0008] Conveniently, a technique is described for registering and deregistering participants in a manner that allows the single public key used for the group to remain the same. A trusted execution environment is used to enable secure changes to group members without requiring any modification of the group's sole public key.
[0009] Accordingly, the present invention may provide a method that can be implemented by computer. The present invention may be described as a method of security or control. The present invention may be configured to secure or control resources. The present invention may be configured to control access to resources. The controlled resources may be electronic resources, entities, or items stored on or transmitted through a computer or network. In some cases, they may be called “digital assets,” “outputs,” “part of cryptocurrency,” and / or “UTXOs.” The present invention may be configured to control access to and / or transfer of resources. The present invention may be configured to control access to and / or transfer of resources. The present invention may be configured to lock or unlock access to / control of resources. In some cases, the term “spend” may be used to indicate unlocking a resource, i.e., allowing its control or access to the resource.
[0010] This method may be performed by encryption. Additionally or alternatively, the present invention 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] This method may include: i) a step of a node forming a signature group with other nodes; ii) a step of a node obtaining a) the reciprocal of a secure random number and b) a first signature component r based on a secure random number, wherein the first signature component is determined based on a secure random number and an elliptic curve generation point; iii) a step of a node determining a partial signature based on a private secret share, the reciprocal of a secure random number, and the first signature component; iv) a step of a node receiving partial signatures from other nodes in the signature group; and v) a step of a node generating a second signature component w based on the determined and received partial signatures.
[0012] This method may include a step of using signatures to control access to and / or transfer of resources in a computer-implemented network. This may be a blockchain network.
[0013] In some implementations, the acquisition step includes generating the reciprocal and the first signature component. This method may also include sending the reciprocal to another node.
[0014] In some implementations, the acquisition step includes preparing an enclave associated with the node's trusted execution environment (TEE) to generate secure random numbers.
[0015] In some implementations, the acquisition step includes receiving the reciprocal and the first signature component from one of the other nodes.
[0016] In some implementations, this method includes a step of signaling an intention to participate in distributed signature generation before forming a signature group.
[0017] In some implementations, partial signatures are determined within an enclave associated with the node's trusted execution environment.
[0018] In some implementations, partial signatures are determined by performing Lagrangian interpolation.
[0019] In some implementations, the second signature component is generated within an enclave associated with a trusted execution environment, and the method further includes the step of sending the elliptic curve digital signature algorithm from the enclave to the node's host portion after generating the second signature component.
[0020] In some implementations, this method further includes the step of adding a signature to a blockchain transaction and broadcasting it to the blockchain network.
[0021] In some implementations, the method further includes the step of obtaining secret shares based on secret sharing data received from multiple existing members of a group, before forming the signing group.
[0022] In some implementations, secret sharing is determined within an enclave associated with the node's trusted execution environment.
[0023] In some implementations, partial signatures i teeth: v i =k -1 rb i s i mod p It will be decided as such.
[0024] b i is the Lagrangian interpolation coefficient, and k -1 is the reciprocal of a secure random number, and s i r is the secret sharing, r is the first signature component, and p is the degree.
[0025] 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 apply 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 may include an interface device, a processor coupled to the interface device, and memory coupled to the processor. The memory may store computer executable instructions therein that, when executed, constitute the processor to perform the methods described herein.
[0026] 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. [Brief explanation of the drawing]
[0027] These and other aspects of the present invention will be evident from and clarified by reference to the embodiments described herein. Embodiments of the present invention will be described with reference to the accompanying drawings, along with various parameters, as merely illustrative examples.
[0028] [Figure 1] Figure 1 shows an exemplary block diagram of a blockchain network.
[0029] [Figure 2] Figure 2 shows a block diagram of an exemplary electronic device that can function as a node in a blockchain network.
[0030] [Figure 3] Figure 3 is a signal diagram showing how to initialize the group.
[0031] [Figure 4] Figure 4 is a signal diagram showing how to join a previously initialized group.
[0032] [Figure 5] Figure 5 is a signal diagram showing how to unregister a member from a group.
[0033] [Figure 6] Figure 6 is a signal diagram showing how to generate a signature for a group. [Modes for carrying out the invention]
[0034] This invention relates to improved security solutions. These can be used for enhanced security of resources controlled on a computer network. In the following exemplary embodiments, we use a blockchain network, such as Bitcoin, as our network example. Blockchain can be used to transfer control of electronic resources, such as tokens or parts of cryptocurrency, between nodes on the network. For convenience, the controlled resources will be referred to as “digital assets” below. However, this should not be construed as limiting in any way, nor as meaning any particular type of asset. This invention has advantages and applications that surpass those of blockchain transactions and has broader applicability, not limited to use in a financial context. The blockchain examples provided below are for illustrative purposes only.
[0035] Blockchain network First, refer to Figure 1, which shows an exemplary blockchain network 100 related to blockchain in block diagram form. The blockchain network may be a public blockchain network, which is a peer-to-peer open membership network on which anyone can join without invitation or consent from other members. Distributed electronic devices running an instance of the blockchain protocol on which the blockchain network 100 operates can participate in the blockchain network 100. Such distributed electronic devices may be referred to as nodes 102. The blockchain protocol may be, for example, the Bitcoin protocol.
[0036] The electronic devices that execute the blockchain protocol and form nodes 102 of the blockchain network 100 may be of various types, including computers such as desktop computers, laptop computers, tablet computers, servers, mobile devices such as smartphones, wearable computers such as smartwatches, or other electronic devices.
[0037] Nodes 102 of the blockchain network 100 are connected to each other using appropriate communication technologies, which may include wired and wireless communication technologies. Such communication adheres to the protocol associated with the blockchain. For example, if the blockchain is a Bitcoin blockchain, the Bitcoin protocol may be used.
[0038] Node 102 maintains a (possibly global) ledger of all transactions in the blockchain. The ledger is a distributed, non-centralized ledger. Each node 102 can store a complete or partial copy of the global ledger. In the case of a proof-of-work protected blockchain, transactions by node 102 that affect the global ledger are verified by other nodes 102, thereby maintaining the validity of the global ledger. If the blockchain is a proof-of-work based blockchain, blocks are also verified by examining the proof-of-work submitted with the block.
[0039] At least some of the nodes 102 will act as miners 104 on the blockchain network 100. The blockchain network 100 in Figure 1 is a proof-of-work blockchain, where miners 104 perform costly calculations to facilitate transactions on the blockchain. For example, a proof-of-work blockchain might require miners to solve cryptographic problems. In Bitcoin, miner 104 discovers a nonce, which, along with SHA-256, hashes the block header to a number smaller than a value determined by the current difficulty. The hashing ability required for the proof-of-work algorithm means that a transaction is considered virtually irreversible after a predetermined number of blocks have been mined at its top. Having solved the cryptographic problem, miner 104 creates a new block for the blockchain and broadcasts that new block to the other nodes 102. The other nodes 102 verify that miner 104 has indeed solved the cryptographic problem and thus 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., the distributed global ledger) by consensus of node 102.
[0040] A block created by miner 104 contains transactions (TXs) that were broadcast to the blockchain by node 102. For example, a block may contain a transaction from an address associated with one node 102 to an address associated with the other node 102. In this way, a block functions as a record of transfers from one address to another. Those who request that a transaction be included in a block prove that they are authorized to initiate the transfer (for example, authorized to use the output in the case of Bitcoin) by signing the request with their private key corresponding to their public key. A transfer can only be added to a block if the request is validly signed.
[0041] In the case of Bitcoin, there is a one-to-one correspondence between a public key and an address. That is, each public key is associated with a single address. Therefore, in this specification, transferring controlled resources (e.g., digital assets) to or from a public key (e.g., a payment to a public key), and transferring digital assets to or from an address associated with that public key, represent common operations.
[0042] Some nodes 102 may not act as miners, but instead participate as verification nodes. Transaction verification may include checking signatures and verifying references to valid UTXOs.
[0043] The example in Figure 1 includes six nodes (102), three of which participate as miners (104). In reality, the number of nodes (102) or miners (104) can vary. In many blockchain networks, the number of nodes (102) and miners (104) can be much larger than the number shown in Figure 1.
[0044] As described below, various nodes 102 may cooperate to form a group 110 that can collaboratively generate digital signatures under a threshold signature scheme. In the illustrated example, three nodes 102 are shown joining group 110. However, the actual number of members in group 110 can be much larger.
[0045] The techniques for joining, leaving, and participating in Group 110 are described in detail below.
[0046] Electronic devices that operate as nodes Figure 2 is a block diagram showing the components of an exemplary electronic device 200 that could function as a node 102 (Figure 1) of a peer-to-peer blockchain network 100 (Figure 1). The exemplary electronic device 200 may also be called a processing device. The electronic device can take various forms, including, for example, a desktop computer, a laptop computer, a tablet computer, a server, a mobile device such as a smartphone, a wearable computer such as a smartwatch, or other types of forms.
[0047] The electronic device 200 includes a processor 210, a memory 220, and an interface device 230. These components can be directly or indirectly coupled to each other and can communicate with each other. For example, the processor 210, the memory 220, and the interface device 230 can communicate with each other via a bus 240. The memory 220 stores a computer software program containing machine-readable instructions and data for performing the functions described herein. For example, the memory may contain processor-executable instructions that, when executed by the processor 210, cause the electronic device to perform the methods described herein. The processor-executable instructions may contain instructions that, when executed by the processor 210, cause the electronic device to perform protocols related to the blockchain network 100 (Figure 1). For example, the instructions may contain instructions for implementing the Bitcoin protocol.
[0048] Memory 220 can store the global ledger of the blockchain network 100 (Figure 1) or a portion thereof. That is, memory 220 can store all or some of the blocks of the blockchain, for example, the most recent block, or some of the information in several blocks.
[0049] Although memory 220 is shown as a single block in Figure 2, in reality, the electronic device 200 may include multiple memory components. These memory components can be of various types, including, for example, RAM, HDD, SSD, flash drive, etc. Different types of memory may be suitable for different purposes. Furthermore, although memory 220 is shown separately from the processor 210, the processor 210 may include built-in memory.
[0050] As shown in Figure 2, the processor 210 may include a secure area such as a Trusted Execution Environment (TEE) 250. The TEE 250 is an isolated execution environment that provides additional security to the electronic device 200, such as isolated execution, trusted application integrity, and asset confidentiality. The TEE 250 provides an execution space that ensures that computer instructions and data loaded within the TEE 250 are protected in terms of confidentiality and integrity. The TEE 250 may also be used to protect the integrity and confidentiality of critical resources such as keys. The TEE 250 is implemented at least partially at the hardware level, thereby protecting instructions and data executed within the TEE 250 from access and manipulation by the rest of the electronic device 200 and by external parties such as the owner of the electronic device. Data and calculations within the TEE 250 are protected from anyone operating node 102, which includes the TEE 250.
[0051] TEE250 can operate by instantiating an enclave and then adding pages of memory one by one while hashing cumulatively. A similar operation may also be performed on a remote machine (which may be a developer machine or another machine) so that the remote machine determines and stores the expected hash. Therefore, to ensure that the enclave is running an approved algorithm, the contents of the enclave can be verified by any remote machine. This verification may be performed by comparing hashes. Once the enclave is fully constructed, it is locked down. It is possible to execute code on TEE250 and send secrets to the code, but the code is immutable. The final hash is signed with an attestation key and may be made available to the data owner for verification before sending any secrets to the enclave.
[0052] An enclave is physically secure from access via the host system's architecture, including the host system's system memory, BIOS, and operating system. Therefore, an enclave enables the secure and verifiable execution of software on a remote computer owned and controlled by an untrusted party. Memory of a process running on an enclave is accessible only to that process and only when the enclave software is running. The contents of memory are encrypted when transmitted from the enclave to a remote computer or to the host system itself. Decrypting enclave data relies on keys available only to codes that hash to specific values. If the enclave code is modified, access to these keys is no longer available. Therefore, modifying the enclave code to access the data is impossible.
[0053] Furthermore, the TEE250 can enable remote authentication, which can be used by node 102 (Figure 1) to prove to other nodes 102 that the TEE250 is authentic and executing computer executable instructions approved with respect to the protocol implemented by group 110. Remote authentication can be provided by the TEE250 by executing a specific portion of code and internally sending a hash of the code signed with an internal authentication key relating to the enclave to the enclave. In fact, remote authentication allows the enclave of the TEE250 to prove to any remote system that it is executing computer executable instructions that hash to a specific value.
[0054] Remote authentication allows code running within a secure enclave to retrieve a signed certificate from the enclave, which is running within that enclave with a given hash of the enclave page cache. The hash of the enclave page cache may also be called a quote, and the enclave page cache is a protected section of memory where a given code and data resides during the execution of such code.
[0055] The TEE250 may include a secure random number generator, internal to the TEE's enclave, which can be used to generate a secret key, a random challenge, or other random data. The TEE250 may also be configured to read data from or write data to external memory. Such data can be encrypted with a secret key maintained only within the enclave. ("Random" here may be interpreted to include "pseudo-random").
[0056] TEE250 may be implemented, for example, using Intel's Software Guard Extensions (SGX). SGX supports remote authentication. Third-party authentication services, such as Intel Authentication Services (IAS), can certify that these signed statements originate from genuine CPUs that comply with the SGX specification.
[0057] The electronic device 200 operates as a node 102 (Figure 1) in the blockchain network 100 (Figure 1) and can join or participate in group 110 (Figure 1). As described below, group members (which may be referred to here as participants or nodes) collaborate to generate a valid signature in order to release the encambrance associated with the group's public key.
[0058] Threshold signature Group 110 may be an authorized or unauthorized group. Group 110 may be connected by any node 102 (Figure 1) in the blockchain network 100 (Figure 1) (i.e., by any node that monitors and stores at least some of the information in the blockchain).
[0059] Group 110 is associated with a public key, which may be called a group public key. This group public key can control and restrict access to resources such as tokens and cryptocurrencies transferred to the group public key. For example, a transaction locking script can use the group public key to lock resources so that such resources cannot be transferred or "consumed" without the approval of group 110.
[0060] Group 110 can operate according to a threshold signature scheme. More specifically, if a threshold number of nodes that are group members cooperate to generate a valid signature, resources restricted by the group's public key (burdened by emcamrance) can be unlocked (i.e., the emcamrance can be removed). The 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 only be used by their legitimate owners, and the threshold signature scheme described here allows a valid ECDSA signature to be generated by a threshold number of nodes in the group.
[0061] To enable group members to collaboratively generate valid signatures, member nodes maintain private secrets generated as separate units (i.e., private secrets generated by the node itself). As will be explained in more detail below, these private secrets can be used by member nodes to generate valid signatures for transactions without exposing their private secrets to other member nodes. In this way, an improved security mechanism is provided for controlling access to resources.
[0062] A threshold signature scheme that allows member nodes to join and leave a group without requiring a change to the group public key is described below. A plurality of nodes 102 (FIG. 1) within a blockchain network 100 (FIG. 1) can implement a threshold signature scheme as described herein. Such a node 102 can include computer-executable instructions stored in a memory 220 (FIG. 2) that implements a threshold signature scheme protocol. When executed by a processor 210 (FIG. 2), such instructions cause the node 102 (such as an electronic device 200 of the type described with reference to FIG. 2) to execute one or more methods of the threshold signature scheme protocol. Such methods may include any one or combination of methods 300, 400, 500, and 600 of FIGS. 3 through 6. The present method may be executed by a node while cooperating with other nodes related to other group members.
[0063] Group Initialization Referring here to FIG. 3, a method 300 for initializing a group is shown. The group is initialized for use in a threshold signature scheme. That is, the group is initialized to allow member nodes to cooperatively generate a valid digital signature to remove an encumbrance of a digital asset. The encumbrance removed by the valid digital signature is an encumbrance based on the group public key.
[0064] FIG. 3 shows a method executed by a plurality of nodes cooperating with each other. More specifically, each node that will be a group member executes the operations of method 300 described below. These nodes may be referred to as participants P i or members in subsequent descriptions. First, a group U of n participants (i.e., i = 1, 2,..., n) is included in executing method 300. In the illustrated example, the group is formed by three nodes (i.e., n = 3). However, a different number of nodes may be used to form the group. Each node executing method 300 is, respectively, an SGX enclave Ei Includes authenticated TEEs that implement it.
[0065] Before executing method 300, the nodes 102 that will form the group establish secure communication channels with each other and agree on a signature threshold (t+1). Each node and enclave can then privately communicate point-to-point after establishing a secure channel (e.g., using the Defie-Hellmann exchange method) and securely broadcast information to other participants. The participants also jointly determine the elliptic curve generation point G and its order p. The operations described below are performed using this elliptic curve generation point G and its order p. For example, the reference "mod p" refers to a modulo operation performed according to this order p. After the communication setup, the nodes perform dealer-free polynomial generation according to method 300 described below.
[0066] In Operation 302, each participant P i This is a polynomial f with randomness t. i To generate (x), each enclave E i Prepare the following, where x is the variable of the polynomial function. A polynomial of degree t is a polynomial of degree t (in a finite field of integers modulo p) with each of the coefficients of a randomly selected polynomial.
[0067] In Operation 304, authentication is performed so that each enclave confirms to each of the other enclaves that it is executing an approved set of initialization instructions. During authentication, each enclave may send a quote to each of the other enclaves, and thus each enclave receives a quote from each of the other enclaves. Each of these received quotes is evaluated to determine whether the authentication is successful or not.
[0068] In Operation 304, each Enclave E iOther Enclave E j Each of them has point f i (j)mod p is safely transmitted, where j=1,...n. Thus, in Operation 304, each enclave E i It is receiving points from other enclaves.
[0069] In Operation 306, each Enclave shared secrets. i This will be determined. More specifically, in Operation 306, each Enclave E i To determine the shared polynomial f(x), we sum up all receiving points: f1(i) + f2(i) + ... + f n (i) mod p. That is, the shared polynomial is the sum of all randomly generated polynomials of the participants. Next, the secret shared is s i =f(i) mod p, which is determined as P in polynomial f(x) mod p. i This is the point (i.e., the point at x=i), where,
[0070]
number
[0071] Therefore, each secret shared is determined as the sum of all points (i.e., values) of the other participants' random polynomials. Each participant only has different points in the shared polynomial, and thus the polynomial (and the shared secret (a0)) can be reconstructed (by interpolation) with t+1 points.
[0072] In Operation 306, each secret shared i Each Enclave E i Each enclave E is protected. iIt can also testify to the other enclave that it has executed an authorized command to generate the secret share. Therefore, remote authentication may be performed in Operation 306 to ensure that the secret share has been properly generated.
[0073] Once a secret sharing is generated, a group public key (which is an elliptic curve public key) may be generated in Operation 308. In Operation 308, Lagrangian interpolation may be used to determine the group public key corresponding to the shared secret a0. More specifically, the group participant P i (Here, i=1,...,t+1) Each prepares its own enclave to compute its own public key exchange based on the Lagrangian interpolation coefficients, elliptic curve generation points, and their secret sharing. That is, the public key exchange is b i s i It may also be calculated as ×G.
[0074] Here, b i teeth
number
[0075] During Operation 308, public key exchanges are broadcast by participants to all other participants. Remote authentication may be used to verify that the public key exchanges are generated correctly.
[0076] Once all public key shares have been received (i.e., after receiving a public key share from each other participant), each participant can calculate the group public key A based on the public key shares they have received. More specifically, the group public key can be determined as the sum of all public key shares:
[0077]
number
[0078] Notably, the initialization phase proceeds in an unreliable manner, and there is no trusted dealer, so there is no single point of failure. Performing polynomial generation and subsequent processing within the enclave protects the secret sharing, which allows deregistration (see Figure 5, described later) to remain secure.
[0079] Group participation after group initialization Referring here to Figure 4, registration method 400 is shown. Registration method 400 may be performed to allow a node to join a pre-existing group that has been initialized for use in a threshold signing scheme, without the need to issue a new group public key. Method 400 is performed after the group has already been initialized (such initialization may follow method 300 in Figure 3).
[0080] Figure 4 illustrates how multiple nodes cooperate to perform the operation. More specifically, existing group member nodes perform at least some of the operations of Method 400 described later, and future members perform at least some of the operations of Method 400. (P n+1 (May be specified as) A future member is the node that is trying to register to the group.
[0081] Prior to performing Method 400, at least one threshold group (t+1) of the participants notifies each other that they wish to register future members. These participants then register group U. E A secure communication channel is established between the nodes constituting the registration group and future members. Future members may also prove themselves to the nodes of the registration group.
[0082] In the example in Figure 4, registration group U E This includes three nodes (i.e., n=3). However, different numbers of nodes may be used to form a registration group, as long as the number of nodes forming the registration group is at least the threshold (t+1) number of nodes. In the illustrated example, future member P n+1 This is shown as P4. Each node running Method 400 is an SGX Enclave E i This includes authenticated TEEs that implement this feature.
[0083] In Operation 402, future member P4 verifies that the future member is running the authentication protocol, and registers group U E Provide all members with an attestation quote. This attestation quote is received by the registered group members, and each member of the registered group evaluates the attestation quote to ensure that future members are following the approval protocol.
[0084] In Operation 404, registered group members each share their own secrets. i Divide it into multiple parts. More specifically, each participant P i (i=1,···,t+1) represents each person's shared secret s i Prepare their enclave so that it is multiplied by the Lagrangian interpolation coefficient determined at the new point (n+1). That is, the modified secret share s i ' may be determined as follows:
[0085]
number
[0086] And each enclave is s i Generate secure random numbers such that each of ' is divided into t+1 parts (the sum of all such parts is s i(This should be done in this way), and that part may be called the secret shared part: s i '=s 1,i +s 2,i +···+s t+1,i
[0087] In Figure 4, (for example, s s,1 Subscript s (like) is a shared s i This is used to indicate that something is divided into t+1 parts.
[0088] Each Enclave E i The secret shared parts i,i It retains the remaining secret shared part and exchanges it with the other t enclaves of the registered group UE, thereby each enclave E i The following secret shared parts will be included: s i,1 ,s i,2 ,...,s i,t+1
[0089] Next, each enclave E i U E All secret shared parts received from all other members of that Enclave E i The secret shared parts that were maintained by i,i In addition, the total number of secret shares v j To obtain:
[0090]
number
[0091] In Operation 406, each Enclave E i Next, the secret shared data is transferred to the future member's Enclave E. n+1 Send to: More specifically, in Operation 406, each participant P of the registration group i Each then goes to its associated Enclave E iProvide this secret shared total v j Enclave E of future members n+1 Send privately to Enclave E of future members. n+1 The system receives these total secret shares from all members of the registered group, and then (in Operation 408) determines the total of all received secret shares to create new secret shares. n+1 To build:
[0092]
number
[0093] In the illustrated example, since n is equal to 3, the new secret share is shown as s4.
[0094] Therefore, future members acquire new secret shares based on secret sharing data received from multiple existing members of the group. More specifically, future members acquire new secret shares based on secret sharing data from at least a threshold number of existing members of the group.
[0095] As an additional verification step, after operation 406 of method 400, operation 308 of method 300 may be performed to generate a group public key. Participants can then verify that the group public key has not changed from its previous value (i.e., the value before method 400 in Figure 4 was performed).
[0096] Leaving the group Group members may occasionally leave the group. As used herein, disenrolling refers to the removal or cancellation of a member from the group. Such disenrollment may occur at the request of the member being disenrolled, or at the request of another member (for example, if the member to be disenrolled is not participating in group activities according to certain criteria). Referring here to Figure 5, an exemplary method 500 for disenrolling a member is shown. This method may be performed by node 102 in cooperation with other nodes 102 in the group. This method can be used to disenroll a member without modifying the group public key. Thus, the present invention provides a cryptographically secure and improved method that provides enhanced control over resources compared to what was previously possible in the prior art.
[0097] To achieve deregistration, a threshold number of n-1 existing group members cooperate to perform method 500 in Figure 5. More specifically, all group members remaining in the group participate in method 500 in Figure 5. However, group members who are to be deregistered do not participate in this method. In some cases, the number of deregistrations d n However, more than one group member may be deregistered at once, as long as it is less than or equal to the difference between the number of existing group members and the threshold of the threshold signing scheme. That is, d n The limit is ≤n-(t+1).
[0098] In other words, the number of group members who are not attempting to leave the group must be at least equal to the threshold t+1 of the threshold signature scheme.
[0099] In the example in Figure 5, an existing group of four members is modified to remove one participant (P4), leaving only three group members.
[0100] Before performing Method 500 in Figure 5, Participant P i(i = 1, ..., n - 1) communicate with each other, and cancel the share of group participant P n and notify a consensus to form an unregistration group U D . Remote authentication may be used to ensure that all enclaves of the unregistration group U D are operating an approved set of unregistration commands. More specifically, each member of the unregistration group verifies that the other members of the unregistration group are operating an approved set of unregistration commands.
[0101] In operation 502, each participant P i performs polynomial generation and sharing in the unregistration group U D . More specifically, each participant P i prepares its respective enclave to generate a polynomial f D of randomness t in the unregistration group U i 0 (x) (a0 = f i 0 (0) = 0).
[0102] In operation 502, each enclave E i (i = 1, ..., n - 1) then securely sends each point j in its new random polynomial f i 0 (j) to each of the other enclaves E j (j = 1, ..., n - 1). Each enclave authenticates the other enclaves via remote authentication.
[0103] In operation 504, each enclave E i (i = 1, ..., n - 1) generates a new secret sharing. More specifically, each enclave E i then determines a new secret sharing s i ' based on all the received points f j'(i)(j=1,...,n-1|j≠i) is the original secret shared s i Add to this. For example, a new secret share may be determined as follows:
[0104]
number
[0105] As an additional verification step, operation 308 of method 300 may be performed after operation 504 of method 500 to generate a group public key. Participants can then verify that the group public key has not changed from its previous value (i.e., the value before method 500 in Figure 5 was performed).
[0106] In Operation 504, previous secret sharing is overwritten with new secret sharing, and participant P is unregistered. n This effectively disables secret sharing within the enclave. Thus, its members are now removed from the group.
[0107] Notably, during deregistration method 500, the security of this scheme relies solely on nt participants overwriting their expired key shares with verifiable new values. Therefore, for security to be affected, a threshold number of enclaves (t+1) must be breached. Even if a deregistered participant manages to (as a last resort) breach their own enclave to recover their key shares, as long as at least nt enclaves are functioning correctly, those shares will not be useful in a collusive attack.
[0108] signature generation A secret shared by group members may be used to allow a valid ECDSA signature to be generated for a transaction. More specifically, at least a threshold number of secret shares may be used to enable group participants to generate valid signatures. The signature may be applied to a transaction that uses digital assets previously restricted by the group public key. That is, a valid signature removes any emcamrance previously placed on the resource. An ECDSA signature consists of two components: a first component r and a second component w.
[0109] Referring now to Figure 6, an exemplary method 600 for generating an ECDSA signature is shown. Method 600 may be performed by node 102 in cooperation with other nodes 102 of a previously formed group. The members of the group (i.e., the nodes that collaboratively perform Method 600) may be predetermined using the techniques described above.
[0110] Prior to execution, several participants within a group (i.e., members) can inform other participants that they wish to participate in distributed signature generation to authenticate a particular transaction Tx. That is, a node can indicate its willingness to participate in the distributed signature generation of transaction Tx. Transaction (Tx) is a transaction that will use outputs restricted by the group public key. That is, the effect of the transaction will be to remove the restrictions based on the group public key from the outputs. Transaction Tx may be proposed, for example, by one of the participants in the group.
[0111] When a threshold number of participants signal their intention to participate, the nodes cooperate with each other to form a signing group. In the illustrated example, the signing group contains three participants (i.e., three nodes). However, a signing group can contain a different number of nodes.
[0112] In operation 602, the node forming the signature group determines the hash z for the transaction Tx. The hash is determined as: z = H(Tx), where H represents a hash function. The hash is determined by consensus of the signature group. For example, the hash may be proposed by one of the participants in the signature group, and the other members may verify the match with the hash.
[0113] In operation 604, the node forming the signature group, based on the secure random number k, obtains: a) the reciprocal k of the secure random number -1 ; 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 generation point G. More specifically, in operation 604, one of the participants, for example P1, generates the secure random number k, calculates the reciprocal k of this secure random number -1 , and also prepares its own enclave E1 (which is associated with the trusted execution environment of the node that is the participant) to calculate the first signature component r. The first signature component r may be determined as follows: r = (k × G) x mod p
[0114] In operation 604, the enclave E1 that calculates the reciprocal k of this secure random number -1 and the first signature component r sends these values (for example, the reciprocal k of this secure random number -1 and the first signature component r) to the enclaves E2,..., E t+1 associated with the other participants within the signature group. The enclave that sends these values remotely authenticates their integrity and authenticates that they were generated using an approved instruction set. The enclaves E2,..., E t+1 that did not generate these values receive them from the enclave E1 that generated them and verify the integrity of the values (for example, by verifying that the instruction set used to generate these values is an approved instruction set).
[0115] In Operation 606, each node in the signing group performs a partial signature based on the private secret sharing, the reciprocal of a secure random number, and the first signature component. i To decide. Partial signature v i These are generated within the enclave of each node. For example, in the signature group enclave E i (i=1,...,t+1) computes a partial signature as follows: v i =k -1 rb i s i mod p Here, b i teeth:
number
[0116] Therefore, determining partial signatures may involve performing Lagrangian interpolation.
[0117] In Operation 606, each Enclave E concerning the signing group i (i=1,...,t+1) is such that each node (more specifically, each enclave) receives a partial signature from the other nodes in the signing group, and their partial signature v i This is then securely broadcast to other enclaves related to the signing group.
[0118] In Operation 608, each node (more specifically, each enclave) of the signature group can generate a second signature component w based on the partial signature determined and received in Operation 606. For example, the second signature component may be determined as follows:
[0119]
number
[0120] In Operation 608, each node in the signing group may send an ECDSA signature, including the first and second signature components, from its enclave to the host portion of the node (i.e., the non-enclave portion of the node), and the node may verify the signature against the transaction hash (z) and the group public key (A).
[0121] Subsequently, any participant in the signing group can add their signature to the corresponding transaction and broadcast it to the blockchain network.
[0122] The security of the aforementioned signing scheme relies on a fleeting private key value, a secure random number generated by one enclave and secretly distributed and hidden to other enclaves in the signing group. If this value were to be extracted by breaching just one of the enclaves, the shared private key could be determined from the transaction signature and used to sign a completely different transaction. However, the impact would be minimal because the physical breach of an enclave would have to occur within a very short time window (the transaction confirmation time in the blockchain).
[0123] It should be noted that the embodiments described above are illustrative and not limiting to the present invention, and that those skilled in the art can design many alternative embodiments without departing from the scope of the invention as defined by the appended claims. In the claims, any reference numerals enclosed in parentheses should not be construed as limiting the claims. Words such as “includes” and “contains” do not exclude the existence of any elements or steps other than those enumerated in any claims or throughout the specification. In this specification, “has” means “includes or consists of,” and “has” means “includes or consists of.” A single reference to an element does not exclude multiple such elements, and vice versa. The present invention can be carried out by hardware comprising several individual elements and by a appropriately programmed computer. In apparatus claims enumerating several means, some of these means may be embodied by a single identical hardware item. The mere fact that certain multiple matters are described in mutually distinct dependent claims does not imply that combinations of these matters cannot be advantageously utilized.
[0124] (Note 1) A computer-based security method comprising the step of generating an elliptic curve digital signature algorithm signature including a first signature component r and a second signature component w, wherein the generating step is: A node forms a signing group with other nodes; The step of obtaining, based on a secure random number, a) the reciprocal 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 generation point; The node performs the step of determining a partial signature based on the sharing of a private secret, the reciprocal of the secure random number, and the first signature component; The node receives a partial signature from another node in the signature group; and The node generates the second signature component w based on the partial signature determined and received; A method that includes running on a computer. (Note 2) The method, as described in Appendix 1, is performed on a computer, wherein the acquisition step includes generating the reciprocal and the first signature component, and the method further includes sending the reciprocal to the other node. (Note 3) The acquisition step is a method performed on a computer as described in Appendix 2, which includes the step of preparing an enclave associated with the trusted execution environment of the node in order to generate the secure random numbers. (Note 4) The acquisition step is a method performed on a computer as described in any one of the appendices 1-3, which includes the step of receiving the reciprocal and the first signature component from one of the other nodes. (Note 5) A method performed on a computer as described in any one of the appendices 1-4, further comprising the step of signaling an intention to participate in distributed signature generation before forming the aforementioned signature group. (Note 6) The partial signature is determined within an enclave associated with the trusted execution environment of the node, and is performed on a computer as described in any one of the items in Appendix 1-5. (Note 7) The aforementioned partial signature is determined by performing Lagrangian interpolation, using a computer method described in any one of the appendices 1-6. (Note 8) The method is performed on a computer as described in any one of Appendix 1-7, the method further comprising the step of sending the elliptic curve digital signature algorithm from the enclave to the host portion of the node after the second signature component has been generated. (Note 9) A method performed on a computer as described in any one of Appendix 1-8, further comprising the step of adding the aforementioned signature to a transaction and broadcasting it to the blockchain network. (Note 10) A method performed on a computer as described in any one of Appendix 1-9, further comprising the step of obtaining the secret share based on secret share data received from several existing members of a group before forming the signing group. (Note 11) The secret sharing is determined within an enclave associated with the trusted execution environment of the node and is performed on the computer described in Appendix 10. (Note 12) Said partial signature v i teeth: v i =k -1 rb i s i mod p It was decided as b i is the Lagrangian interpolation coefficient, and k -1 is the reciprocal of the secure random number, and s i A method performed on a computer as described in any one of the appendices 1-11, wherein is the secret share, r is the first signature component, and p is the degree. (Note 13) A computer-readable storage medium containing computer-executable instructions that, when executed, configure the processor to perform the method described in any one of the items in Appendix 1-12. (Note 14) Interface devices; A processor coupled to the aforementioned interface; Memory coupled to the aforementioned processor; An electronic device comprising a memory which stores computer executable instructions that, when executed, configure the processor to perform the method described in any one of the appendices 1-12. (Note 15) The electronic device described in Appendix 14, wherein the processor includes a trusted execution environment, and the computer executable instructions are executed within the trusted execution environment.
Claims
1. A computer execution method performed by a processing resource to control access to a resource, comprising the step of generating an elliptic curve digital signature algorithm signature including a first signature component r and a second signature component w, wherein the generating step is: A node forms a signing group with multiple other nodes; The node obtains, based on a secure random number k, a) the reciprocal of the secure random number k k - 1 and b) the first signature component r, wherein the first signature component is determined based on the secure random number and the elliptic curve generation point, and the first signature component r is r=(k×G) x mod p The steps are determined based on the secure random number k, the elliptic curve generation point G, and the degree p, such that: The step of determining a partial signature vi by the node, wherein the partial signature vi is: v i =k −1 rb i s i mod p The step is determined as follows: bi is the Lagrangian interpolation coefficient, k-1 is the reciprocal of the secure random number, si is the secret share, r is the first signature component, and p is the degree; The step of receiving partial signatures vi from multiple other nodes of the aforementioned signing group; The step of generating the second signature component w, [Math 1] And z is the transaction hash, step; A step of using the aforementioned signature to control access to and / or transfer of resources over a computer network; A method that includes this.
2. The method according to claim 1, wherein the second signature component w is generated based on a determined and received partial signature.
3. The computer-based method according to claim 1, wherein the acquisition step includes the step of generating the reciprocal and the first signature component, and the method further includes the step of transmitting the reciprocal to the plurality of other nodes.
4. The method performed on a computer according to claim 3, wherein the acquisition step includes the step of preparing an enclave associated with the trusted execution environment of the node in order to generate the secure random numbers.
5. The method performed on a computer according to claim 1, wherein the acquisition step includes receiving the reciprocal and the first signature component from one of the plurality of other nodes.
6. The method performed on a computer according to claim 1, further comprising the step of signaling an intention to participate in distributed signature generation before forming the signature group.
7. The method executed on a computer according to claim 1, wherein the partial signature is determined within an enclave associated with the trusted execution environment of the node.
8. The method performed on a computer according to claim 1, wherein the partial signature is determined by performing Lagrangian interpolation.
9. The method performed on a computer according to claim 1, wherein the second signature component is generated within an enclave associated with a trusted execution environment, and the method further comprises the step of sending an elliptic curve digital signature algorithm from the enclave to the host portion of the node after generating the second signature component.
10. The method performed on a computer according to claim 1, further comprising the step of adding the signature to a transaction and broadcasting it to a blockchain network.
11. The method performed on a computer according to claim 1, further comprising the step of obtaining the secret share based on secret share data received from multiple existing members of a group before forming the signature group.
12. The method executed on a computer according to claim 11, wherein the secret sharing is determined within an enclave associated with the trusted execution environment of the node.
13. A computer-readable storage medium containing computer-executable instructions that, when executed, configure a processor to perform the method described in claim 1.
14. Interface device; A processor coupled to the aforementioned interface; Memory coupled to the aforementioned processor; An electronic device comprising a memory which, when executed, constitutes a computer executable instruction that, when executed, performs the method according to claim 1.
15. The electronic device according to claim 14, wherein the processor includes a trusted execution environment, and the computer executable instructions are executed within the trusted execution environment.