Credential generation and distribution method for blockchain network

Abstract

To provide methods and devices that manage the secure distribution of credentials from a group of autonomous specialized nodes to a requesting node.SOLUTION: The secure distribution of credentials may use secret share and a group private key that none of the nodes reconstructs or possesses. The credentials include an identifier for the requesting node and a secret point that the node assembles from portions of the secret point provided by each of the specialized nodes, where the secret point is based on the group private key and a map-to-point hash of the requesting node's identifier.SELECTED DRAWING: Figure 7

Description

[Technical Field]

[0001] The present invention relates, in general terms, to a method and system for establishing reliable peer-to-peer communication between nodes in blockchain transactions. [Background technology]

[0002] In this specification, we use the term “blockchain” to include all forms of electronic, computer-based distributed ledgers. These include, but are not limited to, consensus-based blockchain and transaction chain technologies, permissioned and unpermissioned ledgers, shared ledgers, and variations thereof. The most widely known application of blockchain technology is the Bitcoin ledger, although other blockchain implementations have been proposed and developed. While Bitcoin may be referred to herein for 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 are within the scope of the present invention.

[0003] A blockchain is a consensus-based electronic ledger, implemented as a computer-based, decentralized, distributed system composed of blocks of transactions. Each transaction (Tx) is a data structure that encodes the transfer of control of a digital asset between participants in the blockchain system, and includes at least one input and at least one output. Each block contains a hash of the previous block so that the blocks chain together to form a permanent and immutable record of all transactions that have been written to the blockchain since its inception. Transactions contain small programs known as scripts embedded in their inputs and outputs. The scripts specify how and by whom the output of a transaction can be accessed. On the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] A network node receiving a new transaction immediately attempts to push that transaction to other nodes in the network. Before sending the new transaction to other nodes, it is "validated." That is, it is checked against a set of criteria to ensure that the transaction meets the basic requirements for a proper transaction according to the applicable protocol.

[0005] For a transaction to be written to the blockchain, it is incorporated into a block by a node ("miner" or "mining node"). Miners are designed to collect transactions and form them into blocks. Miners then attempt to complete a "proof of work" against the block. Multiple miners compete across the blockchain network to be the first to assemble a block of transactions and complete the associated proof of work on that block. The successful miner adds their approved block to the blockchain, and the block propagates through the network. This allows other nodes holding copies of the blockchain to update their own records. Those nodes that receive the block also "validate" it, ensuring that all transactions within it adhere to the protocol's formal requirements.

[0006] One of the challenges in decentralized peer-to-peer systems is ensuring that nodes can communicate with other nodes in the network on a trustworthy basis. As the network architecture of some implementations evolves, some nodes may undertake more specialized tasks, and other nodes may depend on those specialized nodes as sources of specific data or as nodes that perform specific functions. When a node intends to depend on other nodes for information or as a legitimate source, the node must be able to establish a trustworthy relationship for communication with that node. When nodes have different roles, it is advantageous to have a mechanism for determining and verifying the roles of nodes. Furthermore, if a node is found to be illegitimate or malicious, other nodes must be able to remember this in order to ignore future communications from such nodes. In peer-to-peer systems, the challenge is to solve these problems without compromising the peer-to-peer nature of the system by giving it a central authority.

[0007] Such solutions are currently being devised. [Overview of the project]

[0008] Accordingly, the present invention provides methods and devices as defined in the appended claims.

[0009] This application describes and discloses a method and device for managing the secure distribution of credentials from a group of autonomous, specialized nodes to a requesting node. The secure distribution of credentials may use a group secret key and a secret share that are not reconstructed or processed by any node. The credentials include an identifier of the requesting node and a secret point assembled by the requesting node from portions of secret points supplied by each of the multiple specialized nodes. The secret point is based on the group secret key and a map-to-point hash of the identifier of the requesting node.

[0010] The present invention further describes and discloses a method and device for two nodes to authenticate each other without requiring a group of autonomous, specialized nodes or a centralized certificate manager or authenticator, as if they were certified by such a group. The method may include the first and second nodes deriving the same session key using bilinear pairing operations, each requiring its own identifier and secret point. Provided that the secret point and identifier are obtained from a group using a group secret key, the bilinear pairing operations result 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.

[0011] In an additional or alternative embodiment, the present invention describes a computer-implemented method for a node to obtain credentials from a group of specialized nodes, wherein each of the specialized nodes has a private key share of the group private key. The method comprises sending a request for credentials from a node having an identifier to a group of specialized nodes; receiving from each of the multiple specialized nodes a portion of a secret point generated by that node from the identifier and its private key share; and generating the secret point by combining the received portions of the secret point, the secret point being the group private key multiplied by the map-to-point hash of the identifier, and the credentials being the identifier and the secret point. Neither the node nor the specialized nodes need to obtain a complete copy of the group private key.

[0012] In some implementations, sending the request involves sending a separate request to each of the multiple specialized nodes. The identifier may include an identifier string that identifies the node and a role string that identifies the role of the group of specialized nodes. In some cases, the identifier further includes the expiration time of the credentials, and in some further cases, sending the request involves sending the identifier string, and receiving the request involves receiving the identifier.

[0013] In some implementations, generating the secret point involves combining the received portions of the secret point. In some embodiments, this combining includes addition.

[0014] In some implementations, the secret point is generated using a secret share and based on the group secret key. In some such cases, the secret share uses the secret key shares of the multiple specialized nodes and Lagrangian interpolation without reconstructing the group secret key.

[0015] In an additional or alternative embodiment, the present invention describes a computer-implemented method for a first node to establish trusted communication with a second node, wherein the second node has a second node identifier and a second secret point, the second secret point being a group secret key multiplied by a map-to-point hash of the second node identifier, and the group secret key relating to a group of nodes configured to grant credentials. The method includes obtaining a first secret point from the group of nodes, which is the group secret key multiplied by a map-to-point hash of the 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 with the map-to-point hash of the second node identifier and the first secret point; and verifying that the first session key matches a second session key generated by the second node using the bilinear pairing operation with the second secret point and the map-to-point hash of the first node identifier.

[0016] In some implementations, the bilinear pairing operation for generating the first session key is expressed by the formula: K A =e(H1(id B ),s A ), and K A =e(s B ,H1(id A )) Often characterized by one of them, the bilinear pairing operation for generating the second session key is characterized by the other of the above formulas, e() is the bilinear pairing operation, H1() is the map-to-point hash, id A and id B are each one of the first node identifier and the second node identifier, s A Uand s B are each one of the first secret point and the second secret point.

[0017] In some implementations, obtaining the first secret point includes obtaining each part of the first secret point from each of a plurality of nodes within the group of nodes, and combining each of these parts to form the first secret point without reconstructing the group secret key.

[0018] In some implementations, the verifying includes sending a challenge encrypted by the first session key from the first node to the second node, receiving a response to the challenge, and based on the response, determining that the second node has successfully decrypted the challenge using the second session key.

[0019] In some implementations, the sending further includes sending a first nonce, the receiving further includes receiving a second nonce and a calculated C0 value, the C0 value having a hash of the concatenation of the second session key, the first nonce, and the second nonce. In some such cases, the concatenation further includes the first node identifier and the second node identifier. In some such cases, the generating includes generating a calculated C1 value having a hash of the concatenation of the first session key, the first nonce, and the second nonce, and the verifying includes verifying that the calculated C0 value matches the calculated C1 value. It should be noted that in the translation, there may be some terms that need to be adjusted according to the specific context of the patent to ensure more accurate translation. Here, the translation is mainly based on literal translation for the purpose of preserving the original content.

[0020] In some implementations, the second secret point is obtained by multiplying the group secret key by the map-to-point hash of the second node identifier.

[0021] In some implementations, the first secret point and the second secret point are supplied to the first node and the second node, respectively, by the group of nodes using secret sharing.

[0022] In additional or alternative embodiments, the present application describes a node comprising one or more processors, memory, a network interface, and an application including processor-executable instructions, wherein, when executed, the processor-executable instructions cause the node to perform one or more operations among those described herein.

[0023] In additional or alternative embodiments, the present application describes a non-temporary processor-readable medium that stores processor-executable instructions causing one or more processors to perform one or more operations among those described herein when executed by such processors.

[0024] These and other aspects of the present invention will become apparent from the embodiments described herein and will be explained with reference to those embodiments. Embodiments of the present invention will be described hereby, merely as examples, with reference to the accompanying drawings. [Brief explanation of the drawing]

[0025] [Figure 1] This illustrates an example of a blockchain node network. [Figure 2] This illustrates an example of a blockchain network that includes specialized nodes. [Figure 3] This shows an example of a blockchain network block where specialized nodes form an overlay network. [Figure 4] This diagram illustrates how a network of specialized blockchain nodes interacts with mining nodes. [Figure 5] This diagram illustrates how a blockchain node requests credentials from a specialized group or network of blockchain nodes. [Figure 6] This diagram illustrates an example of a blockchain node obtaining partial credentials from a group of specialized blockchain nodes. [Figure 7] A flowchart illustrating an example of the process for obtaining credentials from a group of blockchain nodes is provided. [Figure 8] This diagram illustrates an example of the process by which two blockchain nodes authenticate each other's credentials obtained from a specialized group of blockchain nodes. [Figure 9] This diagram illustrates another example of the process by which two blockchain nodes authenticate each other's credentials obtained from a specialized group of blockchain nodes. [Figure 10] This is a simplified block diagram of an example blockchain node. [Modes for carrying out the invention]

[0026] In this application, the words "and / or" are intended to cover all possible combinations and subcombinations of the listed elements, including only the listed elements, any subcombination, or all of the elements, without necessarily excluding any additional elements.

[0027] In this application, the phrase "at least one of ... or ..." is intended to cover any one or more of the listed elements, including only the listed elements, any subcombination, or all of the listed elements, without necessarily excluding additional elements and without necessarily requiring all of the elements.

[0028] The examples described below refer to implementations in relation to blockchain networks, but it should be understood that this application is not necessarily limited to implementations on blockchain nodes or blockchain networks.

[0029] First, refer to Figure 1. Figure 1 represents an example of a blockchain-related network in block diagram form. The network may be referred to herein as blockchain network 100. Blockchain network 100 is a peer-to-peer, non-member network in which anyone can join without invitation or consent from other members. Distributed electronic devices running an instance of the blockchain protocol on which blockchain network 100 operates may participate in blockchain network 100. Such distributed electronic devices may be referred to as nodes 102. The blockchain protocol may be, for example, the Bitcoin protocol or other cryptocurrency.

[0030] The electronic devices that execute the blockchain protocol and form nodes 102 of the blockchain network 100 may be of various types, including, for example, computers such as desktop computers, laptop computers, and tablet computers, servers, mobile devices such as smartphones, wearable computers such as smartwatches, or other electronic devices.

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

[0032] Each node 102 holds a global ledger of all transactions on the blockchain, grouped into blocks that each contain the hash of the previous block in the chain. The global ledger is a distributed ledger, and each node 102 may hold a complete or partial copy of the global ledger. Transactions made by node 102 that affect the global ledger are verified by other nodes 102 to ensure the validity of the global ledger. The details of implementing and operating a blockchain network, such as one using the Bitcoin protocol, will be well understood by those skilled in the art.

[0033] 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 transaction's outputs can be accessed. A transaction's output can be the address to which a value is moved as a result of the transaction. That value is then associated with its output address as unused transaction output. Subsequent transactions may then refer to that address as input to use or distribute its value.

[0034] Nodes 102 can have various types or categories depending on their functionality. It has been suggested that there are four basic functions associated with Node 102: wallet, mining, full blockchain maintenance, and network routing. Variations of these functions may exist. Node 102 may have more than one of these functions. For example, a “full node” provides all four functions. A lightweight node, for example, which may be implemented in a digital wallet, may feature only wallet and network routing functions. Rather than holding the full blockchain, a digital wallet may track the history of block headers that serve as an index when querying blocks.

[0035] As described above, mining nodes ("miners") participate in the competition to create the next block in the blockchain. To assemble a block, miners construct a block as a set of transactions from a pool of unconfirmed transactions ("mempool"). Miners then attempt to complete proof-of-work on the block they have assembled. If a miner manages to complete proof-of-work before receiving notification that any other miner has successfully generated a block and completed its proof-of-work, the miner then propagates the block by sending it to peer nodes on the network. Those nodes validate the block and then send it to other nodes on the network. If a miner receives notification that another block has been completed before finishing its proof-of-work, the miner then abandons its activity and begins attempting to construct the next block. Rapid propagation of blocks helps avoid wasted effort for miners and validating nodes.

[0036] In current implementations of blockchains, such as the Bitcoin network, each node receiving a block first validates it before sending it to other nodes. The time it takes to validate a block slows down the propagation of blocks through the network. It should be noted that some implementations of blockchain, including evolutions of existing protocols, may provide block validation by only a subset of nodes rather than every node in the network. However, block validation at most nodes can still be a feature of any blockchain implementation to prevent invalid blocks from propagating through the network.

[0037] Validating a block involves verifying that the block satisfies predetermined criteria set by the applicable blockchain protocol. Examples of criteria applicable to the Bitcoin protocol are defined in the Bitcoin Core client functions CheckBlock and CheckBlockHeader. In addition to verifying that the block itself conforms to the predetermined criteria, each transaction within the block may be evaluated to ensure it conforms to transaction-level criteria. As an example, transaction-level criteria applicable to the Bitcoin protocol can be seen in detail in AcceptToMemoryPool, CheckTransaction, and CheckInputs.

[0038] Generally, transaction-level validation criteria define the characteristics of a transaction that should be considered valid under the applicable blockchain protocol. Similarly, block-level validation criteria define the characteristics of a block that should be considered valid under the applicable blockchain protocol.

[0039] Some evolutions of blockchain may offer more specialized nodes. One example is a node structured as a storage node, equipped with large amounts of high-speed access memory and extensive network communication resources. A storage node may implement a distributed transaction database ("memory pool") for storing unconfirmed transactions. In some implementations, a storage node may implement a distributed UTXO database for unused transaction outputs. These distributed databases may, in some cases, be implemented by distributed hash tables. In other examples, some nodes may be structured as validator nodes designed to focus on the rapid validation and propagation of transactions. Validator nodes and storage nodes can facilitate the increasing volume of transactions associated with large-scale payment processing by forming a high-speed transaction merchant network within the blockchain network 100, designed for distributed, high-capacity storage and rapid validation and propagation of transactions.

[0040] As the number of transactions used in payment processing increases significantly, the amount of transactions stored in each memory pool increases. The average size of a 500-byte transaction (TX) and ~10 4Assuming a transaction rate of TX / s, the memory pool could receive up to 400GB of incoming data daily. All of this data needs to be stored in the memory pool of unconfirmed transactions for varying periods of time. Therefore, in some implementations, the network of nodes may use a shared memory pool implemented with a Distributed Hash Table (DHT) to hold the pool of unconfirmed transactions, rather than each node maintaining a complete memory pool. In such implementations, mining nodes and / or other types of nodes do not necessarily have to maintain a complete memory pool locally to alleviate the burden of holding and updating a very large pool of unconfirmed transactions. Instead, mining nodes and / or other types of specialized nodes may rely on a network of storage and / or validator nodes to manage the maintenance of the memory pool. In some of the following examples, the term “specialized node” may be used to refer to nodes that have a specific role in the blockchain network, such as validator nodes, storage nodes, etc.

[0041] Referring now to Figure 2, which shows one embodiment of a blockchain network 200 of nodes, the blockchain network 200 includes a number of specialized nodes 202 and a number of mining nodes 204. In this example, the specialized nodes 202 are physically and logically distributed across the network 200. The blockchain network 200 may include many other types of nodes, including full nodes, Simplified Payment Verification (SPV) nodes (e.g., wallets), and other specialized nodes having focused roles.

[0042] Figure 3 shows another embodiment of the blockchain network 300. Figure 3 shows that specialized nodes 202 form a (logical) overlay network 302 within the blockchain network 300. The overlay network 302 may be configured to ensure high-speed communication between the specialized nodes 202 within the overlay network 302 in order to ensure rapid access to and retrieval of the shared memory pool.

[0043] In this example, the specialized node 202 may be implemented to facilitate high-speed transaction validation and propagation as part of a structure to facilitate large-scale payment processing across blockchain networks 200, 300. In this regard, the specialized node 202 may be a validator node focused on transaction validation and propagation, while the mining node 204 focuses on block mining and is exempt from the need for memory pool storage or transaction validation. In this example, the specialized nodes 202 may have direct access to the memory pool in that they are involved in storage based on their DHT, or they may have access to the memory pool via one or more storage nodes.

[0044] Such a reconfiguration of the roles of blockchain networks 200, 300 and individual nodes to facilitate high-speed transaction processing may present challenges in ensuring blockchain growth and the non-malicious involvement of various nodes. Maintaining the decentralized nature of blockchain networks 200, 300 by avoiding control by one or more central authorities is of paramount importance. For networks 200, 200 to function properly, specialized nodes 202 and other specialized nodes should interact to ensure 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 achieve this objective, the interaction between specialized nodes 202 and mining nodes 204 may use multiple transactions to encourage coordination in pursuing high-speed block mining and propagation.

[0045] Referring now to Figure 4, Figure 4 schematically shows an overlay network 302 that includes multiple mining nodes 402 (indicated individually as 402a, 402b, and 402c) and multiple specialized nodes 202. In this example, the specialized nodes 202 implement a memory pool, for example, as a shared memory pool using DHT, to hold a large database of unconfirmed transactions distributed among the specialized nodes 202. Note that this is one embodiment, and in some other implementations, each of the specialized nodes 202 may hold a complete copy of the memory pool.

[0046] Mining node 204 may include individual single miners, as indicated by reference numbers 402b and 402c, or it may include a mining pool that includes multiple miners, as indicated by reference number 402a.

[0047] In this example, mining node 402 does not possess a complete copy of the memory pool and relies on specialized nodes 202 to provide them with the materials necessary to mine new blocks. Specifically, one of the specialized nodes 202 can invite mining node 402 to participate in mining a new block using a set of unconfirmed transactions that the specialized node 202 has access to in the memory pool. Mining node 402 can choose to agree to participate in the mining activity by receiving a new set of unconfirmed transactions. In exchange for receiving a deposit from each mining node 402, the specialized node 202 supplies each of them with a set of transactions (or a hash of a set of transactions). If one of the participating mining nodes 402 succeeds in creating a new block from the set of transactions, then that mining node 402 receives a refund of its deposit from the specialized node 202, in addition to the usual fee for mining the block. The remaining unsuccessful mining nodes 402 will have their deposits to specialized node 202 forfeited. If none of the participating mining nodes 402 succeed in creating the next block, then specialized node 202 will refund the deposits of those mining nodes 402, minus, firstly, the validation fees collected by specialized node 202 as compensation for its efforts in validating transactions and supplying sets of validated transactions to the mining nodes.

[0048] Furthermore, mining node 402 would want to be able to authenticate that specialized node 202 is a legitimate member of the pool of specialized nodes. Similarly, specialized nodes 202 themselves may need to authenticate the identity of one of the specialized nodes 202 and the authority of that node to participate in the collaboration. In many network architectures, this functionality is achieved by imposing a central authentication service, such as a certificate authority, which centrally manages certificates and authenticates participating nodes. However, such an architecture is undesirable in a decentralized peer-to-peer architecture where central control or authority should be avoided.

[0049] The same problem could arise in other parts of the blockchain network as its architecture evolves to accommodate nodes with specialized roles, whether for validation, storage, mining, or other functions. These nodes would function as members of a group with a specific role, and other members of that group with that role would want to be able to identify and authenticate membership within the group. Similarly, nodes that are not members of a group but need to interact with and "trust" specialized nodes within the group would also want to be able to authenticate the membership of those specialized nodes within the group. It is desirable to enable nodes to authenticate their identity and membership without imposing a centralized certificate authority on a decentralized blockchain network.

[0050] In one embodiment, the present invention provides a method and device for authenticating a node by relying on a distributed private key share among a group of nodes that are members of a specialized node group. Accordingly, credentials are generated and supplied to the requesting node through the cooperation of the specialized nodes in the group, so that no single specialized node supplies a valid credential to the requesting node on its own.

[0051] In another embodiment, the present invention provides a method for establishing a trusted communication channel between two nodes by ensuring that each node possesses credentials authorized by nodes in the same group. Both nodes involved in the trusted communication channel may, but are not necessarily, be members of the group that authorized the credentials. In one example, one node is a member of a specialized group of nodes, and the other node is not. Verifying the validity of the credentials of the two nodes may be based on each node generating a key using a bilinear pairing operation and ensuring that the keys match. The bilinear pairing operation of one node may include, as arguments, a map-to-point hash of the identifier of the other node and a secret point that has been collaboratively generated by the group of nodes and supplied to the one node.

[0052] Referring now to Figure 5, which schematically illustrates group 502 of specialized nodes. Requesting node 504 wants to obtain credentials from group 502 of specialized nodes so that it can prove its identity as one of the specialized nodes or as a node communicating with one of the specialized nodes. Requesting node 504 may or may not be part of group 502 of specialized nodes.

[0053] Requesting node 504 sends credential request 506 to node group 502. Request 506 is associated with the identifier of requesting node 504. In some implementations, the identifier may be generated by requesting node 504 and sent with request 506. For example, requesting node 504 may generate its identifier "Alice" and send its id=Alice to node group 502. In some implementations, the identifier may be assigned by node group 502, or more specifically, by one node within node group 502, and sent to requesting node 504. In some implementations, requesting node 504 provides node group 502 with its "name" or identifier string, for example, "Alice". The identifier string may be some alphanumeric string or other unique identifier. Node group 502 may concatenate additional information to the identifier string in order to generate the identifier of requesting node 504. For example, node group 502 may concatenate an identifier string with the name or identifier of node group 502. In some embodiments, the name is the "role" or function of node group 502, such as "validator". In some embodiments, node group 502 may concatenate the identifier with the credential expiration time so that any other node evaluating the credentials of requesting node 504 can determine from the identifier whether the credentials are still valid. In one embodiment described below, the identifier of requesting node 504 is formed from a concatenation of an identifier string (e.g., Alice), a role string or their functional role that identifies node group 502, and the credential expiration time. Other possible embodiments of the identifier will be understood by those skilled in the art.

[0054] Each node in node group 502 has a share of the private key k. iThis includes secret sharing, which is used in threshold cryptography where secret k is divided among n players such that at least t+1 participants must cooperate to reconstruct secret k. Knowledge of any t parts of secret k leaves secret k undetermined.

[0055] The secret sharing scheme is based on polynomial interpolation, and the secret is considered to be an element of a finite field F. The scheme involves a dealer (a version without a dealer also exists) and n participants U1,...,U n The protocol has a set of and . In the protocol, an arbitrary random secret is stored as f(0) in a t-degree polynomial f(x), and only node i has its share of f(x i ) can be calculated. When t+1 of the n nodes cooperate, they can be calculated using Lagrangian polynomial interpolation as f(x1), f(x2), ..., f(x n ) corresponding to their shares k1, k2, ..., k n By this, any point on f(x) can be reconstructed. Lagrangian polynomial interpolation allows a function f(x) of degree t to have t+1 points p={(x1,f(x1)),(x2,f(x2)),···,(x t+1 ,f(x t+1 It provides that it can be reconstructed by:

number

number

[0056] Regarding the implementation of dealerless shares distribution: 1. Each node i is known to all x i Each x can be assigned. i It must be unique. 2. Each node i is a random polynomial f of degree t. i Generate (x). 3. Each node i can express a polynomial f to any other node. i (x j Each of those points on modn is sent secretly (encrypted using the recipient's public key). 4. Each node i is a share of the polynomial f(x) mod n, k i =f(x i )modn, all of those received f1(x1), f2(x2), ..., f p (x i ), all mod n (where n is the base field) [Outside 1] This is the characteristic of TIFF0007838906000003.tif7170.) Add them together.

[0057] Returning to the example in Figure 5, the node in node group 502 is the secret point for requesting node 504, as indicated by reference number 508. A Collaborate to generate secret points. A It is located within the circulating group G1, and its significance becomes clear from the following explanation regarding the handshake and pairing. The secret point is: s A =k·H1(id A ) It is related to the identifier. Here, id A This is the identifier of the requesting node 504. The credentials are, in some implementations, (id A ,s A It can be considered that H1 is a map-to-point hash, as will be explained in more detail below.

[0058] To generate a secret point without reconstructing the group secret key k, the group of nodes 502 uses the form of Secret Share Joining. A They cooperate in generating . Figure 6 shows another example in which a group of nodes 502 grants credentials to the requesting node 504. In this example, the requesting node 504 sends the credential request to at least t+1 nodes in the group of nodes. Each of those nodes grants s to the requesting node 504. A It supplies a portion of the secret points. A Each share Ai This is determined by node i and sent to requesting node 504, and then requesting node 504 sends them to secret points s A Assemble them (i.e., combine them). In some examples, share s Ai is secret points s A They are combined by adding them together to obtain the desired result.

[0059] Referring now to Figure 7, which shows an example of a process 700 for distributed generation based on a group of credentials in flowchart form. Process 700 is executed by the requesting node. It begins with the requesting node setting index i to 1 in operation 702. The requesting node then requests credentials from node i. Node i is a specialized node within a group of nodes configured to perform the implementation of the credential authorization procedure described herein. Node i has group secret key share k i Using the part, secret point s A Determine the i-th part. That part is s Ai It can be referred to as such.

[0060] In operation 706, the requesting node receives part s from the i-th node. AiIt receives a partial credential. In operation 708, the requesting node determines whether index i is t+1. If so, the requesting node has received t+1 partial credentials. If not, the requesting node receives a secret point s A Further partial credentials are still needed to reconstruct it. If i is not yet equal to t+1, then in operation 710, i is incremented by 1, and process 700 returns to operation 704 to request another partial credential from the other nodes in the group of nodes. If i is equal to t+1, then in operation 712, the requesting node requests secret point s A Assemble it.

[0061] When credentials are obtained through the collaborative efforts of nodes within a group of nodes, it is advantageous to have a mechanism to check or validate the credentials without relying on a central authority or returning to the group for validation / authentication. In this way, two nodes claiming to have valid credentials from nodes in the same group can validate each other's credentials without the burden of time delays and communication overhead associated with having a group of nodes that collaboratively verify and validate issued credentials.

[0062] In general terms, a group secret key k is a member of a finite field, i.e., [Outside 2] It is thought to be TIFF0007838906000004.tif7170. The requesting node to obtain the credentials will use its own identifier id. A and secret points within patrol group G1 A It has in the form of. In this example embodiment, the identifier (or "pseudonym") id Ais (Alice||role||expiration time), where || represents the concatenation of two strings, and role is a string or other alphanumeric identifier related to the group's node and / or its function or role. The requesting node can expose its identifier to anyone, but s A Keep it a secret.

[0063] Other requesting nodes use the identifier id as (Bob||role||elapsed time). B And, secret points B To obtain and

[0064] Secret Points A is, s A =k·H1(id A ) is given by, secret points s B is, s B =k·H1(id B Note that this is given by ).

[0065] When Alice and Bob want to establish trustworthy communication with each other, that is, when one or both of them want to verify the other's credentials, the two nodes exchange their identifiers / pseudonyms without disclosing their secret points.

[0066] Node Alice then: K A =e(H1(Bob||role||elapsed time),s A ) By calculating the session key K, A This generates e(), where e() is a bilinear map, i.e., a pairing operation. The node Bob is: K B =e(s B ,H1(Alice||role||expiration time)) By calculating the session key K, BWe seek.

[0067] The operation H1() is a map-to-point function, as further described below. Due to the pairing properties, the two keys are the same, i.e., K A =K B By sending a task value and receiving a response, the two nodes can verify that the protocol was successful, that is, that each node holds credentials issued by the same group of nodes representing the same role. Alternatively, one party may send to the other some content that can only be successfully decrypted if the handshake is successful.

[0068] In this example, the pairing operation is performed from the same cyclic group G1. A and s B It depends on the other two: e:G1×G2→G T It may be from two different cyclic groups G1 and G2 that are related as two abelian groups that take values ​​within other abelian groups. Here, G1, G2 and G T These are cyclic groups of the same order.

[0069] In the generation of public credentials, certain parameters exist. These are generated by one node in the process and shared with other nodes. When q is a power of a prime number relatively prime to 2 and 3, E is a field. [Outside 3] Starting from the assumption that TIFF0007838906000005.tif7170 is an elliptic curve containing n points, the public parameters are as follows: params=(p, G1, G2, G T ,g1,g2,e,H1,H2) This may include the following: Here, g1 (or g2) is a generator of the group G1 (or G2) of prime numbers of order p having a bilinear map e(.,.). G1 is a group of prime numbers of order r such that r and q are relatively prime. [Outside 4] It is a cyclic subgroup of TIFF0007838906000006.tif7170. And e(g1,g2) is a G which also has order p. T This generates H1 and H2, which are map-to-point hashes for G1 and G2, respectively. As mentioned above, in some implementations, and in many of the examples described herein, only G1 may be used. That is, the same map-to-point hash H1 is used for both secret points s A and s B It is used for that purpose.

[0070] In some elliptic curve cryptography schemes, a hash algorithm is used to map a password or other string, which is an element of a finite field, to a point on a given elliptic curve. These are map-to-point hashes. More precisely, a map-to-point hash H1 is a transformation that takes a message m as input 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, the base field [Outside 5] A one-to-one mapping f exists from TIFF0007838906000007.tif7170 to a curve. This makes it possible to hash using f(H(m)), where H is a classical hash function. [Outside 6] TIFF0007838906000008.tif7170

[0071] Referring now to Figure 8, Figure 8 shows the message flow between two nodes A and B in establishing a reliable communication channel by validating each other's credentials. In this embodiment, node A sends its own identifier id ASupply it to Node B. The identifier id A is publicly available and, in some cases, may be obtained by Node B from other sources. From this, Node B uses the identifier of Node A and the secret point s B held by Node B, and the map-to-point hash H1 defined by the group of nodes that issued the credentials, to generate the session key K B . The session key K B is also generated using the pairing operation e() defined by the group of nodes: K B =e(s B , H1(Alice||role||expiration time)) Here, in this example, the identifier id of Node B B is (Alice||role||expiration time).

[0072] Node B supplies its own id B to Node A, and Node A then, similarly, uses the identifier of Node B, its own secret point s A , and the same pairing operation and map-to-point hash, to generate the session key K A : K A =e(H1(Bob||role||elapsed time), s A )

[0073] When the secret points are legitimately cooperatively generated by the group of nodes using the identifiers of each of Node A and Node B and the same group secret key, the pairing operation should result in K A =K B . This can be tested in various ways. In this embodiment, Node A sends a challenge encrypted with the session key K A to Node B. Node B uses its own session key K BAttempt to decrypt the task using the session key K and send a response to the task. B It can be encrypted by this. Based on this, both nodes can be confident that they have the same session key. That session key can be used to encrypt communication between the two nodes. In other implementations, the session key may be used to encrypt communication resulting in the setup of other keys. In yet another implementation, communication between the two nodes simply relies on the above procedure to validate / authenticate each other's credentials, and communication between the two nodes is either unencrypted or encrypted using the nodes' usual public-private key pair.

[0074] Other embodiments are illustrated by the signal diagram in Figure 9. In this example, node A is a random nonce A It starts by generating the identifier id. Node A is A And send its nonce to node B. Node B then sends its own nonce B Node B then generates the value C0, which in this example is the hash of the result of the pairing operation and other data including the nonce. In this example, the value C0 is: C0=H(e(s B ,H1(id A ))||id A ||id B ||nonce A ||nonce B ) It can be given by , where H is a collision-resistant hash function for each string. In one example, H is SHA-256.

[0075] Next, node B has its identifier id B And that nonce B Then, it supplies value C0 and sends a reply to node A. Next, node A performs a similar calculation to obtain value C1. In this example, C1 is: C1=H(e(H1(id B ),s A )||id A ||id B ||nonce A ||nonce B ) It is expressed as follows.

[0076] The only difference between the arguments in the formula C0 and C1 lies in the pairing operation. Thus, the two values ​​should match if the bilinear pairing operation verifies that the credentials of node A and node B were obtained from the same group of nodes. Node A can verify that they match, and if so, sends C1 to node B. Node B also verifies that they match. In one implementation, the values ​​C0=C1 are then used as a session key to encrypt communication between node A and node B. In some implementations, nodes simply rely on their usual public-private key pairs to encrypt communication, and the above operation is for authentication, not to establish a session key.

[0077] In some embodiments, the data or strings concatenated and hashed to form the values ​​C0 and C1 may include other data or strings, or exclude some of the strings from the previous example. For example, in one embodiment, the values ​​C0 and C1 are identifiers id A and id B The concatenation of hashes and nonces is not required. It should be noted that hashes and nonces are understood to help protect communications from man-in-the-middle attacks.

[0078] Referring now to Figure 10, which shows a simplified example of a blockchain node 1000 in block diagram form, the blockchain node 1000 in this example includes a processor 1002, a network interface 1004, and memory 1006. The blockchain node 1000 may be implemented using any suitable computing hardware having network connectivity and sufficient processing and memory resources to perform the functions described herein. The blockchain node 1000 may include processor-executable instructions for implementing the functions described herein. In some cases, the processor-executable instructions may be called a blockchain application 1020. It will be understood that the instructions may be implemented in one or more modules, applications, scripts, or other programming structures, depending on the hardware and operating system. The processor 1002 may include a multi-core processor and / or multiple processors.

[0079] It will be understood that any module, routine, process, thread, application, or other software component implementing the devices and processes described herein, as well as the methods / processes described for constituting the image feature extraction unit, can be implemented using standard computer programming techniques and languages. This application is not limited to any particular processor, computer language, computer programming specification, data structure, or other such implementation details.

[0080] It should be noted that the embodiments described above are illustrative, not limiting, of the invention, and that those skilled in the art can design many alternative embodiments without exceeding the scope of application of the invention as defined by the appended claims. In the claims, no reference numerals in parentheses should be construed as limiting the claims. The words “comprising” and “comprises,” etc., do not exclude the existence of elements or steps other than those listed in any claim or the entirety of the specification. In this specification, “comprises” means “includes or consists of,” and “comprising” means “including or consisting of.” A single reference to an element does not exclude multiple references to such element, and vice versa. The invention may be carried out using hardware having several individual elements and a appropriately programmed computer. In apparatus claims listing several means, some of those means may be embodied by the same item of hardware. The mere fact that certain means are mentioned in different claims does not indicate that a combination of those means cannot be used advantageously.

Claims

1. A computer-based method for a second node to establish trusted communication with a first node, wherein the second node has a second node identifier and a second secret point, the second secret point is obtained by multiplying a group secret key by a mash-to-point hash of the second node identifier, and the group secret key relates to a group of nodes configured to grant credentials, in the method, Obtaining a first secret point from the group of nodes, which is obtained by multiplying the group secret key by the map-to-point hash of the first node identifier, Obtaining the first node identifier, A second node session key is generated using a bilinear pairing operation with the map-to-point hash of the second secret point and the first node identifier, The first node is supplied with the second node identifier so that the first node can generate a first node session key, The second node verifies that the first node session key generated by the first node matches the second node session key using a bilinear pairing operation with the map-to-point hash of the second node identifier and the first secret point. It has, A method for obtaining the first secret point, comprising obtaining each portion of the first secret point from each of the multiple nodes in the group of nodes, and combining the respective portions to form the first secret point without reconstructing the group secret key.

2. The aforementioned first node identifier is obtained from a source other than the aforementioned first node. The method according to claim 1.

3. The map-to-point hash is defined by the group of nodes that issued the credentials. The method according to claim 1 or 2.

4. The second node session key is given by the formula: K Ｂ = e(s) Ｂ , H １ (Alice||role||Expiration time)) Generated using The method according to any one of claims 1 to 3.

5. The verification described above involves receiving a task encrypted with the first node session key from the first node, sending a response to the task, and enabling the first node to determine, based on the response, that the second node has successfully decrypted the task using the second node session key. The method according to any one of claims 1 to 4.

6. Obtaining the first node identifier further comprises obtaining the first nonce, and supplying the second node identifier comprises the second nonce and the calculated C ０ The C further comprises supplying a value. ０ The value has a hash of the concatenation of the second node session key, the first nonce, and the second nonce. The method according to any one of claims 1 to 5.

7. The concatenation further includes the first node identifier and the second node identifier, The method according to claim 6.

8. Generating the first node session key involves calculating a C having a hash of the concatenation of the first node session key, the first nonce, and the second nonce. １ The process involves generating a value, and verifying the calculated C ０ The value is the calculated C. １ It has the ability to verify that the value matches, The method according to claim 6 or 7.

9. The first secret point and the second secret point are each supplied to the first and second nodes by the group of nodes using secret sharing, the second secret point is obtained from the group of nodes, each node in the group of nodes supplies a portion of the second secret point, and each portion is combined to form the second secret point without reconstructing the group secret key. The method according to any one of claims 1 to 8.

10. The first node session key or the second node session key is used to encrypt communication between the first node and the second node. The method according to any one of claims 1 to 9.

11. A computer-based method for a first node to establish trusted communication with a second node, wherein the second node has a second node identifier and a second secret point, the second secret point being a group secret key multiplied by a map-to-point hash of the second node identifier, and the group secret key relating to a group of nodes configured to grant credentials, in the method, Obtaining a first secret point from the group of nodes, which is obtained by multiplying the group secret key by the map-to-point hash of the first node identifier, Sending the first node identifier to the second node, Receiving the aforementioned second node identifier, A first session key is generated using a bilinear pairing operation with the map-to-point hash of the second node identifier and the first secret point. The first node verifies that the first session key matches the second session key generated by the second node using the bilinear pairing operation involving the second secret point and the map-to-point hash of the first node identifier. Yes, A method for obtaining the first secret point, comprising obtaining each portion of the first secret point from each of the multiple nodes in the group of nodes, and combining the respective portions to form the first secret point without reconstructing the group secret key.

12. The bilinear pairing operation for generating the first session key is given by the formula: K Ａ = e(H １ (id Ｂ ), s Ａ ), and K Ａ =e(s Ｂ ,H １ (id Ａ )) The bilinear pairing operation for generating the second session key has one of the formulas, and the other of the formulas e() is the bilinear pairing operation, H １ ( ) is the aforementioned map-to-point hash, id Ａ and id Ｂ This is one of the first node identifier and one of the second node identifiers, s Ａ and s Ｂ This is one of the first secret point and one of the second secret point. The method according to claim 11.

13. A non-temporary processor-readable medium storing processor-executable instructions that, when executed by one or more processors, cause one or more processors to perform an operation according to any one of claims 1 to 10.

14. A non-temporary processor-readable medium storing processor-executable instructions that cause one or more processors to perform an operation according to claim 11 or 12 when executed by one or more processors.

Images