Key regeneration in a blockchain network via OPRF

Abstract

Example operations may include one or more of encrypting a private key with an encryption key, generating a plurality of keys based on the encryption key and converting the plurality of keys into a plurality of key shares based on a secret input value, storing the encrypted private key on a blockchain, and distributing the plurality of key shares to a plurality of blockchain peers of the blockchain, where distributing comprises sending a different key share from among the plurality of key shares to each blockchain peer in the plurality of blockchain peers.

Description

[Background technology]

[0001] A centralized platform stores and maintains data in a single location. This location is often a central computer, e.g., a cloud computing environment, a web server, a mainframe computer, etc. Information stored on a centralized platform is typically accessible from multiple different points. Multiple users or client workstations can work simultaneously on the centralized platform, e.g., based on a client / server configuration. Due to its single location, a centralized platform is easier to manage, maintain, and control, especially for security purposes. Within a centralized platform, data redundancy is minimized, since the single storage location of all data also implies that a given set of data has only one primary record. Summary of the Invention

[0002] One exemplary embodiment includes encrypting a private key with an encryption key, generating multiple keys based on the encryption key, and synthesizing the multiple keys based on a secret input value. Key sharing portion and storing the encrypted private key on the blockchain; and Key sharing portion and a processor configured to distribute a plurality of network interfaces. Key sharing portion Different from among Key sharing portion to each blockchain peer among the multiple blockchain peers.

[0003] Another exemplary embodiment includes steps of encrypting a private key with an encryption key, generating multiple keys based on the encryption key, and encoding the multiple keys to multiple keys based on a secret input value. Key sharing portionThe step of converting it, the step of storing the encrypted private key on the blockchain, and a plurality of Key sharing portion Providing a method comprising one or more of the steps of distributing, wherein the distributing step comprises distributing a plurality of Key sharing portion from different Key sharing portion to each blockchain peer among the plurality of blockchain peers.

[0004] A further exemplary embodiment, when read by a processor, causes the processor to encrypt a private key using a cryptographic key, generate a plurality of keys based on the cryptographic key, and based on a secret input value, convert the plurality of keys into a plurality of Key sharing portion Providing a non-transitory computer-readable medium comprising instructions for performing one or more of encrypting the encrypted private key, storing it on the blockchain, and distributing a plurality of Key sharing portion to each blockchain peer among the plurality of blockchain peers. Key sharing portion from different Key sharing portion to each blockchain peer among the plurality of blockchain peers.

Brief Description of the Drawings

[0005]

Figure 1A

[0006]

Figure 1B

[0007]

Figure 1C

[0008]

Figure 1D

[0009]

Figure 2A

[0010]

Figure 2B

[0011]

Figure 3A

[0012]

Figure 3B

[0013]

Figure 3C

[0014]

Figure 4A

[0015]

Figure 4B

[0016]

Figure 5

[0017]

Figure 6A

[0018]

Figure 6B

[0019]

Figure 6C

[0020]

Figure 6D

[0021]

Figure 7A

[0022]

Figure 7B

[0023]

Figure 7C

[0024]

Figure 7D

[0025]

Figure 8A

[0026]

Figure 8B

[0027]

Figure 9

Best Mode for Carrying Out the Invention

[0028] It will be readily understood that the components as generally described and illustrated herein can be arranged and designed in a wide variety of different configurations. Therefore, the following detailed description of at least one embodiment of a method, apparatus, non-transitory computer-readable medium, and system, as represented in the accompanying drawings, is not intended to limit the scope of the present application as claimed, but is merely representative of selected embodiments.

[0029] The features, structures, or characteristics as described throughout this specification can be combined or removed in any suitable manner in one or more embodiments. For example, the use of phrases such as "exemplary embodiments", "some embodiments", or other similar language throughout this specification indicates that the particular features, structures, or characteristics described in connection with the embodiments can be included in at least one embodiment. Therefore, the appearance of phrases such as "exemplary embodiments", "in some embodiments", "in other embodiments", or other similar language throughout this specification does not necessarily refer to all being in the same group of embodiments, and the described features, structures, or characteristics can be combined or removed in any suitable manner in one or more embodiments. Further, in the drawings, any connection between elements can allow for one-way communication and / or two-way communication, whether the indicated connection is an arrow in one direction or both directions. Also, any device shown in the drawings can be a different device. For example, if a mobile device is shown as transmitting information, information can also be transmitted using a wired device.

[0030] In addition, although the term "message" may be used in the description of the embodiments, this application can be applied to many types of networks and data. Further, although specific types of connections, messages, and signaling may be shown in the exemplary embodiments, this application is not limited to specific types of connections, messages, and signaling.

[0031] The exemplary embodiments provide a method, system, component, non-transitory computer-readable medium, device, and / or network that target a key recovery process based on an Oblivious Pseudorandom Function (OPRF).

[0032] In one embodiment, the present application utilizes a decentralized database (such as a blockchain), which is a distributed storage system comprising a plurality of nodes communicating with each other. The decentralized database includes an additional dedicated immutable data structure similar to a distributed ledger capable of maintaining records among parties who do not trust each other. The parties who do not trust each other are referred to herein as peers or peer nodes. Each peer maintains a copy of the database records, and no single peer can modify the database records without reaching a consensus among the distributed peers. For example, the peers may execute a consensus protocol to validate blockchain storage transactions, group the storage transactions into multiple blocks, and construct a hash chain across the blocks. This process forms a ledger by ordering the storage transactions as necessary for consistency. In various embodiments, a permissioned and / or permissionless blockchain can be used. In a public or permissionless blockchain, anyone can participate without a specific identity. The public blockchain includes native cryptocurrencies and can use consensus based on various protocols such as proof of work (PoW). On the other hand, a permissioned blockchain database provides secure interactions among groups of entities that share a common purpose, such as businesses exchanging funds, goods, information, etc., but do not fully trust each other.

[0033] This application can utilize a blockchain that is adapted to a decentralized storage scheme and operates any programmable logic, referred to as a "smart contract" or "chain code". In some cases, there may be a chain code specialized for administrative functions and parameters, referred to as a system chain code. This application can further utilize a smart contract, which is a trusted distributed application that takes advantage of the blockchain's immutability property and the underlying agreement between nodes, referred to as an approval or endorsement policy. Blockchain transactions associated with this application can be "endorsed" before being committed to the blockchain, while unendorsed transactions are ignored. The endorsement policy enables the chain code to specify endorsers for a transaction in the form of a set of peer nodes that are required for endorsement. When a client sends a transaction to the peers specified in the endorsement policy, the transaction is executed and the transaction is validated. After validation, the transaction enters an ordering phase, where a consensus protocol is used to generate an ordered sequence of endorsed transactions grouped into multiple blocks.

[0034] This application can utilize nodes, which are communication entities in a blockchain system. A "node" may execute a logical function in the sense that multiple different types of nodes can operate on the same physical server. Nodes are grouped into trust domains and associated with logical entities that control them in various ways. Nodes may include different types such as client or submitting client nodes that submit transaction calls to approvers (e.g., peers) and broadcast transaction proposals to an ordering service (e.g., an ordering node). Another type of node is a peer node that can receive transactions submitted by a client, commit the transactions, and maintain the state and a copy of the ledger of blockchain transactions. A peer can also have the role of an approver, but this is not a requirement. An ordering service node or orderer is a node that executes a communication service for all nodes, commits transactions, and implements delivery guarantees such as broadcasting to each of the peer nodes in the system when modifying the world state of the blockchain, which is another name for an initial blockchain transaction that usually includes control and setup information.

[0035] This application can utilize a ledger, which is a sequenced and tamper-resistant record of all state transitions in a blockchain. State transitions can result from chain code calls (i.e., transactions) submitted by participating parties (e.g., client nodes, ordering nodes, approver nodes, peer nodes, etc.). Each participating party (such as a peer node) can maintain a copy of the ledger. As a result of a transaction, a set of asset key-value pairs can be committed to the ledger as one or more operands such as creation, update, deletion, etc. The ledger includes a blockchain (also referred to as a chain) that is used to store immutable sequenced records in multiple blocks. The ledger also includes a state database that maintains the current state of the blockchain.

[0036] This application can utilize a chain that is a transaction log structured as hash-linked blocks, where each block contains a sequence of N transactions, where N is equal to or greater than 1. The block header includes the hash of the block's transactions and the hash of the header of the previous block. In this way, all the transactions on the ledger can be sequenced and cryptographically linked together. Therefore, it is not possible to tamper with the ledger data without breaking the hash link. The hash of the most recently added blockchain block represents all the transactions on the chain that occurred before it, making it possible to ensure that all peer nodes are consistent and in a trusted state. The chain may be stored on a peer node file system (i.e., local, attached storage, cloud, etc.), and the append-only nature of the blockchain workload is efficiently supported.

[0037] The current state of the immutable ledger represents the latest values for all keys included in the chain transaction log. Since the current state represents the latest key values known to the channel, this is sometimes referred to as the world state. Chain code calls execute transactions against the data in the current state of the ledger. To make these chain code interactions efficient, the latest values of the keys may be stored in a state database. The state database may simply be an indexed view into the chain's transaction log and, therefore, can be regenerated from the chain at any point in time. The state database may be automatically restored (or generated if necessary) when the peer node starts up and before transactions are accepted.

[0038] Asymmetric key pairs (private and public digital key pairs) are often used to secure information. For example, a blockchain client may use a private key to encrypt / decrypt data that is to be submitted to other participants in the blockchain. In this example, the private key is only known to the client. On the other hand, the corresponding public key of the private key is shared among other participants on the blockchain and may be used to decrypt / encrypt data. However, if the private key is lost (e.g., the storage device containing the private key is destroyed, lost, malfunctioning, etc.), the data encrypted using such a private key is also lost. Therefore, a client may store the private key using a third party (e.g., a remote server, etc.) in case the private key is permanently lost.

[0039] For example, to obtain the private key from a server, the client may provide a password for login. Password-based authentication enables the client (having knowledge of the password) to obtain the private key. On the other hand, an entity without the password cannot obtain the private key. However, password-based authentication is vulnerable to malicious attacks. For example, when the client sends the private key to a remote server, the client may set up an authentication process with the server that includes the password. The server may store the salted and hashed form of the password. When the client wishes to obtain the private key, this involves providing the corresponding password during the login process or the like. In this case, if the server is malicious, the server can discover the password through a brute-force dictionary attack on the password or by trivially intercepting the login.

[0040] The exemplary embodiments provide a new mechanism that can perform password-based authentication without leaving the private key vulnerable to brute-force attacks. In particular, the private key can be encrypted using a cryptographic key. Here, the encrypted private key can be provided to one or more blockchain peers and further stored on the blockchain. Additionally, the private key may be converted into a plurality of key values (e.g., random values), and an Oblivious Pseudorandom Function (OPRF) may be used to convert the plurality of keys into a plurality of Key sharing portion which may be used to convert the plurality of keys into a plurality of Key sharing portion and may be generated based on the password. Key sharing portion may be distributed among a plurality of blockchain peers.

[0041] If the client wishes to restore the private key, the client requests Key sharing portion from a plurality of blockchain peers. Here, the client may require a predetermined number of Key sharing portion to restore the cryptographic key. Key sharing portion To convert Key sharing portion back into a plurality of keys, the client inputs Key sharing portion and the password into the OPRF program, which outputs a plurality of keys. The client can then reconstruct the cryptographic key from the plurality of keys. The client then requests the encrypted private key from the blockchain peer and can decrypt the encrypted private key based on the restored cryptographic key.

[0042] Some of the benefits of the OPRF process described herein include protecting a password from both malicious clients and malicious peers (servers). For example, a malicious client attempting brute force login attempts and / or attempts to learn information stored on the server is prevented from learning the password because the password is not stored on the server or is not accessible to the server. Instead, the password stays with the client throughout the process. Further, a server attempting an offline dictionary attack or a man-in-the-middle attack is prevented from obtaining the password because the server does not store the password. Further, Each key sharing portion appears random.

[0043] FIG. 1A shows a process 100A for storing an encrypted private key 101' using a blockchain network, according to an exemplary embodiment. Referring to FIG. 1A, a client application (e.g., a blockchain client, etc.) may receive a private key 101 from a blockchain wallet (not shown). Here, the private key 101 may be part of an asymmetric key pair that includes a corresponding public key associated with the blockchain wallet. In this example, the client application 110 may encrypt the private key 101 based on an encryption key 102 to generate an encrypted private key 101'.

[0044] According to various embodiments, the client application 110 may store the encrypted private key 101' and the fees using one or more blockchain peers 131, 132, 133, and 134 of a blockchain network that manages the blockchain 130. In addition to encrypting the private key 101, the fees that would be assigned to the blockchain peers 131, 132, 133, and 134 may be similarly encrypted to prevent the blockchain peers from spending the fees. In this example, the blockchain peers 131 - 134 may be servers that execute a blockchain ledger that is distributed / replicated among all of the blockchain peers 131 - 134. The fees may be compensation included in a transaction stored on the blockchain 130. When the client application 110 subsequently requests the encrypted private key 101' from the blockchain peers 131 - 134, the client application 110 may decrypt the fee transaction and provide the decrypted fees to any of the blockchain peers 131 - 134. In response, the blockchain peers 131 - 134 may execute the corresponding transaction, collect the fees, and return the encrypted private key (as shown in FIG. 1D).

[0045] FIG. 1B is according to an exemplary embodiment, the encryption key 102, via a Oblivious Pseudorandom Function (OPRF) service 120 Key sharing portionThe process 100B of converting to 122A~122D is shown. Referring to FIG. 1B, the client application 110 may generate a plurality of keys 112A, 112B, 112C, and 112D based on the encryption key 102. Here, the keys 112A~112D may be pseudo-random values extracted from the encryption key 102 or the like. Here, the number of the keys 112A~112D may be based on the number of blockchain peers of the network used by the client application 110. For example, the keys 112A~112D may be random values uniformly sampled from larger prime numbers. The keys 112A~112D are generated so that they can be used to restore the encryption key 102 via the OPRF protocol.

[0046] In an exemplary embodiment, the user 111 (e.g., associated with the client application 110) has a password 114 or some other secret value. Here, the password 114 may be a text value or an alphanumeric value known only to the user 111. The keys 112A~112D may be output from the client application 110 and input to the OPRF service 120. The password 114 may also be output via a user interface (not shown) of the user device and input to the OPRF service 120. In this example, the OPRF service 120 may be integrated with the client application 110 (on the client device), or this may be a stand-alone service executed on the client device. The OPRF service 120 may convert the plurality of keys 112A~112D into a plurality of OPRF keys 122A~122D via an OPRF protocol using the password 114 so that only the user 111 (who knows the password 114) can restore the keys 112A~112D.

[0047] To generate each of the OPRF keys 122A, 122B, 122C, and 122D, the OPRF service 120 may execute a predetermined function f K (x).

[0048] In this example, f is an OPRF algorithm, K is an input value associated with a blockchain peer (e.g., one of keys 112A - 112D), and x is a secret value from the client application 110 (e.g., password 114). The function f K is a two - party protocol that takes as input a key (one of keys 112A - 112D) and a secret value (password 114) and returns OPRF keys 122A - 122D associated with the specific password 114 of user 111. For example, the OPRF service 120 may receive as input key 112A and password 114 and output the OPRF key 122A assigned to the blockchain peer 131. This process may be executed for each of the blockchain peers 131 - 134. The OPRF service 120 may generate the OPRF keys 122A - 122D in parallel (simultaneously), sequentially (e.g., one at a time), with partial temporal overlap, etc. Examples of the OPRF function (f) include, but are not limited to, DH - OPRF and Naor - Reingold. Further, the OPRF keys 122A - 122D are each distributed among a plurality of blockchain peers 131 - 134. As a result, the blockchain peers 131 - 134 do not learn anything about the password 114.

[0049] The function f K is a pseudorandom function if it is efficiently computable, K is randomly selected, and no efficient algorithm can distinguish f Kcannot be distinguished from a random function. Further, the client application 110 may associate each of the keys 112A - 112D with one of the blockchain peers 131 - 134, respectively. In this system, the OPRF protocol is necessarily a two - party protocol between the client application 110 and each of the blockchain peers 131 - 134, where the client provides the input x, the blockchain peer is registered with the input K, and after the protocol, the client calculates f K (x) such that the blockchain peer learns nothing about the password 114.

[0050] Figure 1C shows a process 100C for restoring the encryption key 102 according to an exemplary embodiment. In this example, the OPRF service 120 may restore the encryption key 102 based on the OPRF keys 122A - 122D stored using the blockchain peers 131 - 134 in the process 100B of Figure 1B and the password 114 supplied by the user 111. Referring to Figure 1C, the OPRF service 120 receives the plurality of OPRF keys 122A - 122D held by the plurality of peers 131 - 134, respectively, and receives the password 114 from the user 111. If the secret - sharing method used requires only a predetermined threshold of keys (e.g., quorum, etc.) of the keys to restore the encryption key 102, it is not necessary for the OPRF service 120 to receive all of the OPRF keys 122A - 122D. In this case, the OPRF service 120 may evaluate the OPRF keys 122A - 122D when the user 111 provides the password 114. The OPRF service 120 may execute the OPRF function f K (x) to restore the plurality of keys 112A - 112D. Next, the OPRF service 120 or the client application 110 may restore the encryption key 102 from the plurality of keys 112A - 112D, and the plurality of keys 112A - 112D can be used to decrypt the encrypted private key 101' to reveal the private key 101.

[0051] FIG. 1D shows a process 100D for decrypting a fee transaction and obtaining an encrypted private key 101' from blockchain peers 131 to 134 according to an exemplary embodiment. Referring to FIG. 1D, a client application 110 restores an encryption key 102 based on a plurality of keys 112A to 112D as described in the example of FIG. 1C. In this example, the client application 110 may decrypt a fee transaction stored on blockchain peers 131 to 134 based on the restored encryption key 102 and exchange the decrypted transaction with the encrypted private key 101'. In this example, the client application 110 transfers the decrypted transaction to each of the blockchain peers 131 to 134, enabling them to receive payments. Next, one or more of the blockchain peers 131 to 134 may return the encrypted private key 101'. In response, the client application 110 may decrypt the encrypted private key 101' to restore the original private key 101.

[0052] Figure 2A shows a blockchain architecture configuration 200 according to an exemplary embodiment. Referring to Figure 2A, the blockchain architecture 200 may include certain blockchain elements, such as a group of blockchain nodes 202. The blockchain nodes 202 may include one or more nodes 204 - 210 (these four nodes are merely shown as examples). These nodes participate in a plurality of activities such as the blockchain transaction addition and validation process (consensus). One or more of the blockchain nodes 204 - 210 may approve transactions based on an approval policy and may provide an ordering service to all the blockchain nodes within the architecture 200. The blockchain nodes may initiate blockchain authentication and attempt to write to the blockchain ledger stored in the blockchain layer 216, and a copy thereof may be stored on the underlying physical infrastructure 214. The blockchain configuration may include one or more applications 224 linked to an application programming interface (API) 222 to access and execute the stored program / application code 220 (e.g., chain code, smart contract, etc.). The stored program / application code 220 can be created according to a customized configuration required by the participants, maintain their own state, control their own assets, and receive external information. This can be deployed as a transaction and installed on all the blockchain nodes 204 - 210 via addition to the distributed ledger.

[0053] The blockchain-based or platform 212 may include various layers of underlying physical computer infrastructure that can be used to receive and store blockchain data, services (such as cryptographic trust services, virtual execution environments, etc.), and new transactions, and provide access to auditors attempting to access data entries. The blockchain layer 216 may expose an interface that processes program code and provides access to the virtual execution environment necessary to engage the physical infrastructure 214. The cryptographic trust service 218 may be used to verify transactions such as asset exchange transactions and keep information private.

[0054] The blockchain architecture configuration of FIG. 2A may process and execute program / application code 220 via one or more interfaces presented by the blockchain platform 212 and the services provided thereby. The code 220 may control blockchain assets. For example, the code 220 may be able to store and transfer data and may be executed by nodes 204-210 in the form of smart contracts and associated chain code, along with other code elements that are the subject of conditions or its execution. As a non-limiting example, a smart contract may be created to execute reminders, updates, and / or other notifications that are the subject of changes, updates, etc. A smart contract can use itself to identify authorization and access requirements and rules associated with the use of ledgers. For example, a smart contract (or chain code that executes the logic of the smart contract) may read blockchain data 226 that can be processed by one or more processing entities (such as virtual machines) included in the blockchain layer 216 to generate results 228 including alerts, determination of liability, etc. within a complex service scenario. The physical infrastructure 214 may be utilized to obtain any of the data or information described herein.

[0055] Smart contracts can be created via high-level applications and programming languages and then written to blocks within a blockchain. A smart contract may include executable code that is registered, stored, and / or replicated using a blockchain (e.g., a distributed network of blockchain peers). A transaction is the execution of smart contract logic that can be executed in response to conditions associated with the smart contract being satisfied. Execution of a smart contract may trigger a trusted modification to the state of a digital blockchain ledger. Modifications to the blockchain ledger caused by smart contract execution may be automatically replicated across the distributed network of blockchain peers through one or more consensus protocols.

[0056] Smart contracts may write data to the blockchain in the format of key-value pairs. Additionally, smart contract code can read values stored on the blockchain and use them in application operations. Smart contract code can write the output of various logical operations to one or more blocks within the blockchain. The code may be used to create temporary data structures in a virtual machine or other computing platform. Data written to the blockchain can be made public and / or encrypted and maintained privately. Temporary data used / generated by a smart contract is held in memory by the provided execution environment and then deleted once the data required for the blockchain is identified.

[0057] The chain code may include the code interpretation (e.g., logic) of the smart contract. For example, the chain code may include a packaged and deployable version of the logic within the smart contract. As described herein, the chain code may be program code deployed on a computing network, where it is executed and validated by the chain validators together during the consensus process. The chain code may receive a hash and obtain from the blockchain a hash associated with a data template created using a previously stored feature extractor. If the hash of the hash identifier and the hash created from the stored identifier template data match, the chain code sends an authorization key to the requested service. The chain code may be written to the blockchain data associated with the cryptographic details.

[0058] Figure 2B shows an example of a blockchain transaction flow 250 between nodes of a blockchain according to an exemplary embodiment. Referring to Figure 2B, the transaction flow may include a client node 260 sending a transaction proposal 291 to an endorser peer node 281. The endorser peer 281 may verify the client signature and execute a chaincode function to initiate a transaction. The output may include a chaincode result, a set of key / value versions read in the chaincode (read set), and a set of key / values written to the chaincode (write set). Here, the endorser peer 281 may determine whether to approve the transaction proposal. The proposal response 292, if committed, is returned to the client 260 along with an endorsement signature. The client 260 assembles the approval into the transaction payload 293 and broadcasts it to the ordering service node 284. Thereafter, the ordering service node 284 delivers the ordered transactions as blocks to all peers 281-283 on the channel. Before committing to the blockchain, each peer 281-283 may validate the transaction. For example, the peer may check an endorsement policy to ensure that the correct assignment of the specified peer has signed the result and that the signature for the transaction payload 293 has been authenticated.

[0059] Referring back to Figure 2B, the client node starts transaction 291 by constructing a request and sending it to the approving peer node 281. The client 260 may include an application that utilizes the available API and leverages a supported software development kit (SDK) to generate a transaction proposal. The proposal is a request to call a chaincode function so that data can be read and / or written to the ledger (i.e., write a new key-value pair for an asset). The SDK may function as a shim that packages the transaction proposal into a properly designed format (e.g., a protocol buffer for a remote procedure call (RPC)) and incorporates the client's cryptographic credentials to generate a unique signature for the transaction proposal.

[0060] In response, the approving peer node 281 may verify that (a) the transaction proposal is well-formed, (b) the transaction has not already been submitted in the past (protection against replay attacks), (c) the signature is valid, and (d) the submitter (in this case, the client 260) is properly authorized to perform the proposed action on that channel. The approving peer node 281 may take in the transaction proposal input as an argument to the chaincode function being called. The chaincode is then executed against the current state database to generate a transaction result that includes a response value, a read set, and a write set. However, the ledger is not updated at this point. At 292, the set of values is returned as a proposal response 292 to the client 260's SDK that parses the payload consumed by the application, along with the signature of the approving peer node 281.

[0061] In response, the application of client 260 inspects / verifies the signature of the approving peer and compares the proposed response to determine if it is the same. If the chaincode only queries the ledger, the application inspects the query response and typically will not submit the transaction to the ordering node service 284. If the client application intends to submit a transaction to the ordering node service 284 to update the ledger, the application determines whether the specified approval policy is satisfied before submission (i.e., whether all the peer nodes required for the transaction have approved the transaction). Here, the client may include only one of the multiple parties to the transaction. In this case, each client may have its own approval node, and each approval node is required to approve the transaction. This architecture allows the approval policy to still be enforced by the peers and maintained during the commit validation phase, even if the application chooses not to inspect the response or, otherwise, forwards an unapproved transaction.

[0062] After successful inspection, at stage 293, client 260 assembles the approvals into the transaction proposal and broadcasts the transaction proposal and response within the transaction message to the ordering node 284. The transaction may include a read / write set, an approving peer signature, and a channel ID. The ordering node 284 does not need to inspect the entire content of the transaction to execute its operation. Instead, the ordering node 284 simply receives the transactions from all the channels in the network, orders them chronologically per channel, and may create a block of transactions per channel.

[0063] The block is delivered from the ordering node 284 to all the peer nodes 281-283 on the channel. To ensure that the approval policy is satisfied and that the ledger state has not changed for the read set variables since the read set was generated by transaction execution, the data section within the block may be validated. Further, at stage 295, each peer node 281-283 adds the block to the channel's chain, and for each valid transaction, the write set is committed to the current state database. Events may be issued to notify the client application that a transaction (call) has been immutably added to the chain and to notify whether the transaction has been validated or invalidated.

[0064] Figure 3A shows an example of a permissioned blockchain network 300 featuring a distributed decentralized peer-to-peer architecture. In this example, a blockchain user 302 may initiate a transaction against the permissioned blockchain 304. In this example, the transaction may be deployed, called, or queried and may be issued through a client-side application that utilizes an SDK directly through an API or the like. The network may provide access to a regulator 306 such as an auditor. The blockchain network operator 308 manages membership permissions such as registering the regulator 306 as an "auditor" and registering the blockchain user 302 as a "client". The auditor may be restricted to only querying the ledger, while the client may be authorized to deploy, call, and query specific types of chaincodes.

[0065] The blockchain developer 310 can write chain codes and client-side applications. The blockchain developer 310 can directly deploy the chain code to the network through an interface. To include credentials from the conventional data source 312 in the chain code, the developer 310 can access the data using an out-of-band connection. In this example, the blockchain user 302 connects to the permissioned blockchain 304 through the peer node 314. Before proceeding with any transaction, the peer node 314 obtains the user's registration and transaction certificates from the certification authority 316 that manages the user's role and permissions. In some cases, the blockchain user must own these digital certificates to conduct transactions on the permissioned blockchain 304. On the other hand, a user attempting to utilize the chain code may need to verify their credentials on the conventional data source 312. To confirm the user's authorization, the chain code can use an out-of-band connection to this data through the conventional processing platform 318.

[0066] Figure 3B shows another example of a permissioned blockchain network 320 featuring a distributed decentralized peer-to-peer architecture. In this example, the blockchain user 322 may submit a transaction to the permissioned blockchain 324. In this example, the transaction can be deployed, invoked, or queried and may be issued through a client-side application that utilizes an SDK directly through an API or the like. The network may provide access to regulators 326 such as auditors. The blockchain network operator 328 manages member permissions such as registering the regulator 326 as an "auditor" and registering the blockchain user 322 as a "client". The auditor can be restricted to only querying the ledger, while the client can be authorized to deploy, invoke, and query specific types of chain codes.

[0067] The blockchain developer 330 can write chain codes and client-side applications. The blockchain developer 330 can directly deploy chain codes to the network through an interface. To include credentials from the conventional data source 332 in the chain code, the developer 330 can access the data using an out-of-band connection. In this example, the blockchain user 322 connects to the network through the peer node 334. Before proceeding with any transaction, the peer node 334 obtains the user's registration and transaction certificates from the certification authority 336. In some cases, the blockchain user must possess these digital certificates to conduct transactions on the permissioned blockchain 324. On the other hand, a user attempting to utilize a chain code may need to verify their credentials on the conventional data source 332. To confirm user authorization, the chain code can use an out-of-band connection to this data through the conventional processing platform 338.

[0068] In some embodiments, the blockchain herein may be a permissionless blockchain. In contrast to a permissioned blockchain that requires permission to participate, anyone can participate in a permissionless blockchain. For example, to participate in a permissionless blockchain, a user may start interacting with the network by creating a personal address, submitting a transaction, and thus adding an entry to the ledger. Additionally, all parties have the option to run nodes on the system and utilize a mining protocol that helps verify transactions.

[0069] Figure 3C shows a process 350 in which a transaction is processed by a permissionless blockchain 352 that includes a plurality of nodes 354. A sender 356 desires to send a payment or some other form of value (e.g., a certificate, a medical record, a contract, a good, a service, or any other asset that can be encapsulated in a digital record) to a recipient 358 via the permissionless blockchain 352. In one embodiment, each of the sender device 356 and the recipient device 358 may have a digital wallet (associated with the blockchain 352) that provides user interface control and display of transaction parameters. In response, the transaction is broadcast to the nodes 354 throughout the blockchain 352. Depending on the network parameters of the blockchain 352, the nodes verify (360) the transaction based on rules (which may be predefined or dynamically assigned) established by the creator of the permissionless blockchain 352. For example, this may include verification of the identities of the parties involved. The transaction may be verified immediately or queued with other transactions, and the nodes 354 determine whether the transaction is valid based on a set of network rules.

[0070] In structure 362, valid transactions are formed into blocks and sealed using a lock (hash). This process may be performed by a mining node among the nodes 354. The mining node may utilize additional software specifically for mining and creating blocks of the permissionless blockchain 352. Each block may be identified by a hash (e.g., a 256-bit number, etc.) created using an algorithm agreed upon by the network. Each block may include a header, a pointer or reference to the hash of the header of the preceding block in the chain, and a group of valid transactions. The reference to the hash of the preceding block is associated with the creation of a secure and independent chain of blocks.

[0071] Before a block can be added to the blockchain, the block must be validated. Validation of a permissionless blockchain 352 may include a proof of work (PoW) that is a solution to a puzzle derived from the block's header. Although not shown in the example of FIG. 3C, another process for validating a block is proof of stake. Unlike PoW where the algorithm rewards miners for solving a mathematical problem, in proof of stake, the creator of a new block is selected in a deterministic manner depending on its wealth, also defined as "stake". Subsequently, a similar proof is executed by the selected node.

[0072] In mining 364, a node attempts to solve a block by incrementally changing one variable until the solution meets the network-wide target. This creates the PoW, thereby guaranteeing the correct answer. In other words, the potential solution must prove that computing resources have been exhausted in order to solve the problem. In some types of permissionless blockchains, miners may receive a reward of value (e.g., coins, etc.) for correctly mining a block.

[0073] Here, the PoW process makes it extremely difficult to modify the blockchain because while modifying one block, the attacker has to modify all subsequent blocks for the modification to be accepted. Further, as new blocks are mined, the difficulty of modifying a block increases with the number of subsequent blocks. In dissemination 366, successfully validated blocks are disseminated through the permissionless blockchain 352 and all nodes 354 add the blocks to the majority chain which is an auditable ledger of the permissionless blockchain 352. Further, the value of the transaction submitted by the sender 356 is credited to or otherwise transferred to the digital wallet of the recipient device 358.

[0074] Figure 4A shows a communication process 400A for generating and distributing an OPRF key according to an exemplary embodiment. Referring to Figure 4A, client 410 has a public and private key pair (pk, sk). In this example, the client encrypts the private key (sk) using an encryption key and stores a backup of the encrypted private key (sk) by submitting a plurality of transactions to a plurality of blockchain peers 421, 422, 423, and 424 at 430, 431, 432, and 433, respectively. Each transaction may include the encrypted private key and a fee / compensation for when the client 410 needs to recover the encrypted private key. Here, the number of blockchain peers is not limited to 4 and may be any threshold desired by the protocol.

[0075] At 434, client 410 generates an OPRF key for each of blockchain peers 421 - 424. First, client 410 may generate a plurality of keys that can be used to recover the encryption key. Next, client 410 converts the plurality of keys into a plurality of OPRF keys based on the user password. For each peer, client 410 may randomly generate an OPRF key based on a predefined function f K (x) that takes the key and password as inputs and outputs the OPRF key. This step 434 may be executed iteratively or simultaneously to generate a plurality of OPRF keys for blockchain peers 421 - 424. Client 410 distributes the plurality of OPRF keys to the plurality of blockchain peers 421 - 424 at steps 435, 436, 437, and 438, respectively.

[0076] Although steps 430 - 433 are shown as being executed before steps 434 - 438 in Figure 4A, it should be understood that steps 430 - 433 may be executed after and / or simultaneously with steps 434 - 438. In other words, the order of steps 430 - 438 is not limited to the example illustrated and described in Figure 4A.

[0077] Figure 4B shows a communication process 400B for restoring an encryption key based on a distributed OPRF key according to an exemplary embodiment. Referring to Figure 4B, at 440, the client device 410 sends a request for an OPRF key to the blockchain peers 421-424. The request may be broadcast to all peers 421-424. In response, the blockchain peers 421-424 may send their respective OPRF keys held for the client device 410 at stages 441, 442, 443, and 444. At 445, the client 410 may trigger the execution of an OPRF function (service) to convert the received OPRF key into a corresponding key that can be used to restore the encryption key. In this case, the user may input a password that is input into the OPRF function along with the OPRF key. The output from the OPRF function is the original key. The client 410 can restore the encryption key based on the key at 445. At 446, the client 410 may request an encrypted private key from any of the blockchain peers. In this case, the client receives the encrypted private key from the blockchain peer 421 at 447. The client 410 then decrypts the private key at 448 and uses the private key to sign blockchain transactions, blockchain messages, blockchain requests, etc.

[0078] Figure 5 shows a method 500 for distributing an encryption key among peers in a blockchain network according to an exemplary embodiment. As a non-limiting example, the method 500 may be executed by a client application running on a computing device such as a smartphone, tablet, laptop, desktop, server, cloud platform, etc. Referring to Figure 5, at 510, the method may include encrypting a private key using an encryption key. Here, the encryption key may be generated by the client.

[0079] At 520, the method may include generating a plurality of keys based on a cryptographic key and converting the plurality of keys into a plurality of Key sharing portion based on a secret input value. The secret input may be a password known only to the client. At 530, the method may include storing the encrypted private key on the blockchain. For example, the client may send the encrypted private key to a plurality of blockchain peers of the blockchain. At 540, the method may include Key sharing portion distributing the plurality of Key sharing portion to a plurality of blockchain peers of the blockchain, where distributing includes sending different Key sharing portion from among the plurality of

[0080] In some embodiments, the plurality of keys may include a plurality of pseudorandom values, and the method may further include registering the plurality of pseudorandom values with a plurality of blockchain peers respectively. In some embodiments, converting includes receiving a key and a secret input value from among the plurality of keys and executing a Oblivious Pseudorandom Function (OPRF) that outputs Key sharing portion for each respective key. In some embodiments, converting may further include repeatedly executing the OPRF for each key among the plurality of keys based on the secret input value to output Key sharing portion among the plurality of Each key sharing portion .

[0081] In some embodiments, storing may include distributing a blockchain transaction to a plurality of blockchain peers, where the blockchain transaction includes the encrypted private key and a payment value. In some embodiments, the method includes obtaining a plurality of Key sharing portion from a plurality of blockchain peers and, based on the secret input value, a plurality of Key sharing portionIt may further include converting back to a plurality of keys. In some embodiments, the method may further include restoring an encryption key from the plurality of keys and decrypting the encrypted private key based on the restored encryption key.

[0082] In some embodiments, the method may further include restoring an encryption key from the plurality of keys and decrypting the fee transaction stored by a plurality of blockchain peers based on the restored encryption key. In this example, the method may further include sending the decrypted fee transaction to a blockchain peer out of the plurality, receiving the encrypted private key from the blockchain peer in exchange for the decrypted fee transaction, and decrypting the encrypted private key based on the restored encryption key.

[0083] FIG. 6A shows an exemplary system 600 including a physical infrastructure 610 configured to perform various operations according to an exemplary embodiment. Referring to FIG. 6A, the physical infrastructure 610 includes a module 612 and a module 614. The module 614 includes a blockchain 620 and a smart contract 630 (which may exist on the blockchain 620), which may perform any of the operational steps 608 (in module 612) included in any of the exemplary embodiments. The steps / operations 608 may include one or more of the described or illustrated embodiments and may represent output or written information written to or read from one or more smart contracts 630 and / or the blockchain 620. The physical infrastructure 610, the module 612, and the module 614 may include one or more computers, servers, processors, memories, and / or wireless communication devices. Further, the module 612 and the module 614 may be the same module.

[0084] Figure 6B shows another exemplary system 640 configured to perform various operations according to an exemplary embodiment. Referring to Figure 6B, system 640 includes module 612 and module 614. Module 614 includes blockchain 620 and smart contract 630 (which may exist on blockchain 620), which may perform any of the operation steps 608 (in module 612) included in any of the exemplary embodiments. Step / operation 608 may include one or more of the described or illustrated embodiments and may represent output or written information that is written to or read from one or more smart contracts 630 and / or blockchain 620. Physical infrastructure 610, module 612, and module 614 may include one or more computers, servers, processors, memories, and / or wireless communication devices. Further, module 612 and module 614 may be the same module.

[0085] Figure 6C shows an exemplary system configured to utilize a smart contract configuration among contract parties and an intermediary server configured to enforce smart contract terms on a blockchain according to an exemplary embodiment. Referring to Figure 6C, configuration 650 may represent a communication session, asset transfer session, or process or procedure driven by smart contract 630 that explicitly identifies one or more user devices 652 and / or 656. The execution, operation, and results of smart contract execution may be managed by server 654. The content of smart contract 630 may require a digital signature by one or more of entities 652 and 656, which are parties to the smart contract transaction. The results of smart contract execution may be written to blockchain 620 as a blockchain transaction. Smart contract 630 exists on blockchain 620, which may exist on one or more computers, servers, processors, memories, and / or wireless communication devices.

[0086] FIG. 6D shows a system 660 including a blockchain according to an exemplary embodiment. Referring to the example of FIG. 6D, an application programming interface (API) gateway 662 provides a common interface for accessing blockchain logic (e.g., smart contract 630 or other chain code) and data (e.g., distributed ledger, etc.). In this example, the API gateway 662 is a common interface for executing transactions (calls, queries, etc.) on the blockchain by connecting one or more entities 652 and 656 to a blockchain peer (i.e., server 654). Here, the server 654 is a blockchain network peer component that holds a copy of the world state and the distributed ledger, enabling the client 652 and 656 to query data against the world state and submit transactions to the blockchain network where the approval peer executes the smart contract 630, depending on the smart contract 630 and the approval policy.

[0087] The above embodiments may be implemented in hardware, in a computer program executed by a processor, in firmware, or in a combination of the above. The computer program may be embodied on a computer-readable medium such as a storage medium. For example, the computer program may be present in random access memory ("RAM"), flash memory, read-only memory ("ROM"), erasable programmable read-only memory ("EPROM"), electrically erasable programmable read-only memory ("EEPROM"), registers, hard disk, removable disk, compact disc read-only memory ("CD-ROM"), or any other form of storage medium known in the art.

[0088] An exemplary memory medium may be coupled to a processor such that the processor can read information from and write information to the memory medium. In an alternative form, the memory medium may be integrated with the processor. The processor and the memory medium may be present within an application specific integrated circuit (an "ASIC"). In an alternative form, the processor and the memory medium may exist as separate components.

[0089] FIG. 7A shows a process 700 in which a new block is added to the distributed ledger 720 according to an exemplary embodiment, and FIG. 7B shows the content of a new data block structure 730 for a blockchain according to an exemplary embodiment. Referring to FIG. 7A, a client (not shown) may submit a transaction to blockchain nodes 711, 712, and / or 713. The client may be an instruction to perform an activity on the blockchain 720 received from any source. As an example, the client may be an application that operates on behalf of a requester such as a device, person, or entity to propose a transaction to the blockchain. Different types of blockchain nodes / peers, including an approval peer that simulates and approves a transaction proposed by the client, and a committing peer that verifies the approval, validates the transaction, and commits the transaction to the distributed ledger 720, may exist within the blockchain network. In this example, blockchain nodes 711, 712, and 713 may serve as approval nodes, commit nodes, or both.

[0090] The distributed ledger 720 comprises a blockchain that stores immutable sequenced records in blocks, and a state database 724 (current world state) that maintains the current state of the blockchain 722. One distributed ledger 720 may exist for each channel, and each peer maintains its own copy of the distributed ledger 720 for each channel of which the peer is a member. The blockchain 722 is a transaction log constructed as a hash-linked list of blocks where each block contains a sequence of N transactions. The blocks may contain various components such as those shown in FIG. 7B. The links of the blocks (indicated by the arrows in FIG. 7A) may be generated by adding the hash of the header of the previous block within the block header of the current block. In this way, all transactions on the blockchain 722 are sequenced and cryptographically linked together, preventing the blockchain data from being tampered with without breaking the hash links. Further, due to the links, the latest block in the blockchain 722 represents all transactions that have come before it. The blockchain 722 may be stored on a peer file system (local or attached storage) that supports an append-only blockchain workload.

[0091] The current state of the blockchain 722 and the distributed ledger 722 may be stored in the state database 724. Here, the data of the current state represents the latest values for all keys that have been included in the chain transaction log of the blockchain 722 so far. The chain code calls execute transactions against the current state within the state database 724. To make these chain code interactions extremely efficient, the latest values of all keys are stored in the state database 724. The state database 724 may include an indexed view into the transaction log of the blockchain 722, and thus, this can be regenerated from the chain at any point in time. The state database 724 may be automatically restored (or generated if necessary) at the startup of the peer node, before transactions are accepted.

[0092] The approval node receives a transaction from the client and approves the transaction based on the simulation result. The approval node holds a smart contract that simulates the transaction proposal. When the approval node approves a transaction, the approval node creates a transaction approval, which is a signed response from the approval node indicating the approval of the simulated transaction, to the client application. The method of approving a transaction depends on the approval policy that can be specified within the chain code. An example of an approval policy is that "a majority of the approving peers must approve the transaction". Different channels may have different approval policies. The approved transaction is transferred by the client application to the ordering service 710.

[0093] The ordering service 710 accepts the approved transactions, orders them into one block, and delivers the block to the committing peers. For example, the ordering service 710 may start a new block when a threshold of transactions is reached, a timer times out, or another condition occurs. In the example of FIG. 7A, the blockchain node 712 is the committing peer that has received a new data block 730 of new data for storage on the blockchain 720. The first block in the blockchain may be referred to as the genesis block, which contains information about the blockchain, its members, the data stored therein, etc.

[0094] The ordering service 710 may be composed of a cluster of orderers. The ordering service 710 does not process transactions, smart contracts, or maintain a shared ledger. Rather, the ordering service 710 may accept the approved transactions and specify the order in which those transactions are committed to the distributed ledger 720. The architecture of the blockchain network may be designed such that the specific implementation of "ordering" (e.g., Solo, Kafka, BFT, etc.) is a pluggable component.

[0095] Transactions are written to the distributed ledger 720 in a consistent order. The order of the transactions is established to ensure that the updates to the state database 724 are valid when they are committed to the network. Unlike a cryptocurrency blockchain system (e.g., Bitcoin, etc.) where ordering is done through solving a cryptographic puzzle or mining, in this example, the parties of the distributed ledger 720 may choose the ordering mechanism that best fits the network.

[0096] When the ordering service 710 initializes a new data block 730, the new data block 730 may be broadcast to the committing peers (e.g., blockchain nodes 711, 712, and 713). In response, each committing peer validates the transactions in the new data block 730 by checking to ensure that the read set and write set still match the current world state in the state database 724. Specifically, the committing peer can determine whether the read data that existed when the approver simulated the transaction is identical to the current world state in the state database 724. When a committing peer validates a transaction, the transaction is written to the blockchain 722 on the distributed ledger 720, and the state database 724 is updated with the write data from the read-write set. If the transaction fails, i.e., the committing peer discovers that the read-write set does not match the current world state in the state database 724, the ordered and blocked transactions are still included in the block but are marked as invalid and the state database 724 is not updated.

[0097] Referring to FIG. 7B, a new data block 730 (also referred to as a data block) stored on the blockchain 722 of the distributed ledger 720 may include a plurality of data segments such as a block header 740, block data 750 (block data section), and block metadata 760. It should be understood that the various illustrated blocks such as the new data block 730 and its contents shown in FIG. 7B are merely examples and are not intended to limit the scope of the exemplary embodiments. In a conventional block, the data section may store transaction information for N transactions (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) within the block data 750.

[0098] The new data block 730 may include a link to a previous block (e.g., on the blockchain 722 in FIG. 7A) within the block header 740. In particular, the block header 740 may include a hash of the header of the previous block. The block header 740 may also include a unique block number, a hash of the block data 750 of the new data block 730, and the like. The block number of the new data block 730 is unique and may be assigned in various orders such as incremental / sequential order starting from 0.

[0099] The block metadata 760 may store a plurality of fields of metadata (e.g., as a byte array or the like). The metadata fields may include a signature for block creation, a reference to the last configuration block, a transaction filter that identifies valid and invalid transactions within the block, the last persistent offset of an ordering service that ordered the block, and the like. The signature, the last configuration block, and the order metadata may be added by the ordering service 710. On the other hand, a committing node of the block (such as the blockchain node 712) may add validity / invalidity information based on an approval policy, verification of a read / write set, and the like. The transaction filter may include a byte array of a size equal to the number of transactions included in the block data 750, and a validation code that identifies whether the transaction was valid / invalid.

[0100] FIG. 7C shows an embodiment of a blockchain 770 for digital content according to the embodiments described herein. The digital content may include one or more files and associated information. The files may include media, images, videos, audio, text, links, graphics, animations, web pages, documents, or other forms of digital content. The immutable append-only aspect of the blockchain functions as a safeguard to protect the integrity, validity, and authenticity of the digital content, and is appropriately used in legal procedures where admissibility rules apply, or in other settings where evidence is considered, or in other respects where the presentation and use of digital information are of interest. In this case, the digital content may be referred to as digital evidence.

[0101] The blockchain may be formed in various ways. In one embodiment, the digital content may be included in and accessed from the blockchain itself. For example, each block of the blockchain may store a hash value of reference information (e.g., header, value, etc.) along with the associated digital content. Next, the hash value and the associated digital content may both be encrypted. Therefore, the digital content of each block may be accessed by decrypting each block within the blockchain, and the hash value of each block may be used as a basis for referencing the previous block. This can be shown as follows: Block 1 Block 2...... Block N Hash value 1 Hash value 2 Hash value N Digital content 1 Digital content 2 Digital content N

[0102] In one embodiment, the digital content may not be included in the blockchain. For example, the blockchain may store the encrypted hash of the content of each block without any of the digital content. The digital content may be stored in another storage area or memory address in relation to the hash value of the original file. The other storage area may be the same storage device used to store the blockchain, or it may be a different storage area or even a separate relational database. The digital content of each block may be referenced or accessed by obtaining or querying the hash value of the block of interest and then looking up the value within the storage area that is stored in association with the actual digital content. This operation may be performed, for example, by a database gatekeeper. This can be shown as follows: Blockchain Storage Area Block 1 Hash Value Block 1 Hash Value... Content Block N Hash Value Block N Hash Value... Content

[0103] In the exemplary embodiment of FIG. 7C, the blockchain 770 includes a plurality of blocks 7781, 7782,... 778 that are cryptographically linked in a sequential order N where N≧1. The encryption used to link the blocks 7781, 7782,... 778 N may be any of a plurality of hashing functions with or without keys. In one embodiment, the blocks 7781, 7782,... 778 Nis subject to a hash function that generates an n-bit alphanumeric output (where n is 256 or another number) from an input based on the information within the block. Examples of such hash functions include, but are not limited to, SHA type (SHA is an abbreviation for Secure Hash Algorithm) algorithms, Merkle-Damgård algorithms, HAIFA algorithms, Merkle tree algorithms, non-base algorithms, and collision-resistant hard PRF algorithms. In another embodiment, blocks 7781, 7782, ..., 778 N may be cryptographically linked by a function different from the hash function. For purposes of illustration, the following description is made with reference to a hash function, for example, SHA-2.

[0104] Each of the blocks 7781, 7782, ..., 778 within the blockchain N contains a header, a version of the file, and a value. The header and the value are different for each block as a result of the hashing within the blockchain. In one embodiment, the value may be included in the header. As will be described in more detail below, the version of the file may be the original file or a different version of the original file.

[0105] The first block 7781 within the blockchain is referred to as the genesis block and contains the header 7721, the original file 7741, and the initial value 7761. The hashing method used in the genesis block, and in fact all subsequent blocks, may be different. For example, all the information within the first block 7781 may be hashed together at once, or each or a portion of the information within the first block 7781 may be hashed separately, and then a hash of the separately hashed portions may be performed.

[0106] The header 7721 may include one or more initial parameters, which may include, for example, a version number, a timestamp, a nonce, route information, difficulty, a consensus protocol, a duration, a media format, a source, descriptive keywords, and / or other information associated with the original file 7741 and / or the blockchain. The header 7721 may be generated automatically (e.g., by a blockchain network that manages software) or manually by a blockchain participant. Unlike the headers within the other blocks 7782 - 778 N within the blockchain, the header 7721 within the genesis block does not reference a previous block, simply because there is no previous block.

[0107] The original file 7741 within the genesis block may be data captured by a device, with or without processing prior to including it in the blockchain. The original file 7741 is received from a device, a media source, or a node through an interface of the system. The original file 7741 is associated with metadata, which may be generated by a user, a device, and / or a system processor, either manually or automatically. The metadata may be included within the first block 7781 in relation to the original file 7741.

[0108] The value 7761 within the genesis block is an initial value generated based on one or more unique attributes of the original file 7741. In one embodiment, the one or more unique attributes may include a hash value of the original file 7741, the metadata of the original file 7741, and other information associated with the file. In one implementation, the initial value 7761 may be based on the following unique attributes: 1) The SHA-2 computed hash value of the original file 2) The source device ID 3) The start timestamp of the original file 4) The initial storage location of the original file 5) The blockchain network member ID of the software that currently controls the original file and the associated metadata

[0109] Other blocks 7782 - 778 in the blockchain N also have headers, files, and values. However, unlike the first block 7721, the headers 7722 - 772 in other blocks N each contain the hash value of the previous block. The hash value of the previous block may simply be the hash of the header of the preceding block or, alternatively, the hash value of the entire preceding block. By including the hash value of the preceding block in each of the remaining blocks, a trace can be executed block - by - block from the Nth block back to the genesis block (and the associated original file), as indicated by arrow 780, in order to establish auditable and immutable evidence preservation.

[0110] Also, the headers 7722 - 772 in other blocks N each may contain other information, such as version numbers, timestamps, nonces, root information, difficulty levels, consensus protocols, and / or other parameters or information associated with the corresponding file and / or the blockchain as a whole.

[0111] The files 7742 - 774 in other blocks N may be, for example, the same as the original file depending on the type of processing being performed or, alternatively, a modified version of the original file in the genesis block. The type of processing being performed may vary from block to block. The processing may involve, for example, editing or otherwise changing the information of the file, removing information from the file, or adding or appending information to the file, i.e., any modification of the file in the preceding block.

[0112] Additionally or alternatively, the processing may involve merely copying a file from a preceding block, changing the storage location of a file, analyzing a file from one or more preceding blocks, moving a file from one storage or memory location to another, or performing an action on a file of a blockchain and / or its associated metadata. Processing involving file analysis may include, for example, adding, incorporating, or otherwise associating various analytics, statistics, or other information related to the file.

[0113] The values in each of the other blocks within the other block 7762~776 N are unique values and all different as a result of the processing performed. For example, the value in any one block corresponds to an updated version of the value in the preceding block. The update is reflected in the hash of the block to which the value is assigned. Thus, the value of a block provides an indication of what processing was performed in the block and also permits tracing back through the blockchain to the original file. This tracing verifies the integrity of the file throughout the blockchain.

[0114] For example, consider the case where a portion of a file within a preceding block has been edited, blocked out, or pixelated in order to protect the identity of a person shown in the file. In this case, the block containing the edited file includes metadata associated with the edited file, such as how the edit was performed, who performed the edit, the timestamp at which the edit was made, etc. The metadata may be hashed to form a value. Since the metadata for a block is different from the information hashed to form the value in the preceding block, these values are different from each other and may be restored when decoded.

[0115] In one embodiment, when any one or more of the following occur, the value of the previous block may be updated (e.g., a new hash value may be calculated) and the value of the current block may be formed. The new hash value may, in this exemplary embodiment, be calculated by hashing all or a portion of the information described below. a) If the file is being processed in any way (e.g., if the file has been edited, copied, modified, accessed, or some other action has been taken), a new SHA-2 computed hash value, b) A new storage location for the file, c) Identified new metadata associated with the file, d) Transfer of access or control of the file from one blockchain participant to another blockchain participant.

[0116] FIG. 7D shows an embodiment of a block that may represent the structure of a block within blockchain 790, according to one embodiment. The block, i.e., Block i includes a header 772 i a file 774 i and a value 776. i

[0117] The header 772 i includes the hash value of the previous block Block i-1 and additional reference information that can be of any type of information discussed herein (e.g., header information including references, characteristics, parameters, etc.). All blocks, of course, except the genesis block, reference the hash of the previous block. The hash value of the previous block may simply be the hash of the header within the previous block, or the hash of all or a portion of the information within the previous block, including the file and metadata.

[0118] The file 774 i ​includes a plurality of data such as data 1, data 2, ..., data N in the sequence. The data is tagged with metadata 1, metadata 2, ..., metadata N that describes the content and / or characteristics associated with the data. For example, the metadata for each data may include the timestamp of the data, the process of the data, keywords indicating the person or other content shown in the data, and / or other features that may be useful for establishing the validity and content of the file as a whole, and, in particular, information indicating digital evidence as described in the embodiments discussed below. In addition to the metadata, each data is tagged with references REF1, REF2, ..., REF to the previous data in order to prevent tampering, gaps in the file, and sequence references through the file. N may be tagged.

[0119] Once the metadata is assigned to the data (e.g., through a smart contract), the metadata cannot be changed without a change in the hash that can be easily identified for invalidation. Therefore, the metadata creates a data log of information that can be accessed for use by participants within the blockchain.

[0120] Value 776 i is a hash value or another value calculated based on any of the types of information described above. For example, for any given block Block i the value for that block may be updated to reflect the processing performed on that block, such as a new hash value, a new storage location, new metadata for the associated file, a transfer of control or access, an identifier, or other actions or information added. The value within each block is shown to be separate from the metadata and headers for the data of the file, but in another embodiment, the value may be based in part or in whole on this metadata.

[0121] Once the blockchain 770 is formed, at any point in time, immutable evidence preservation for a file may be obtained by querying the blockchain for the transaction history of values across the blocks. This query, or tracing procedure, may start by decrypting the values of the most recently included block (e.g., the last (the Nth) block), and then continuing to decrypt the values of other blocks until the genesis block is reached and the original file is restored. Decryption may also involve decrypting the headers and files and associated metadata in each block.

[0122] Decryption is performed based on the type of encryption performed in each block. This may involve the use of a private key, a public key, or a public-private key pair. For example, when asymmetric encryption is used, blockchain participants or processors within the network may generate a public key and a private key pair using a given algorithm. The public key and the private key are related to each other through some mathematical relationship. The public key may be distributed publicly so as to function as an address for receiving messages from other users, such as an IP address or a home address. The private key is kept secret and is used for digital signature messages sent to other blockchain participants. The signature is included in the message so that the recipient can verify it using the sender's public key. In this way, the recipient can ensure that only the sender could have sent this message.

[0123] Generating the key pair may be similar to creating an account on the blockchain, but there is no need to actually register anywhere. Also, all transactions executed on the blockchain are digitally signed by the sender using their private key. This signature ensures that only the owner of the account can track and process the blockchain's files (if within the scope of permission determined by the smart contract).

[0124] Figures 8A and 8B show additional examples of use cases of blockchain that can be incorporated and used in this specification. In particular, FIG. 8A shows an example 800 of a blockchain 810 that stores machine learning (artificial intelligence) data. Machine learning relies on a vast amount of historical data (or training data) to build a predictive model for accurate prediction of new data. Machine learning software (e.g., neural networks, etc.) can often sort through millions of records and discover non-intuitive patterns.

[0125] In the example of FIG. 8A, the host platform 820 builds and deploys a machine learning model for predictive monitoring of the asset 830. Here, the host platform 820 may be a cloud platform, an industrial server, a web server, a personal computer, a user device, etc. The asset 830 can be any type of asset (e.g., a machine or device, etc.) such as an aircraft, a locomotive, a turbine, medical machines and equipment, oil and gas equipment, a boat, a ship, a vehicle, etc. As another example, the asset 830 may be an intangible asset such as stocks, currency, digital coins, insurance, etc.

[0126] The use of blockchain 810 can significantly improve both the training process 802 of a machine learning model and the prediction process 804 based on the trained machine learning model. For example, in 802, instead of requiring a data scientist / engineer or other user to collect data, historical data may be stored on blockchain 810 by the asset 830 itself (or through an intermediary not shown). This can significantly reduce the collection time required by the host platform 820 when performing predictive model training. For example, using smart contracts, data can be transferred directly and securely from its original location to blockchain 810. By using blockchain 810 to ensure the security and ownership of the collected data, smart contracts may directly send data from an asset to an individual using the data to build a machine learning model. This enables sharing of data among assets 830.

[0127] The collected data may be stored on blockchain 810 based on a consensus mechanism. The consensus mechanism incorporates (authorized nodes) to ensure that the recorded data is verified and accurate. The recorded data is time-stamped, cryptographically signed, and immutable. Thus, it is auditable, transparent, and secure. Adding IoT devices that write directly to the blockchain can increase both the frequency and accuracy of the data recorded in certain cases (i.e., supply chain, healthcare, logistics, etc.).

[0128] Furthermore, the training of the machine learning model on the collected data may take rounds of improvement and testing by the host platform 820. Each round may be based on additional data, or data that was not previously considered useful for expanding the knowledge of the machine learning model. At 802, different training and test stages (and the data associated therewith) may be stored on the blockchain 810 by the host platform 820. Each improvement to the machine learning model (e.g., changes to variables, weights, etc.) may be stored on the blockchain 810. This provides verifiable evidence of how the model was trained and what data was used to train the model. Further, when the host platform 820 finally achieves the trained model, the resulting model may be stored on the blockchain 810.

[0129] After the model is trained, it may be deployed to a live environment where it can make predictions / determinations based on the execution of the finally trained machine learning model. For example, at 804, the machine learning model may be used for condition-based maintenance (CBM) of assets such as aircraft, wind turbines, medical devices, etc. In this example, data fed back from the asset 830 may be input into the machine learning model and used to make event predictions such as failure events, error codes, etc. Decisions made by the execution of the machine learning model in the host platform 820 may be stored on the blockchain 810 to provide auditable / verifiable evidence. As one non-limiting example, the machine learning model may predict future failures of a part of the asset 830 and create an alert or notification to replace the part. The data on which this determination is based may be stored by the host platform 820 on the blockchain 810. In one embodiment, the features and / or actions described and / or illustrated herein may be performed on or with respect to the blockchain 810.

[0130] New transactions of the blockchain can be grouped into a new block and added to the existing hash value. Next, this is encrypted to create a new hash for the new block. This is added to the next list of transactions, such as when the transaction is encrypted. The result is a chain of blocks, each containing the hash values of all the previous blocks. The computers storing these blocks regularly compare their hash values to ensure they all match. Any computer with a mismatch discards the record causing the problem. This method is suitable for ensuring the prevention of blockchain tampering but is not perfect.

[0131] One way to exploit the loopholes in this system is for a malicious user to modify the list of transactions to their advantage without changing the hash. This can be done by brute force, in other words, by modifying the record, encrypting the result, and checking whether the hash value is the same. If not, repeat the attempt until a matching hash is found. The security of the blockchain is based on the idea that a normal computer can only perform this type of brute force attack over a completely unrealistic timescale such as the age of the universe. In contrast, a quantum computer is much faster (thousands of times faster) and thus poses a much greater threat.

[0132] Figure 8B shows an example 850 of a quantum-secure blockchain 852 implementing quantum key distribution (QKD) to protect against quantum computing attacks. In this example, blockchain users can use QKD to verify each other's identities. This transmits information using quantum particles such as photons, which cannot be copied without being disrupted by an eavesdropper. In this way, the sender and receiver through the blockchain can confirm each other's identities.

[0133] In the example of FIG. 8B, there are four users 854, 856, 858, and 860. Each pair of users may share a secret key 862 (i.e., QKD) among themselves. Since there are four nodes in this example, there are six pairs of nodes, and thus, six different secret keys 862 including QKD AB , QKD AC , QKD AD , QKD BC , QKD BD , and QKD CD are used. Each pair can create QKD by transmitting information using quantum particles such as photons that cannot be copied by an eavesdropper without being disrupted. In this way, pairs of users can authenticate each other's identities.

[0134] The operation of the blockchain 852 is based on two procedures: (i) creation of a transaction, and (ii) construction of a block that aggregates new transactions. New transactions may be created in the same way as in a conventional blockchain network. Each transaction may include information regarding the sender, the receiver, the time of creation, the amount (or value) transferred, a list of reference transactions justifying that the sender has funds for the operation, etc. Next, this transaction record is sent to all other nodes and put into a pool of unconfirmed transactions. Here, two parties (i.e., a pair of users from among 854 - 860) authenticate the transaction by providing their shared secret key 862 (QKD). This quantum signature can be attached to all transactions, making forgery extremely difficult. Each node checks its own entry with respect to the local copy of the blockchain 852 to verify that each transaction has sufficient funds. However, the transaction has not yet been confirmed.

[0135] Rather than performing a conventional mining process on a block, a block may be created in a decentralized manner using a broadcast protocol. During a predetermined period (e.g., seconds, minutes, hours, etc.), the network applies the broadcast protocol to any unconfirmed transactions, whereby a Byzantine consensus regarding the correct version of the transaction can be achieved. For example, each node may own a private value (the transaction data of that particular node). In the first round, the nodes send their private values to each other. In subsequent rounds, the nodes communicate the information received from other nodes in the previous round. Here, an honest node can create a complete set of transactions within a new block. This new block can be added to the blockchain 852. In one embodiment, the features and / or actions described and / or illustrated herein can be performed on or with respect to the blockchain 852.

[0136] Figure 9 shows an exemplary system 900 that supports one or more of the exemplary embodiments described and / or illustrated herein. The system 900 includes a computer system / server 902 operable to operate with a number of other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations suitable for use with the computer system / server 902 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments including any of the above systems or devices, etc.

[0137] The computer system / server 902 may be described in the general context of computer system-executable instructions, such as program modules, being executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform particular tasks or implement particular abstract data types. The computer system / server 902 may be practiced in a distributed cloud computing environment where tasks are performed by remote processing devices linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media including memory storage devices.

[0138] As shown in FIG. 9, the computer system / server 902 within the cloud computing node 900 is shown in the form of a general-purpose computing device. The components of the computer system / server 902 may include, but are not limited to, one or more processors or processing units 904, a system memory 906, and a bus that couples various system components including the system memory 906 to the processor 904.

[0139] The bus represents one or more of any of several types of bus structures including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example and without limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus.

[0140] The computer system / server 902 typically includes a variety of computer system readable media. Such media can be any available media accessible by the computer system / server 902, including both volatile and non-volatile media, removable and non-removable media. System memory 906, in one embodiment, implements the flow diagrams of other figures. System memory 906 can include computer system readable media in the form of volatile memory, such as random access memory (RAM) 910 and / or cache memory 912. The computer system / server 902 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 914 can be provided to read from and write to a non-removable, non-volatile magnetic medium (not shown, typically referred to as a "hard drive"). Although not shown, a magnetic disk drive for reading from and writing to a removable non-volatile magnetic disk (e.g., a "floppy disk"), and an optical disk drive for reading from or writing to a removable non-volatile optical disk such as a CD-ROM, DVD-ROM or other optical media can be provided. In such cases, each can be connected to the bus by one or more data media interfaces. As further illustrated and described below, memory 906 may include at least one program product having a set of program modules (e.g., at least one) configured to execute the functions of various embodiments of the application.

[0141] Program / utility 916 having a set (at least one) of program modules 918 may be stored in memory 906, by way of example and not limitation, as may an operating system, one or more application programs, other program modules, and program data. Similarly, the operating system, one or more application programs, other program modules, and program data may each or any combination thereof include implementation of a networking environment. Program modules 918 generally execute the functionality and / or methodologies of various embodiments of the application as described herein.

[0142] As will be appreciated by one of ordinary skill in the art, aspects of the present application may be embodied as a system, method, or computer program product. Accordingly, aspects of the present application may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects that may generally all be referred to herein as a “circuit,” “module,” or “system.” Furthermore, aspects of the present application may take the form of a computer program product embodied in one or more computer readable media having computer readable program code embodied thereon.

[0143] In addition, the computer system / server 902 may communicate with one or more external devices 920 such as a keyboard, a pointing device, a display 922, etc.; one or more devices that enable a user to interact with the computer system / server 902; and / or any device that enables the computer system / server 902 to communicate with one or more other computing devices (e.g., a network card, a modem, etc.). Such communication can be performed via the I / O interface 924. Furthermore, the computer system / server 902 can communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet) via the network adapter 926. As shown, the network adapter 926 communicates with other components of the computer system / server 902 via a bus. Although not shown, it should be understood that other hardware and / or software components can be used in conjunction with the computer system / server 902. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archive storage systems, etc.

[0144] Exemplary embodiments of at least one of a system, a method, and a non-transitory computer-readable medium are shown in the accompanying drawings and described in the foregoing detailed description, but the present application is not limited to the disclosed embodiments, and it will be understood that numerous rearrangements, modifications, and substitutions are possible as set forth and defined in the following claims. For example, the functionality of the systems of the various figures can be performed by one or more of the modules or components described herein or in a distributed architecture and may include a transmitter, a receiver, or a pair of both. For example, all or part of the functionality performed by individual modules may be performed by one or more of these modules. Further, the functionality described herein may be performed at various times in relation to various events internal or external to the modules or components. Also, the information transmitted between the various modules can be transmitted between the modules via at least one of a data network, the Internet, a voice network, an Internet protocol network, a wireless device, a wired device, and / or via multiple protocols. Also, messages transmitted or received by any of the modules may be transmitted or received directly and / or via one or more of the other modules.

[0145] One of ordinary skill in the art will understand that a "system" can be embodied as a personal computer, a server, a console, a personal digital assistant (PDA (registered trademark)), a mobile phone, a tablet computing device, a smartphone or any other suitable computing device, or a combination of devices. Presenting the functions described above as being performed by a "system" is not intended to limit the scope of the present application in any way, but rather to provide one example of many embodiments. In fact, the methods, systems, and apparatus disclosed herein may be implemented in local and distributed forms consistent with computing technology.

[0146] Note that some of the system functions described in this specification are presented as modules to more specifically emphasize their implementation independence. For example, a module may be implemented as a hardware circuit that includes off-the-shelf semiconductors such as custom very large scale integration (VLSI) circuits or gate arrays, logic chips, transistors, or other discrete components. A module may also be implemented in a programmable hardware device such as a field programmable gate array, programmable array logic, programmable logic device, graphics processing unit, and the like.

[0147] A module may also be implemented at least partially in software for execution by various types of processors. For example, an identified unit of executable code may have one or more physical or logical blocks of computer instructions that can be organized, for example, as objects, procedures, or functions. Nevertheless, the executable files of the identified module need not be physically located together but may have heterogeneous instructions stored in different locations, which, when logically combined, have the module and achieve the defined purpose of the module. Further, a module may be stored on a computer-readable medium that can be, for example, a hard disk drive, flash device, random access memory (RAM), tape, or any other such medium used to store data.

[0148] In fact, a module of executable code can be a single instruction or many instructions, and can even be distributed across several different code segments, between different programs, and across several memory devices. Similarly, the operating data may be identified and shown within a module herein, embodied in any suitable form, and organized within any suitable type of data structure. The operating data may be collected as a single data set, or may be distributed across different locations including different storage devices, and may exist at least partially only as electronic signals on a system or network.

[0149] It will be readily understood that the components of the present application, generally described and illustrated herein, can be arranged and designed in a wide variety of different configurations. Therefore, the detailed description of the embodiments is not intended to limit the scope of the present application as claimed, but merely to represent selected embodiments of the present application.

[0150] Those skilled in the art will readily understand that the above can be practiced at different stages of the order and / or with hardware elements of a different configuration than those disclosed. Thus, although the present application has been described based on these preferred embodiments, it will be apparent to those skilled in the art that certain modifications, variations, and alternative configurations are apparent.

[0151] Preferred embodiments of the present application have been described, but the described embodiments are merely illustrative, and it should be understood that the scope of the present application should be defined only by the appended claims when considering the full scope of equivalents and modifications to the embodiments (e.g., protocols, hardware devices, software platforms, etc.).

Claims

1. encrypt the private key using a cryptographic key, generate a plurality of keys based on the cryptographic key, convert the plurality of keys into a plurality of key shares based on a secret input value, store the encrypted private key on a blockchain a processor configured as such; and a network interface configured to distribute the plurality of key shares to a plurality of blockchain peers of the blockchain, wherein the processor transmits different key shares from among the plurality of key shares to each blockchain peer among the plurality of blockchain peers An apparatus comprising.

2. The plurality of keys include a plurality of pseudo-random values, and the processor is configured to register the plurality of pseudo-random values with the plurality of blockchain peers respectively. The apparatus according to claim 1.

3. The processor is configured to receive a key from among the plurality of keys and the secret input value, and execute an Oblivious Pseudo-Random Function (OPRF) that outputs a key share for each of the keys. The apparatus according to claim 1 or 2.

4. The processor is configured to repeatedly execute the OPRF for each key among the plurality of keys based on the secret input value to output each key share among the plurality of key shares. The apparatus according to claim 3.

5. The secret input value includes a password. The apparatus according to claim 3 or 4.

6. The processor is configured to obtain the plurality of key shares from the plurality of blockchain peers, and convert the plurality of key shares back to the plurality of keys based on the secret input value. The apparatus according to any one of claims 1 to 5.

7. The processor is further configured to restore the cryptographic key from the plurality of keys, and decrypt a fee transaction stored by the plurality of blockchain peers based on the restored cryptographic key. The apparatus according to claim 6.

8. The processor is further configured to send the decoded fee transaction to a blockchain peer from among the plurality of blockchain peers, receive the encrypted private key from the blockchain peer in exchange for the decoded fee transaction, and decrypt the encrypted private key based on the restored encryption key. The apparatus according to claim 7.

9. A computer system encrypting a private key using an encryption key; A computer system generating a plurality of keys based on the encryption key and converting the plurality of keys into a plurality of key shares based on a secret input value; A computer system storing the encrypted private key on a blockchain; and A computer system dispersing the plurality of key shares to a plurality of blockchain peers of the blockchain, where the dispersing step includes sending different key shares from among the plurality of key shares to each blockchain peer among the plurality of blockchain peers A method comprising.

10. The plurality of keys includes a plurality of pseudo-random values, and the method further includes a computer system registering the plurality of pseudo-random values with the plurality of blockchain peers respectively. The method according to claim 9.

11. The converting step includes receiving a key from among the plurality of keys and the secret input value and executing an Oblivious Pseudo-Random Function (OPRF) that outputs a key share for each of the keys. The method according to claim 9 or 10.

12. The converting step further includes repeatedly executing the OPRF for each key among the plurality of keys based on the secret input value to output each key share among the plurality of key shares. The method according to claim 11.

13. The secret input value includes a password. The method according to claim 11 or 12.

14. The method further includes a computer system obtaining the plurality of key shares from the plurality of blockchain peers and converting the plurality of key shares back to the plurality of keys based on the secret input value. The method according to any one of claims 9 to 13.

15. The method according to claim 14, further comprising the computer system restoring the encryption key from the plurality of keys and decrypting the fee transaction stored by the plurality of blockchain peers based on the restored encryption key.

16. The method according to claim 15, further comprising the computer system sending the decrypted fee transaction to a blockchain peer from among the plurality of blockchain peers, receiving the encrypted private key from the blockchain peer in exchange for the decrypted fee transaction, and decrypting the encrypted private key based on the restored encryption key.

17. To a processor: A procedure for encrypting a private key using an encryption key; A procedure for generating a plurality of keys based on the encryption key and converting the plurality of keys into a plurality of key shares based on a secret input value; A procedure for storing the encrypted private key on a blockchain; and A procedure for distributing the plurality of key shares to a plurality of blockchain peers of the blockchain, wherein the distributing procedure has a procedure for sending different key shares from among the plurality of key shares to each blockchain peer among the plurality of blockchain peers A computer program for causing the execution.

18. The computer program according to claim 17, wherein the converting procedure has a procedure for receiving a key from among the plurality of keys and the secret input value and executing an oblivious pseudorandom function (OPRF) that outputs a key share for each of the keys.

Images