Voucher generation and distribution method and system for block chain network

Abstract

A method and apparatus for managing secure distribution of credentials from a group of autonomous private nodes to a requesting node. Secure distribution of credentials may use a secret share and a group private key that neither reconstructs nor owns by any node. The credential includes an identifier for the requesting node and a secret point combined by the node from a portion of the secret point provided by each of the plurality of private nodes, where the secret point is based on a mapping of the group private key and the identifier of the requesting node to a point hash.

Description

[0001] This application is a divisional application of the patent application with Chinese application number 201880037501.3 (PCT international application number PCT / IB2018 / 053981), application date June 4, 2018, and name “Credential Generation and Distribution Method and System for Blockchain Network”. Technical Field

[0002] The present invention relates generally to blockchain transactions, and more particularly to methods and devices for establishing trusted peer-to-peer communications between nodes. Background Art

[0003] In this document, we use the term "blockchain" to include all forms of electronic, computer-based distributed ledgers, including but not limited to consensus-based blockchain and transaction chain technologies, permissioned and unpermissioned ledgers, shared ledgers and their variations. It should be noted that the present invention is not limited to the use of a specific blockchain, and other alternative blockchain implementations and protocols also fall within the scope of the present invention.

[0004] A blockchain is a consensus-based electronic ledger implemented as a decentralized, distributed computer-based system consisting of blocks, which in turn consist of transactions. Each transaction (Tx) is a data structure that encodes the transfer of control of a digital asset between participants in a blockchain system, and the data structure includes at least one input and at least one output. Each block contains a hash of the previous block, and the blocks are linked together to create a permanent, unchangeable record of all transactions written to the blockchain since its creation. Transactions contain small programs called scripts embedded in their inputs and outputs that specify how and by whom the outputs of the transaction can be accessed. These scripts are written using a stack-based scripting language.

[0005] A network node that receives a new transaction will quickly attempt to push that transaction to other nodes in the network. Before a new transaction is transmitted to other nodes, it is "validated," meaning that it is checked against a set of criteria to ensure that it meets the basic requirements for a proper transaction under the applicable blockchain protocol.

[0006] To write a transaction to the blockchain, a node incorporates that transaction into a block, which is designed to collect transactions and form those transactions into blocks. The node then attempts to complete the "proof of work" associated with that node. The successful node adds its confirmed block to the blockchain, and the block propagates through the network so that other nodes that maintain a copy of the blockchain can update their records. The node that receives the block also "validates" the block and all the transactions in it to ensure that it meets the formal requirements of the protocol.

[0007] One of the challenges in a decentralized peer-to-peer system is ensuring that a node can communicate with another node in the network on a trusted basis. As the network architecture of some implementations evolves, some nodes may take on more specialized tasks, while other nodes may rely on those specialized nodes as sources of certain data or performers of certain functions. If a node is to rely on another node for information or as a legitimate source, it needs to be able to establish a trusted relationship to communicate with that node. In cases where nodes may have different roles, it is best to have a mechanism to determine and verify the role of a node. In addition, if a node is proven to be illegitimate or malicious, other nodes should be able to remember the node and ignore future communications from such a node. In a peer-to-peer system, the challenge is to address these issues by imposing a central authority without compromising the peer-to-peer nature of the system. Summary of the invention

[0008] Such a solution has now been devised.

[0009] Hence, according to the present invention there is provided a method and system as defined in the accompanying claims.

[0010] The present application may describe and disclose methods and apparatus for managing secure distribution of credentials from an autonomous group of dedicated nodes to a requesting node. The secure distribution of credentials may use a secret share and a group private key that is not rebuilt or possessed by any node. The credential includes an identifier for the requesting node and a secret point that is assembled from portions of a secret point provided by each of a plurality of dedicated nodes, wherein the secret point is based on a map-to-point hash of the group private key and the identifier of the requesting node. In some embodiments, the node may be a blockchain node.

[0011] The present application may further describe and disclose methods and apparatus for two nodes to authenticate each other under the attestation of an autonomous private node group without involving the group or a decentralized certificate manager or authenticator. The method may include a first node and a second node deriving a same session key using a bilinear pairing operation including their respective identifiers and a secret point. Assuming the secret point and the identifier are obtained from the group using a group private key, the bilinear pairing operation results in the generation of the same session key at each of the two nodes, thereby authenticating their respective credentials and enabling trusted communication between the two nodes.

[0012] Additionally or alternatively, the present application describes a computer-implemented method for a node to obtain a credential from a group of dedicated nodes, each dedicated node having a private key share of a group private key. The method may include: sending a request for the credential from the node to a plurality of dedicated nodes, wherein the node has an identifier; receiving a portion of a secret point from each of the plurality of dedicated nodes, the portion of the secret point being generated by the node from the identifier and the node's private key share; generating the secret point by combining the received portions of the secret point, wherein the secret point is a mapping to a point hash of the group private key multiplied by an identifier, the credential being the identifier and the secret point. None of the dedicated nodes or the nodes may be required to obtain a complete copy of the group private key.

[0013] Additionally or alternatively, the present application describes a computer-implemented method for forming a node to obtain credentials from a group of dedicated nodes (the method for forming a node to obtain credentials from a group of dedicated nodes), each dedicated node having a private key share of a group private key, wherein the method comprises: sending a request for the credential from the node to a plurality of the dedicated nodes, wherein the node has an identifier, wherein the identifier comprises an identifier string identifying the node, and a role string identifying a role of the dedicated node group, wherein the identifier is formed according to a concatenation of the identifier string, the role string, and an expiration time of the credential; receiving from each of the plurality of the dedicated nodes a portion of a secret point, the portion of the secret point being generated by the node from the identifier and the node's private key share; and generating the secret point by combining the received portions of the secret point. wherein the secret point comprises a mapping to a point hash of the group private key multiplied by the identifier, the credential comprising the identifier and the secret point; wherein obtaining a complete copy of the group private key does not require any of the dedicated nodes and the node; and wherein the node is not a member of the group of dedicated nodes.

[0014] In some embodiments, sending the request includes sending a separate request to each of the plurality of dedicated nodes. The identifier may include an identifier string identifying the node and a role string identifying the dedicated node group role. In some cases, the identifier also includes an expiration time of the credential, and in some other cases, sending the request includes sending the identifier string, and wherein receiving includes receiving the identifier.

[0015] In some embodiments, generating the secret point comprises combining portions of the received secret point. In some example embodiments, combining may comprise summing.

[0016] In some embodiments, the secret point is generated using a secret share (secret share) and based on a group private key. In some cases, the secret share (secret share) uses Lagrange interpolation and private key shares of multiple dedicated nodes without reconstructing the group private key.

[0017] Additionally or alternatively, the present application may describe a computer-implemented method for a first node to establish trusted communication with a second node, the second node having a second node identifier and a second secret point, the second secret point being a group secret key multiplied by a mapping-to-point hash of the second node identifier, the group secret key being associated with a node group for granting credentials. The method may include: obtaining a first secret point from the node group, wherein the first secret point is a group secret key multiplied by a mapping-to-point hash of a first node identifier; sending the first node identifier to the second node; receiving the second node identifier; generating a first session key using a bilinear pairing operation, a mapping-to-point hash of the second node identifier, and the first secret point together; confirming that the first session key matches a second session key, the second session key being generated by the second node using a bilinear pairing operation, the second secret point, and a mapping-to-point hash of the first node identifier together.

[0018] In some implementations, the generating of the first session key by a bilinear pairing operation is represented by one of the following expressions:

[0019] K A =e(H1(id B ),s A ),and

[0020] K A =e(s B ,H1(id A )),

[0021] Generating the second session key by a bilinear pairing operation is represented by another of the expressions, and wherein e() is a bilinear pairing operation, H1() is a mapping to a point hash, idA and id B are respectively one of the first node identifier and the second node identifier, s A and B One of the first secret point and the second secret point respectively.

[0022] In some embodiments, obtaining the first secret point includes obtaining portions of the first secret point from each of a plurality of nodes in the node group and combining the portions to form the first secret point without reorganizing the group private key.

[0023] In some embodiments, the confirming includes sending a challenge encrypted with the first session key from the first node to the second node, receiving a response to the challenge, and determining, based on the response, that the second node validly decrypted the challenge using the second session key.

[0024] In some embodiments, the sending further comprises sending a first random number, and wherein the receiving further comprises receiving a second random number and a calculated C0 value, wherein the C0 value comprises a hash of a concatenation of the second session key, the first random number, and the second random number. In some of these cases, the concatenation further comprises the first node identifier and the second node identifier. In some of these cases, the generating comprises generating a calculated C1 value, the C1 value comprising a hash of a concatenation of the first session key, the first random number, and the second random number, and wherein the confirming comprises confirming that the calculated C0 value matches the calculated C1 value.

[0025] In some embodiments, the second secret point is a mapping-to-point hash of the group private key multiplied by the second node identifier.

[0026] In some embodiments, the first secret point and the second secret point are each provided to the first node and the second node, respectively, by the node group using secret sharing.

[0027] Additionally or alternatively, the present application may describe a node comprising one or more processors, a memory, a network interface, and an application comprising processor-executable instructions that, when executed, cause the node to perform the operations of one or more of the methods described herein.

[0028] Additionally or alternatively, the present application may describe a node, comprising: a processor; a memory; a network interface; and an application, wherein the application contains processor-executable instructions for obtaining a credential from a group of dedicated nodes, each of the dedicated nodes having a private key share of a group private key, wherein when the processor-executable instructions are executed, the processor-executable instructions cause the node to: send a request for the credential to a plurality of the dedicated nodes, wherein the node has an identifier, wherein the identifier includes an identifier string identifying the node, and a role string identifying a role of the dedicated node group, wherein the identifier is based on the identifier string. The credential is formed by a concatenation of a string, a role string and an expiration time of the credential; receiving a portion of a secret point from each of a plurality of the dedicated nodes, the portion of the secret point being generated by the node from the identifier and a private key share of the node; and generating the secret point by combining the received portions of the secret point; wherein the secret point comprises a mapping to a point hash of the group private key multiplied by the identifier, and the credential comprises the identifier and the secret point; wherein obtaining a complete copy of the group private key does not require any of the dedicated nodes and the node; and wherein the node is not a member of the dedicated node group.

[0029] Additionally or alternatively, the present application may describe a non-volatile processor-readable medium storing processor-executable instructions that, when executed by one or more processors, cause the one or more processors to perform the operations of one or more of the methods described herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] These and other aspects of the invention will become clear and elucidated with reference to the embodiments described herein. Embodiments of the invention will now be described by way of example only and with reference to the accompanying drawings, in which:

[0031] Figure 1 An example network of blockchain nodes is shown;

[0032] Figure 2 Schematically illustrating a blockchain node requesting a credential from a dedicated blockchain node group or network of dedicated blockchain nodes;

[0033] Figure 3 Schematically illustrating an example implementation in which a blockchain node obtains partial credentials from the dedicated blockchain node group;

[0034] Figure 4 An example process for obtaining credentials from a blockchain node group is shown in flowchart form;

[0035] Figure 5A schematic diagram showing an example process of two blockchain nodes authenticating each other with credentials obtained from a dedicated blockchain node group;

[0036] Figure 6 A schematic diagram showing another example process of two blockchain nodes authenticating each other with credentials obtained from a dedicated blockchain node group;

[0037] Figure 7 A simplified block diagram of an example blockchain node is shown. DETAILED DESCRIPTION

[0038] In the present application, the term “and / or” is intended to cover all possible combinations and subcombinations of the listed elements, including any one of the listed elements individually, in any subcombination or all the elements, and does not necessarily exclude additional elements.

[0039] In the present application, the phrase "at least one of... or..." is intended to cover any one or more of the listed elements, including any one listed element alone, any subcombination, or all elements, without necessarily excluding any other elements, and without necessarily requiring the presence of all elements.

[0040] Although the examples described below refer to implementation in the context of a blockchain network, it should be understood that the present application is not necessarily limited to blockchain nodes or implementation in a blockchain network.

[0041] First reference Figure 1 , Figure 1 An example network associated with a blockchain is shown in block diagram form, which may be referred to herein as a blockchain network 100. The blockchain network 100 is a peer-to-peer open membership network that anyone can join without invitation or consent from other members. Distributed electronic devices running an instance of a blockchain protocol (under which the blockchain network 100 runs) may participate in the blockchain network 100. Such distributed electronic devices may be referred to as nodes 102.

[0042] The electronic devices that run the blockchain protocol and form the nodes 102 of the blockchain network 100 may be of various types, including, for example, computers (e.g., desktop computers, laptops, tablet computers, servers), mobile devices (e.g., smartphones), wearable computers (e.g., smart watches), or other electronic devices.

[0043] The nodes 102 of the blockchain network 100 are connected to each other using suitable communication technologies, which may include wired and wireless communication technologies. In many cases, the blockchain network 100 is at least partially implemented by the Internet, and some nodes 102 may be located in geographically dispersed locations.

[0044] Nodes 102 maintain a global ledger of all transactions on the blockchain, divided into groups of blocks, each containing a hash of the previous block in the chain. The global ledger is a distributed ledger, and each node 102 can store a full copy or a partial copy of the global ledger. Transactions that affect the global ledger through nodes 102 are verified by other nodes 102, thereby maintaining the validity of the global ledger. One of ordinary skill in the art will understand the details of implementing and operating a blockchain network.

[0045] Each transaction typically has one or more inputs and one or more outputs. Scripts embedded in the inputs and outputs specify how and by whom the output of the transaction can be accessed. The output of a transaction can be an address to which the value is transferred as a result of the transaction. The value is then associated with that output address as an unspent transaction output. Subsequent transactions can take that address as an input to spend or disperse that value.

[0046] Nodes 102 may be of different types or categories depending on their functionality. It has been proposed that basic functions associated with nodes 102 include: wallet, full blockchain maintenance, and network routing. These functions may also have variations. Nodes 102 may have more than one of these functions. For example, a "full node" provides all functions. A lightweight node may be implemented, for example, in a digital wallet and may only have wallet and network routing functions. Instead of storing the entire blockchain, a digital wallet may track block headers, which are used as indexes when querying blocks.

[0047] In current implementations of blockchains, each node that receives a block first validates the block before sending the block to other nodes. The time required to validate a block slows down the propagation of blocks through the network. Note that some implementations of blockchains, including evolutions of existing protocols, may provide block validation only by a subset of nodes rather than by every node in the network. However, block validation by a majority of nodes may still be a feature of any blockchain implementation to prevent invalid blocks from propagating through the network.

[0048] Validating a block involves confirming that the block meets the specified standards set by the applicable blockchain protocol. In addition to confirming that the block itself meets the specified standards, each transaction within the block can also be evaluated for compliance with transaction-level standards.

[0049] Typically, transaction-level validation criteria are the specified characteristics that a transaction must possess to be considered valid under the applicable blockchain protocol. Similarly, block-level validation criteria are the specified characteristics that a block must possess to be considered valid under the applicable blockchain protocol.

[0050] Certain evolutions of blockchains may provide services for more specialized nodes. For example, there may be nodes that are constructed as storage nodes with large amounts of fast-access memory and large amounts of network communication resources. Storage nodes may implement a distributed transaction database ("memory pool") that stores unconfirmed transactions. In some embodiments, storage nodes may implement a distributed unspent transaction output database for unspent transaction outputs. In some cases, these distributed databases may be implemented in the form of distributed hash tables. Another example is that some nodes may be constructed as validator nodes that are designed to focus on rapid verification and propagation of transactions. Validator nodes and storage nodes may facilitate an increase in transaction volume associated with large-scale payment processing by forming a fast trader network within the blockchain network 100 that is designed for distributed large-capacity storage and rapid verification and propagation of transactions.

[0051] The significant growth in the number of transactions used in payment processing will increase the volume of transactions stored in each memory pool. Assuming the average size of a transaction (TX) is 500 bytes and the transaction rate is ~104TX / s, the memory pool may receive ~400GB of daily incoming data. All of this data needs to be stored in the memory pool of unconfirmed transactions for different periods of time. Therefore, in some embodiments, the node network may use a shared memory pool implemented by a distributed hash table (DHT) to store the unconfirmed transaction pool instead of storing the complete memory pool at each node. In such an embodiment, certain types of nodes may not have to maintain a complete memory pool locally to reduce their burden of storing and updating very large unconfirmed transaction pools. Instead, dedicated nodes may rely on a storage network and / or a validator node to manage the maintenance of the memory pool. In some of the examples below, the term "dedicated node" may be used to refer to nodes with specific roles in a blockchain network, such as a validator node, a storage node, etc.

[0052] In one example implementation of a blockchain network of nodes, the blockchain network includes a plurality of dedicated nodes. In this example, the dedicated nodes are physically and logically distributed throughout the network. It is understood that the blockchain network may include other types of nodes, which may include full nodes, simplified payment verification (SPV) nodes (e.g., wallets), and other dedicated nodes with focused uses.

[0053] In another example implementation of the blockchain network, the dedicated nodes form a (logical) overlay network within the blockchain network. The overlay network can be used to ensure fast communication between dedicated nodes within the overlay network to ensure fast access and retrieval from the shared memory pool.

[0054] In this example, a dedicated node may be implemented as part of the structure to facilitate rapid transaction validation and propagation, thereby facilitating large payment processing through the blockchain network. In this regard, the dedicated node may be a validator node that focuses on transaction validation and propagation, without the need to store the memory pool or verify transactions. In this example, the dedicated node may have direct access to the memory pool because it participates in the DHT-based storage of the memory pool, or may have access to the memory pool via one or more storage nodes.

[0055] Restructuring the blockchain network and the roles of individual nodes to encourage fast transaction processing can create challenges in ensuring the growth of the blockchain and non-malicious participation of individual nodes. It is important to maintain the decentralization of the blockchain network by avoiding control exerted by one or more central authorities. In order for the network to function properly, dedicated nodes will interact in a way that ensures that each node reliably performs its own function or role and that other nodes can be trusted to reliably perform their functions or roles. To this end, interactions between dedicated nodes can use multiple transactions that promote cooperation in the pursuit of fast propagation of blocks.

[0056] In one example of an overlay network comprising multiple dedicated nodes, the dedicated nodes implement the memory pool as a shared memory pool, using, for example, a DHT to store a large database of unconfirmed transactions in a distributed manner among the dedicated nodes. However, this is just one example implementation, and in some other implementations, each dedicated node may store a complete copy of the memory pool.

[0057] In some examples, some nodes want to be able to authenticate that a dedicated node is a legitimate member of a pool of dedicated nodes. Similarly, among the dedicated nodes themselves, they may need to authenticate the identity of one of the dedicated nodes and the authority of that node to participate in collaborative work. In many network architectures, this functionality is achieved by implementing a central authentication service (such as a certificate authority, etc.) that centrally manages credentials and authenticates participating nodes. However, this architecture is unwelcome in a distributed peer-to-peer architecture, where central control or central authority should be avoided.

[0058] As blockchain network architectures evolve to accommodate nodes with special roles (whether for validation, storage, or other functions), the same issues may arise in other parts of the blockchain network. These nodes act as members of a group with a specific role, and other members of the group with that role want to be able to identify and authenticate membership in that group. Similarly, nodes that are not members of the group but interact with and need to "trust" nodes dedicated to the group want to be able to authenticate the node's membership in the group. It would therefore be desirable to enable nodes to authenticate identity and membership without imposing a centralized certificate authority on a decentralized blockchain network.

[0059] In one aspect, the present application provides a method and apparatus for authenticating a node by relying on a distributed private key share between a group of nodes, the group of nodes being members of a dedicated node group. Thus, credentials are generated and provided to a requesting node through the collaboration of the dedicated nodes in the group, such that no single dedicated node can provide valid credentials to the requesting node alone.

[0060] On the other hand, the present application provides a method for establishing a trusted communication channel between two nodes by confirming that each node has a credential granted by the same group of nodes. The nodes involved in the trusted communication channel can all be members of the group that grants the credential, but not necessarily members. In one example, one node is a member of a dedicated node group, while the other is not. Confirmation of the validity of the credentials of the two nodes can be based on each node using a bilinear pairing operation to generate a key to ensure that the keys match. The bilinear pairing operation for the node may include a mapping of the identifier of the other node to a point hash and a secret point collaboratively generated by the node group and provided to the node, the mapping to the point hash and the secret point as independent variables.

[0061] Reference Figure 2 , Figure 2 Schematically illustrated is a dedicated node group 502. A requesting node 504 wishes to obtain credentials from the dedicated node group 502 in order to be able to prove its identity as one of the dedicated nodes or as a node communicating with one of the dedicated nodes. The requesting node 504 may or may not be part of the dedicated node group 502.

[0062] The requesting node 504 sends a request 506 for a credential to the node group 502. The request 506 is associated with an identifier of the requesting node 504. The identifier may be generated by the requesting node 504 and sent with the request 506 in some embodiments. For example, the requesting node 504 may generate its identifier "Alice" and tell the node group 502 that its identity (id) is Alice. In some embodiments, the identifier may be assigned by the node group 502, or more specifically, assigned by one of the nodes in the node group 502 and communicated to the requesting node 504. In some embodiments, the requesting node 504 provides its "name" or identifier string, such as "Alice", to the node group 502, which may be any alphanumeric string or other unique identifier. The node group 502 may concatenate additional information to the identifier string to generate an identifier for the requesting node 504. For example, the node group 502 may combine the identifier string with the name or identifier of the node group 502. In some embodiments, the name is a "role" or function of the node group 502, such as "validator", etc. In some embodiments, the node group 502 may combine an identifier string with an expiration time of a credential, so that any other node evaluating the credentials of the requesting node 504 can evaluate whether the credential is still unexpired based on its identifier. In an example embodiment shown below, the identifier of the requesting node 504 is formed based on a concatenation of an identifier string (e.g., Alice), a role string, and an expiration time of the credential, the role string being used to identify the functional role of the node group 502 or the node. Other possible implementations of the identifier will be understood by those of ordinary skill in the art.

[0063] Each node in node group 502 includes a share k of private key k i Secret sharing is used in threshold cryptosystems where a secret k is distributed among n users so that at least t+1 participants need to collaborate to reconstruct k. Knowing any t of the secret k does not allow one of the remaining ones to determine it.

[0064] Secret sharing is based on polynomial interpolation and assumes that the secret is an element of a finite field F. The scheme consists of a dealer (there is also a dealerless version), a set of n participants U1,...,U n In this protocol, an arbitrary random secret is stored as f(0) in a t-degree polynomial f(x), and only node i can calculate its share f(x i ). If t+1 of the n nodes cooperate, they can reconstruct any point on f(x) with shares k1,k2,...,k of key kn Corresponding to f(x1),f(x2),...,f(x n ). The Lagrange polynomial interpolation method provides the ability to reconstruct the t-order function f(x) using t+1 points:

[0065] p={(x1,f(x1)),(x2,f(x2)),...,(x t+1 ,f(x t+1 ))}

[0066]

[0067] in,

[0068]

[0069] Note: i,p (x i )=1 and b i,p (x j )=0. Here, b i is the interpolation coefficient.

[0070] In embodiments involving non-trader share allocations:

[0071] 1. Assign each node i a known x i . Each x i Must be unique.

[0072] 2. Each node i generates t random polynomials f i (x).

[0073] 3. Each node i secretly sends its own value in polynomial f to every other node. i (x j )mod n.

[0074] 4. Each node i will receive all f1(x i ),f2(x i ),...f p (x i ) and all mod n additions (where n is the base domain F n Characteristics (F n It can also be expressed as GF(n),Z / nZ)) to form k i =f(x i )mod n, which is the fraction of the polynomial f(x)mod n.

[0075] Refer to Figure 2 In the example of FIG. 5 , the nodes in the node group 502 cooperate to generate a secret point s for the requesting node 504.A , as shown by reference numeral 508. Secret point s A In the cyclic group G1, its importance can be clearly seen from the following explanation of handshake and pairing. The secret point is related to the identifier according to the following relationship:

[0076] s A =k·H1(id A )

[0077] Among them, id A is the identifier of the requesting node 504. In some embodiments, the credential may be treated as (id A ,s A ). H1 is a hash function that maps to points, which will be explained in more detail below.

[0078] In order to generate a secret point without reconstructing the group private key k, the node group 502 uses Secret Share Joining to collaboratively generate s A . Figure 3 Another example of a node group 502 granting credentials to a requesting node 504 is shown. In this illustration, the requesting node 504 sends a credential request to at least t+1 nodes of the node group 502. Each of these nodes provides s A In particular, the secret point s A Each share of Ai determined by node i and sent to the requesting node 504, which then assembles them (i.e., combines them) into the secret point s A In some examples, the share s Ai The combination is made by dividing the shares s Ai Add together to get secret points s A To achieve.

[0079] Reference Figure 4 , which shows an example process 700 for group-based distributed credential generation in flowchart form. Process 700 is performed by a requesting node. First, in operation 702, the requesting node sets index i to 1. Then, the requesting node requests a credential from node i. Node i is a dedicated node in a node group that is used to perform the implementation of the credential granting process described herein. Node i uses the group private key share k i part of the secret point s A The i-th part of . This part can be called s Ai .

[0080] In operation 706, the requesting node receives the portion s from the i-th node. Ai, i.e., receiving a partial credential. In operation 708, the receiving node evaluates whether the index i is t+1. If so, the receiving node has received the t+1 partial credential, but if not, other partial credential is still needed to reconstruct the secret point s A If i is not equal to t+1, then in operation 710 it is increased by 1 and process 700 returns to operation 704 to request another portion of the credential from another node in the node group. If i is equal to t+1, then in operation 712 the requesting node assembles the secret point s A .

[0081] Once a credential is obtained through the joint efforts of nodes in a node group, it is desirable to have a mechanism to check or validate the credential without relying on a central authority or going back to the group for confirmation / authentication. This way, two nodes claiming to have valid credentials from the same node group can validate each other's credentials without incurring the burden of time delays and communication overhead associated with having a node group collaborate to verify and validate issued credentials.

[0082] As an overview, we can think of the group key k as a member of a finite field, that is, k∈Z q The credentials are identified by their identifier id in the requesting node that obtained them. A and the secret point s in the cyclic group G1 A In this example embodiment, the identifier (or "pseudonym") id A is (Alice||role||expirationtime) where || represents the concatenation of two strings, and role is a string or other alphanumeric identifier associated with a node group and / or its function or role. The requesting node may reveal its identifier to anyone, but will A Keep it confidential.

[0083] The other requesting node will send the identifier id B Get (Bob||role||expirationtime) and secret point s B .

[0084] Attention, secret spots A By A =k·H1(id A ) is obtained, and the secret point s B By B =k·H1(id B )get.

[0085] When Alice and Bob wish to establish trusted communication with each other, i.e., when one or both of them wish to verify each other's credentials, the two nodes exchange their respective identifiers / pseudonyms without disclosing their respective secret points.

[0086] Then, node Alice generates the session key K by the following calculation A :

[0087] K A =e(H1(Bob||role||expirationtime),s A )

[0088] Among them, e() is a bilinear map, that is, a pairing operation. Node Bob calculates the session key K by the following calculation B :

[0089] K B =e(s B ,H1(Alice||role||expirationtime))

[0090] The operation H1() is mapped to a point function, which will be further explained below. Due to the nature of the pairing, the two keys mentioned above are the same, namely K A =K B The two nodes can verify the success of the protocol by sending a challenge value and getting a response to the challenge value, that is, the two nodes each hold a credential indicating the same role issued by the same group of nodes. Alternatively, one party can send some content to the other party, and the content will be successfully decrypted if and only if the handshake succeeds.

[0091] The pairing operation in this example depends on s in this case. A and B from the same cyclic group G1. In other cases, s A and B It may come from different cyclic groups G1 and G2, which are related to each other as two Abelian groups, and its value in another Abelian group is:

[0092] e:G1×G2→G T

[0093] Among them, G1, G2, and G T is a cyclic group with the same order.

[0094] There are some common parameters in the generation of credentials, which can be generated by any node in the process and shared with other nodes. Assume that E is in domain F q For an elliptic curve containing n points on the elliptic curve, where q is a power of a prime number that is relatively prime to 2 and 3, the public parameters may include the following:

[0095] params=(p,G1,G2,G T ,g1,g2,e,H1,H2)

[0096] where g1(resp.g2) is a generator of the group G1(resp.G2) of prime order p with the bilinear map e(.,.). G1 is the generator of E(F q ), where r and q are relatively prime. Also, e(g1,g2) generates G T , G T The order of is also p. H1 and H2 are the mappings to point hashes relative to G1 and G2, respectively. As mentioned above, in some embodiments, and in many examples described herein, only G1 may be used, which means that for the secret point s A and B Use the same hash function H1 that maps to points.

[0097] In some elliptic curve cryptography systems, hashing algorithms are used to map passwords or other strings (which are elements of a finite field) to points on a given elliptic curve. These are hashes mapped to points. More precisely, a hash function H1 that maps to a point is a transformation that takes as input a message m and returns a point P∈E(K). More specifically, H1 returns a point P∈E(K)[r], where E(K)[r] is a subgroup of E(K) generated by G1. In this scheme, there exists a set of functions from the base field A one-to-one mapping f to a curve. This allows hashing using f(H(m)), where H is a classical hash function and H(m)∈F q .

[0098] Reference Figure 5 , Figure 5 1 shows the message flow when two nodes A and B establish a trusted communication channel by verifying each other's credentials. In this example implementation, node A sends its identifier id A Provided to Node B. Identifier id A is publicly available and can in some cases be obtained by Node B from another source. Accordingly, Node B is able to use the identifier of Node A, the secret point s held by Node B, and the B , and mapping to the point hash function H1 (the mapping to the point hash function H1 is specified by the node group that issues the credential) to generate the session key K B . Session K B is generated using the pairing operation e(), which is also specified by the node group:

[0099] K B =e(s B ,H1(Alice||role||expirationtime))

[0100] In this example, the identifier of node B is Bis (Alice||role||expirationtime).

[0101] Node B sends its identifier id B Provided to node A, node A can then use node B’s identifier, its secret point s A , and the following same pairing operation and mapping to point function, similarly generate the session key K A :

[0102] K A =e(H1(Bob||role||expirationtime),s A )

[0103] If the secret point is generated by a legitimate collaboration of the group of nodes using the same group secret key k and the respective identifiers of nodes A and B, then the pairing operation should yield K A =K B This can be a test performed in any number of ways. In this example implementation, node A sends a session key K A Node B sends the encrypted challenge. Node B attempts to use its session key K B Decrypt the challenge and send a response to the challenge. The response can be determined by the session key K B Encryption. On this basis, both nodes can be guaranteed to have the same session key. The session key can be used to encrypt communications between the two nodes. In another embodiment, the session key can be used to encrypt communications that lead to the establishment of another key. In yet another embodiment, the communication between the two nodes relies solely on the above process to verify / authenticate each other's credentials, and the communication between the two nodes is either unencrypted or encrypted using the nodes' usual public-private key pair.

[0104] Figure 6 The signal diagram of FIG. 1 shows another example implementation. In this example, node A first generates an arbitrary random number nonce A Node A sets its identifier id A and its random number is sent to node B. Node B generates its own random number nonce B . Then, in this example, node B generates a value C0, which is a hash of the result of the pairing operation and other data (including the random number). In this example, the value C0 can be given by:

[0105] C0=H(e(s B ,H1(id A ))||id A ||id B ||nonce A ||nonce B )

[0106] Where H is a collision-resistant hash function from string to string. In one example, H is SHA-256.

[0107] Node B then replies to Node A, providing Node A with its identifier id B , its random number nonce B and the value C0. Node A then performs a similar calculation to obtain the value C1, which in this example is represented as:

[0108] C1=H(e(H1(id B ),s A )||id A ||id B ||nonce A ||nonce B )

[0109] It can be noted that the only difference in the arguments in the expressions for C1 and C0 is in the pairing operation. Therefore, if the bilinear pairing operation confirms that the credentials of node A and node B are obtained from the same group of nodes, the two values ​​should match. Node A can verify that they match, and if so, send C1 to node B, which also verifies that they match. In one embodiment, the value C0=C1 is used as a session key to encrypt communications between node A and node B. In some embodiments, the nodes rely only on their usual public-private key pairs to encrypt communications, and the operations described above are used for authentication rather than for establishing session keys.

[0110] In some example embodiments, the data or strings that are concatenated and hashed to form the values ​​C0 and C1 may include other data or strings, or may not include some of the above example strings. For example, in one embodiment, the values ​​C0 and C1 may not include the identifier id A and id B Nonetheless, it is understood that hashing and random numbers help protect communications from man-in-the-middle attacks.

[0111] Reference Figure 7 , Figure 7A simplified example of a blockchain node 1000 is shown in block diagram form. The blockchain node 1000 in this example includes a processor 1002, a network interface 1004, and a memory 1006. The blockchain node 1000 may be implemented using any suitable computing hardware that has network connectivity and sufficient processing and storage resources to perform the functions described herein. The blockchain node 1000 may include processor executable instructions to implement the functions described herein. In some cases, the processor executable instructions may be referred to as a blockchain application 1020, but it should be understood that, depending on the hardware and operation, the instructions may be implemented in one or more modules, applications, scripts, or other programming structures. The processor 1002 may include a multi-core processor and / or multiple processors.

[0112] It should be understood that the devices and processes described herein and any modules, routines, processes, threads, applications, or other software components that implement the described methods / processes for configuring a video feature extractor can be implemented using standard computer programming techniques and languages. The application is not limited to a particular processor, computer language, computer programming convention, data structure, or other such implementation details.

[0113] It should be noted that the above embodiments illustrate rather than limit the present invention, and those skilled in the art will be able to design many alternative embodiments without departing from the scope of the present invention as defined by the appended claims. In the claims, any reference numerals in brackets shall not be interpreted as limiting the claims. The words "comprising" and "comprises" and the like do not exclude the presence of other elements and steps as a whole, even though these elements and steps are not listed in any claim or specification. In this specification, "comprises" means "includes or consists of...", and "comprises" means "including or consists of...". The singular reference of an element does not mean to exclude the plural reference of these elements, and vice versa. The present invention can be implemented by means of hardware comprising several different elements, and by means of a suitably programmed computer. In a device claim enumerating several ways, several of these ways can be embodied by the same component of hardware. The fact that certain measures are enumerated in mutually different dependent claims does not indicate that the combination of these measures cannot be used advantageously.

Claims

1. A computer-implemented method for forming a node to obtain credentials from a group of dedicated nodes, each dedicated node having a private key share of a group private key, wherein: The method comprises: sending a request for the credential from the node to a plurality of the dedicated nodes, wherein the node has an identifier, wherein the identifier comprises an identifier string identifying the node and a role string identifying a role of the dedicated node group, wherein the identifier is formed from a concatenation of the identifier string, the role string, and an expiration time of the credential; receiving, from each of the plurality of dedicated nodes, a portion of a secret point generated by the node from the identifier and the node's share of a private key; and generating the secret point by combining received portions of the secret point, wherein the secret point comprises a mapping-to-point hash of the group private key multiplied by the identifier, the credential comprising the identifier and the secret point, wherein obtaining a complete copy of said group private key does not require any of said dedicated nodes and said nodes; And wherein the node is not a member of the dedicated node group.

2. The method according to claim 1, wherein: Sending the request includes sending a separate request to each of a plurality of the dedicated nodes.

3. The method according to claim 1, wherein: The identifier also includes the expiration time of the credential.

4. The method according to any one of claims 1 to 3, wherein: Sending the request includes sending the identifier string, and wherein the receiving includes receiving the identifier.

5. The method according to any one of claims 1 to 4, wherein: Said generating said secret point comprises combining received portions of said secret point.

6. The method according to any one of claims 1 to 5, wherein: The generating the secret point is generating the secret point based on the group private key using secret sharing.

7. The method according to claim 6, wherein: The secret sharing uses Lagrange interpolation and the private key shares of the plurality of dedicated nodes without reconstructing the group private key.

8. A node, comprising: processor; Memory; Network interface; and An application comprising processor-executable instructions for obtaining credentials from a group of dedicated nodes, each of the dedicated nodes having a private key share of a group private key, wherein when the processor-executable instructions are executed, the processor-executable instructions cause the nodes to: Sending a request for the credential to a plurality of the dedicated nodes, wherein the node has an identifier, wherein the identifier includes an identifier string identifying the node and a role string identifying a role of the dedicated node group, wherein the identifier is formed according to a concatenation of the identifier string, the role string, and an expiration time of the credential; receiving, from each of the plurality of dedicated nodes, a portion of a secret point generated by the node from the identifier and the node's share of a private key; and generating the secret point by combining received portions of the secret point, wherein the secret point comprises a mapping-to-point hash of the group private key multiplied by the identifier, the credential comprising the identifier and the secret point, wherein obtaining a complete copy of said group private key does not require any of said dedicated nodes and said nodes; And wherein the node is not a member of the dedicated node group.

9. The node according to claim 8, wherein: When the processor-executable instructions are executed, the processor-executable instructions cause the node to send the request by sending a separate request to each of the plurality of dedicated nodes.

10. The node according to claim 8, wherein: The identifier also includes the expiration time of the credential.

11. The node according to claim 9 or 10, wherein: When the processor executable instructions are executed, the processor executable instructions cause the node to send a request by sending the identifier string and to receive by receiving the identifier.

12. A node according to any one of claims 8 to 11, wherein: i) when the processor executable instructions are executed, the processor executable instructions cause the node to generate the secret point by combining received portions of the secret point; and / or ii) when the processor executable instructions are executed, the processor executable instructions cause the node to generate the secret point by: using secret sharing to generate the secret point based on the group private key; and / or iii) The secret sharing uses Lagrange interpolation and the private key shares of the plurality of dedicated nodes without reconstructing the group private key.

13. A non-volatile processor-readable medium storing processor-executable instructions, wherein when the processor-executable instructions are executed by one or more processors, the one or more processors are caused to perform the operations in the method according to any one of claims 1 to 7.

Images