Cryptographic methods and systems for secure extraction of data from a blockchain

Abstract

The present invention relates to a computer-implemented method, a computer device and a computer-readable storage medium for securely extracting data from a blockchain. The method comprises the steps of: associating one or more elements of a structure with an encryption sub-key derived from another encryption key, wherein the structure is formed by elements within a hierarchical entity having a plurality of elements organized or associated in a hierarchical relationship; extracting or copying data from a blockchain transaction (Tx) comprising or involving the encryption sub-key associated with the one or more elements; and sending the extracted data to a non-blockchain-based computer system associated with the hierarchical entity.

Description

[0001] This application is a divisional application of Chinese patent application No. 2017800093987 (corresponding to PCT international application No. PCT / IB2017 / 050979), filed on February 21, 2017, entitled "Cryptographic method and system for securely extracting data from a blockchain". Technical Field

[0002] This invention generally relates to cryptographic techniques for the secure processing, transmission, and exchange of data. It also relates to peer-to-peer distributed ledgers and related technologies. More specifically, this invention relates to control solutions for the identification, protection, retrieval, transmission, and updating of data in a cryptographically controlled and secure manner. Furthermore, this invention relates to system interoperability and the ability to transfer data between different and dissimilar computing systems. Background Technology

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based decentralized distributed system composed of blocks, which in turn consist of transactions. Each transaction is a data structure that encodes the transfer of control over digital assets between participants in the blockchain system and includes at least one input and at least one output. Each block contains the hash of the previous block to link these blockchains together, creating a permanent, immutable record of all transactions written into the blockchain since its inception. Transactions contain small programs called scripts embedded in their inputs and outputs, specifying how and by whom the transaction's outputs are accessed. On some platforms, these scripts are written using stack-based scripting languages.

[0004] For a transaction to be written to the blockchain, it must be "verified." Network nodes work to ensure that every transaction is valid, and invalid transactions are rejected from entering the network. Software clients installed on nodes perform this verification work for unspent transactions (UTXOs) by executing their locking and unlocking scripts. If the execution of the locking and unlocking scripts evaluates to TRUE, the transaction is valid and written to the blockchain. Therefore, for a transaction to be written to the blockchain, it must i) be verified by the first node that receives the transaction—if the transaction is verified, that node will relay it to other nodes in the network; ii) be added to a newly constructed block; and iii) be added to the public ledger of past transactions.

[0005] Digital entrepreneurs have begun exploring the use of cryptographic security systems and data stored on blockchains to create new systems. Blockchain could be highly advantageous if it can be used to automate tasks and processes. Such solutions would diversify the applications of blockchain while leveraging its benefits (e.g., permanent, tamper-proof event logging, distributed processing, etc.).

[0006] One area of ​​current research is implementing "smart contracts" using blockchain. These contracts are computer programs designed to automatically execute machine-readable contract or agreement terms. Unlike traditional contracts written in natural language, smart contracts are machine-executable programs that include rules that process input to produce results, and then perform actions based on those results.

[0007] In this invention, these technologies are used in a novel and advantageous configuration that allows the transfer of data and assets between different computer systems, one of which is blockchain. Computer systems used within large organizations or entities are typically very large, complex, and technologically diverse. Data security is often paramount. Access to and use of data stored in the system must be efficient and cost-effective. Overcoming at least some of the technical difficulties arising from using complex computing systems in large organizations, which are often inherently hierarchical, is necessary.

[0008] In this document, we use a financial account environment to illustrate one possible use or application of the invention. However, it is important to note that this example is for illustrative purposes only, and the invention is not limited thereto. Rather, the invention provides a general, cryptographically implemented, blockchain-based solution for any type of non-blockchain-implemented computing system associated with an organization.

[0009] Regarding our illustrative use, an entity's general ledger is a set of accounts that summarizes all financial transactions occurring within the entity. The structure of this set of accounts is typically maintained by the individual entity itself and may include accounts reported in business financial statements, such as cash, accounts payable, expense accounts, and purchases and loans. In some cases, the general ledger may be subdivided into multiple sub-ledgers. In such cases, each sub-ledger within the general ledger may maintain a separate or dynamic balance of financial positions based on the monetary exchanges of each account the entity needs to track.

[0010] An entity's account setup can be relatively complex, with hundreds or thousands of individual reporting points, such as business units, departments, products, etc. For example, parallel ledgers may be necessary: ​​one by product line and one by department.

[0011] Large entities can build complex financial systems based on large database structures to manage the accounts in the general ledger. For example, a financial system may need to manage and synchronize various databases so that the captured data can be reported accurately.

[0012] In this article, we use the term "blockchain" to encompass all forms of computer-based distributed electronic ledgers. These include, but are not limited to, peer-to-peer, consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and their variations. Summary of the Invention

[0013] The present invention is defined in the appended claims.

[0014] This invention can provide a cryptographic method and a corresponding system. This invention can provide a method / system for implementing blockchain. This invention can provide a control system for securely identifying, extracting, transmitting, processing, and / or updating data. This invention can provide a method / system for integrating blockchain with non-blockchain implemented computing (e.g., data storage / processing) resources using cryptographic keys. This invention can provide a method / system for extracting data from a blockchain and / or integrating data originating from that blockchain into non-blockchain implemented storage resources using cryptographic keys. This invention can provide a computer-implemented method for generating records of interest to an entity of interest in a (first) structure on or from a peer-to-peer distributed ledger (i.e., blockchain). This entity may be referred to as an organization, system, or network.

[0015] This invention offers significant advantages over existing technologies, particularly because it allows for secure data processing while maintaining data integrity through the use of novel cryptographic techniques. The invention also enables data communication and exchange between independent computer systems implemented on different designs, architectures, systems, and protocols. Therefore, this invention provides system interoperability. This invention allows the use of cryptographic keys as an facilitator or interface between existing computer systems and blockchains without requiring any modifications to any protocol or architecture. This invention provides enhanced data processing performance and efficiency because it facilitates the management and synchronization of potentially large and complex systems, such as databases.

[0016] An entity can consist of multiple elements, such as system components, accounts, data records, or network entities. The entity can be a hierarchical entity, comprising multiple elements organized or related in a hierarchical relationship. The elements within an entity can form a structure. This can be a hierarchical structure. This structure can include chains or tree-like hierarchies, defining or reflecting the relationships or associations between elements within the entity. Elements in the structure can be linked to sub-entities, units, or other associations within the entity.

[0017] Entities and / or one or more elements within a structure can be associated with corresponding cryptographic keys. Keys can form part of a public / private key pair. One key or key pair can be designated as the "root" key / pair. Other elements in the structure can be associated with subkeys or pairs derived from the root. Subkeys can be generated in a deterministic manner. Subkeys can be generated or determined as substantially described in the section titled "Subkey Generation Methods" below. Subkeys can be generated, derived, or determined based on another (previous) key. Subkey generation can include the use of elliptic curve cryptosystem (ECC) techniques. Subkeys can be generated, derived, or determined using a deterministic key (DK) based on a message (M) cryptographic hash. The message can be random, pseudo-random, predefined, or selected. In a preferred embodiment, a message is selected, arranged, or created to correspond to a meaningful value, such as an account number. The message can have some meaning related to an entity or sub-entity / element. The message can provide a link, association, or reference to an entity or element. A subkey can be determined based on a scalar addition of a scalar multiplication of the associated public parent key with a deterministic key and a generator (G). This message can be stored within a blockchain transaction (Tx) or as metadata within a blockchain transaction (Tx). The message can be rehashed to provide another subkey.

[0018] This invention may include the following steps:

[0019] Associate one or more elements of the structure with a cryptographic subkey derived from another cryptographic key;

[0020] Extracting data from a blockchain transaction (Tx) including the subkey of an element or data about the subkey of an element; and

[0021] The extracted data is sent to a non-blockchain-based computer system. This non-blockchain-based computer system may not be part of the blockchain.

[0022] The method may include steps of scanning, traversing, and / or analyzing a blockchain to identify one or more blockchain transactions (TX) that contain data relating to or including the cryptographic subkeys of elements.

[0023] The method may also include the step of processing the extracted data to generate output. In one embodiment, the output may be a result, calculation, report, decision, or record, such as a financial account record. The method may include the step of transmitting the output to a destination via a network.

[0024] Additionally or alternatively, the present invention may include the following steps:

[0025] Identify a first structure public key set, which includes at least one public root key and one or more associated public subkeys associated with the first structure;

[0026] Derive a deterministic association between at least one public root key and one or more related public subkeys;

[0027] Extracting (copying) transaction data / information from multiple blockchain transactions in a peer-to-peer (P2P) distributed ledger (blockchain), the extracted data includes at least:

[0028] Data indicating transactions between a first structure and at least one other structure; and

[0029] The public key of the first structure associated with the first structure,

[0030] The first structure public key is part of an encryption pair, which includes the first structure public key and the first structure private key; and

[0031] By using deterministic association to match the first structure public key set with the extracted transaction data, the output of the first structure of interest (e.g., financial account records) is generated.

[0032] A transaction between the first structure and at least one other structure may involve the transfer of assets from one party to the other. The assets may be some form of digital asset. The transaction may transfer ownership and / or control of the assets from one party to the other.

[0033] The first structure can represent a defined group of items, such as components within an entity. Items can be physical or logical, such as accounts. For example, the first structure can be associated with the first business unit, such as the first group of users, departments, or teams; the first product or service of an entity; or the entire entity.

[0034] At least one other structure may be within the entity. For example, at least one other structure may be associated with a second business unit or a second product or service.

[0035] Alternatively, at least one other structure may be within another entity. For example, at least one other structure may be associated with a business unit of another entity, a product or service of another entity, or the entirety of another entity.

[0036] The first structured public key set may include at least one public root key and all associated public subkeys.

[0037] The steps of deriving a deterministic association between at least one public root key and one or more associated public subkeys may include: determining rules for the public subkeys used to determine the associated parent key. For example, the rules for determining the subkeys may include determining a hash of a message to create a seed value.

[0038] A deterministic association between at least one public root key and one or more related public subkeys can be a tree hierarchy. Alternatively, the deterministic association can be a chain hierarchy.

[0039] Each public subkey can represent a virtual, physical, or logical item within an entity (e.g., an account).

[0040] The steps for identifying the first structured public key set may include: identifying at least one root key and determining one or more subkeys based on the at least one root key. At least one root key can be identified by obtaining data from an internal database such as an account chart.

[0041] The steps of extracting transaction data from multiple transactions in a blockchain may further include: extracting or copying one or more of the following data items from the multiple transactions:

[0042] Transaction input values;

[0043] Transaction output value;

[0044] Rules used to derive transaction input or output values ​​based on data indicating the transaction;

[0045] The timestamp of the transaction; and

[0046] The block number of a block in a blockchain.

[0047] Transactions between the first structure and another structure can involve currency transactions, contract exchanges, and transactions of goods or services.

[0048] The steps for extracting transaction information from multiple transaction records in a P2P distributed ledger may include: identifying previously unextracted transaction records to generate financial account records. In one example, the method may include identifying the block number of a block in the P2P distributed ledger and comparing that block number with a previously generated financial account record.

[0049] This method may include the step of publishing the output to a computer-based resource. This can be any type of computer-based system, such as a database system or a financial ledger. It can be internal to the entity, as it can be arranged and configured to store data relating to the entity and / or its sub-entities. The computer-based resource can be the entity's general ledger. Alternatively, a financial ledger can be a sub-ledger of the entity's general ledger. As mentioned above, an entity's general ledger typically represents a set of accounts that summarize all financial transactions occurring within the entity.

[0050] The step of publishing the generated output to computer-based resources can be automated. In other words, it can be an automatic, computer-executed process without manual intervention.

[0051] The step of publishing the generated output can be performed periodically. This can be done after a predetermined time period or at a specified time.

[0052] The steps of publishing the generated output may include writing the generated output to one or more locations or files. These may be referred to as, for example, publication files. One or more publication files can have any suitable format, such as JSON, XML, or XBRL. One or more publication files may be encrypted. For example, one or more publication files may be hashed. In another example, one or more publication files may be encrypted using a computed secret. An example of computed secrets is described in further detail in the section below titled “Subkey Generation Methods.”

[0053] The method may include the step of signing one or more published files using a first structure private key, wherein the first structure private key is part of an asymmetric cryptographic pair comprising a first structure private key and an associated first structure public key. In this way, one or more published files can be verified using the first structure public key associated with the first structure private key used to sign one or more published files.

[0054] This method may include the step of storing the generated output. In one specific example, the generated output may be recorded in an entity's internal database, or located on other storage facilities within or subordinate to the entity. In an alternative example, the generated output may be stored on a public database, which may be centralized or distributed, such as a distributed hash table. In a specific example, the generated output may be stored on a blockchain in the form of a transaction (Tx). For example, the generated output may be recorded as metadata of a blockchain transaction (Tx). The hash value of the transaction can be signed using the private key of the first structure of interest.

[0055] The method may include the step of encrypting the generated output to store the data in a database or blockchain.

[0056] The method may include steps of hashing and / or signing the generated output to store the generated output on a database, storage facility, or blockchain.

[0057] This method may include steps of analyzing the generated output. In one example, the method may include steps of determining the cash flows of a first structure of interest. In another example, the method may include steps of determining the assets and / or liabilities of the first structure of interest.

[0058] The steps of publishing the generated financial account records may include making the generated financial account records available to a dedicated account system. This account system may be configured to execute the entity's dedicated account software.

[0059] According to embodiments of the present invention, a computer system is provided for implementing any embodiment of the method of the present invention. The system can be used to generate a record of a first structure of interest for an entity on a blockchain, comprising:

[0060] Processing equipment, for

[0061] Identify a first structure public key set, which includes at least one public root key and one or more associated public subkeys associated with the first structure; and

[0062] Derive a deterministic association between at least one public root key and one or more related public subkeys;

[0063] A network interface for extracting transaction information from multiple transaction records in a peer-to-peer (P2P) distributed ledger, the extracted information including at least:

[0064] Information indicating transactions between a first structure and at least one other structure; and

[0065] A first structure public key associated with the first structure, wherein the first structure public key is part of a cryptographic pair including a first structure public key and a first structure private key;

[0066] The processing device is also used to match the first structure public key set with the extracted transaction information by using deterministic association to generate financial account records of the first structure of interest.

[0067] A computer program comprising machine-readable instructions to cause a processing device to implement any of the methods described above. Attached Figure Description

[0068] Embodiments of the invention will now be described by way of non-limiting example only with reference to the accompanying drawings, wherein:

[0069] Figure 1 This is a schematic diagram of an example system for generating financial account records;

[0070] Figure 2 This is an optional schematic diagram of an illustrative computer system used to generate financial account records;

[0071] Figure 3 This is a flowchart illustrating a computer-implemented method for determining account configurations to generate financial account records;

[0072] Figure 4 This is a diagram illustrating the deterministic association between the root public key and one or more public subkeys;

[0073] Figure 5 This is a flowchart illustrating a computer-implemented method for extracting information from a peer-to-peer distributed ledger (blockchain) to generate financial account records; and

[0074] Figure 6 This is a flowchart illustrating a computer-implemented method for publishing generated financial account records to a financial account ledger.

[0075] Figures 7 to 13 Illustrative techniques for deriving child keys from parent keys are shown below, and these techniques are applicable to uses related to various aspects of the present invention. Detailed Implementation

[0076] Overview

[0077] This invention generally relates to methods and systems using peer-to-peer (P2P) distributed ledgers (hereinafter referred to as "blockchain") for identifying, retrieving, transmitting, processing, and / or updating data. This invention provides a secure, cryptographically enforced solution for using blockchain-published data to enhance, add to, or integrate data within computer-based resources set up within an organization (entity). These computer-based resources can be databases, account systems, or any other type of computer-based facility used for storing and / or processing data. This system can be referred to as an "internal" system because it is internal to the organization and not part of the blockchain.

[0078] This invention provides a solution for data control and security by assigning cryptographic keys to elements associated with an entity or sub-entity. The elements are organized into a (linear or tree) structure defined or specified by relationships between them. Each element in the structure is associated with a cryptographic public / private key pair, with a root key pair at the top. Lower elements in the structure are deterministically associated with key pairs derived from previous key pairs. This deterministic derivation can, preferably, be performed according to a method substantially described in the section titled "Subkey Generation Method" below. Thus, a hierarchical structure of cryptographic key pairs is generated to reflect the hierarchical relationships between elements within an entity. In the following description, the term "account" may be used instead of "element".

[0079] For purely illustrative purposes, and without intending to limit the nature of the invention to this use or field of application, an example is now provided in which the invention is used to generate financial account records of an entity with an interesting structure. It is worth noting that this financial-oriented aspect is not essential to the invention, and that the invention can be used in conjunction with any type of internal computer-based system and for the control, transmission, and security of any type of data.

[0080] In our example, the structure of interest can be, for example, a business unit, such as a department or sub-entity within an entity, or it can represent the entire entity for which outputs (e.g., account records) are to be generated. Alternatively, the structure of interest can relate to the products or services of interest of the entity for which financial account records are to be generated, or any suitable structure, and may optionally be published to, for example, the entity's general ledger.

[0081] Embodiments of the present invention offer significant advantages. For example, utilizing a public blockchain for generating financial transaction records is advantageous because blockchains are inherently decentralized. This means that transaction records on the blockchain are stored synchronously across the network, ensuring the distribution and publication of all information.

[0082] Furthermore, the financial account records generated from the desired structure can be recorded on the same blockchain, for example, as metadata within transaction records. This provides the advantage of creating a permanent, immutable public record that is a true and accurate reflection of the entity's activities. This could ultimately eliminate the need for external assistance such as auditors.

[0083] Now for reference Figure 1 , Figure 1 A computer system 10 for generating account records according to an illustrative embodiment of the present invention is shown. Financial account records may be published, for example, to a financial account ledger, such as an entity's general ledger.

[0084] In this example, the computer system includes: a processor 12 for controlling and coordinating operations; a memory 14; and a network interface 16, which communicate with each other via a bus 18. The network interface 16 facilitates wireless communication between the computer system 10 and a P2P distributed ledger, such as a blockchain 20, via a communication network, in this example, the Internet 22.

[0085] Memory 14 stores instructions 24 and data 26 for the process described below, and processor 12 executes the instructions 24 in memory 14 to perform the processing. It should be noted that although computer system 10 is represented as a separate network element, computer system 10 may alternatively be part of another network element, and the functions performed by computer system 10 may be distributed among multiple network elements. Computer system 10 may represent the computer system of a first entity.

[0086] Figure 1 Another computer system 28 of the second entity is also shown. This is for illustrative purposes only, and it should be understood that other computer systems or entities may be part of the network.

[0087] Financial account ledger of the entity / general ledger

[0088] As described above, the general ledger is a set of accounts that summarizes all financial transactions that occur within an entity. It typically serves as the entity's primary financial record and contains all financial transactions (accounts) related to the entity. These can include asset accounts (e.g., cash and cash equivalents, securities, accounts receivable, inventory, and intellectual property) and liability accounts (e.g., notes payable, accounts payable, expense accounts, and loans). The examples of accounts described above are merely illustrative and should not be considered restrictive. Each account in the general ledger is traditionally balanced according to the monetary exchange for each account to maintain the entity's financial position.

[0089] While both small and large entities need to keep records of their accounts through a general ledger, larger entities may need to track thousands or even hundreds of thousands of accounts. This tracking can become a massive and potentially complex task. Maintaining a very large general ledger can take days to audit or balance, which presents several challenges.

[0090] In addition, some organizations may consider introducing sub-ledgers into the general ledger to simplify its complexity.

[0091] The general ledger can be an object of internal and external auditing for an entity. Auditing is typically a tedious and time-consuming task performed by specially designated auditors. However, by recording the general ledger or one or more sub-ledgers on a publicly visible blockchain, it is possible to facilitate and alleviate the auditor's task.

[0092] In the following text, the term "financial account ledger" may refer to an entity's general ledger or one or more sub-ledgers within the general ledger. However, the invention is not limited to financial or accounting systems and may be used with any other type of computer-based system.

[0093] Blockchain

[0094] It should be understood that this invention can be implemented using any blockchain.

[0095] A blockchain is a public ledger of transactions distributed across network nodes participating in the system. Each transaction is broadcast to the network, confirmed, and then aggregated into blocks. These blocks are then included in the blockchain.

[0096] A complete copy of the blockchain contains every transaction (Tx) published to the ledger since the blockchain's inception. This provides a constantly growing list of transaction records. Because every transaction input into the blockchain is cryptographically enforced, the blockchain is also strengthened to prevent tampering and modification; even the operators on the data storage nodes cannot be altered.

[0097] Due to the transparency of blockchain, the transaction history of each transaction is publicly available. Another advantage of blockchain is that transactions and transaction records are identical; that is, transaction records are embedded within transactions.

[0098] In this way, information related to data exchange is captured within the actual transaction (Tx). This record is permanent and immutable, so each transaction is not only facilitated by the blockchain but also immutably recorded within it. Therefore, this eliminates the need for third parties to store transaction records on a separate database.

[0099] In embodiments of the invention, in addition to the design features for storing transaction records, blockchain is used in novel ways to generate data of interest to entities or organizations, such as business units or products of interest. The data can be used in any foreseeable manner, for example, to generate account records. For simplicity, but not limited thereto, the term "account record" will be used hereinafter in a description. In this example, the generated account records are suitable for publication in the entity's general ledger or for provision to the entity's dedicated account system.

[0100] While the exemplary embodiments described below refer to the blockchain as a public ledger, it should be understood that this disclosure also applies to any blockchain platform or protocol.

[0101] Functional components of a computer system

[0102] Figure 2An exemplary implementation representation of a computer system 40 is given, wherein functional components of the computer system 40 are shown instead of hardware components. It can be used... Figure 1 The hardware components of the computer system 10 shown implement the functional components in this example, thereby providing a network interface for accessing the blockchain.

[0103] In this example, computer system 40 includes a control unit 42 for controlling and coordinating the operation of components of computer system 40. This control unit 42 may, for example, be composed of… Figure 1 The processor 12 shown is implemented.

[0104] In addition, the computer system 40 has a network interface 44 for facilitating access to information stored on the blockchain 20 via the Internet 22.

[0105] Computer system 40 also includes a database management system (“DBMS”) 50, which stores data received and / or generated in computer system 40 in data storage 52. It is understood that the data may alternatively be stored in a remote database, such as in cloud storage, and may be received at computer system 40 via network interface 44 through Internet 22.

[0106] Data storage 52 includes storage for storing account configuration data 54 of the first entity. For example, account configuration data 54 may include an account chart that collects account names and identifiers for each account. This may further include, as referenced... Figure 4 Further detailed information about the public root key.

[0107] The stored account configuration data 54 can be accessed by the account configuration determiner 56 of the computer system 40.

[0108] The data storage 52 also includes a memory for storing publication files 58 created by the publication component 60 of the computer system 40. For example, generated financial account records can be written to one or more publication files that can be stored in the data storage 52.

[0109] The computer system 40 also includes a transaction information collector 62, which communicates with the network interface 44 to obtain transaction information from transaction records on the blockchain 20 via the Internet 22.

[0110] The matching component 64 of the computer system 40 communicates with the account configuration determiner 56 and the transaction information collector 62. The matching component 64 is used to match transaction information extracted from the blockchain with the identified public keys associated with the various accounts of the entity to generate financial account records.

[0111] As described above, these generated financial account records can then be written to one or more publication files and published to the entity's general ledger 66 in data storage 52.

[0112] Overview of example methods for generating financial account records

[0113] The method for generating financial account records is divided into four main steps: determining account configuration (step 100), extracting transaction information from transaction records on the blockchain (step 200), generating financial account records and creating one or more publication files (step 300), and publishing one or more publication files to the entity's general ledger (step 400).

[0114] The first structure of interest can be any suitable structure for the first entity for which account records are to be generated. For example, the first structure could refer to the entire first entity, and the generated account records would be published to the first entity's general ledger. In another example, the first structure of interest could represent a business unit, such as a department, team, or designated group of employees. Alternatively, the first structure of interest could refer to a first product or service that may span multiple business units. In this way, generated account records can be created to analyze accounts associated with the desired product or service.

[0115] Account Configuration

[0116] Now for reference Figure 3 and Figure 4 It shows a flowchart of method step 100 for determining account configuration, and a schematic diagram of some method steps of method 100.

[0117] Specifically, method 100 may include the step of identifying a first entity public key set, which includes at least one public root key associated with the first entity and one or more associated public subkeys. Each subkey may represent an account within the first entity. In this regard, the first entity public key set may initially be identified by identifying one or more accounts for which financial account records are to be generated (step 100.10).

[0118] In a further step, at least one public root key associated with the identified one or more accounts is identified (step 100.20). This can be accomplished by accessing data stored on the internal data storage of the first entity, for example... Figure 2 The data storage 54 shown is an internal data storage device that can store an account table containing the account name and identifier for each account. The identifier may include the associated public root key. In a manner similar to... Figure 3 In the example shown, method 100 identifies three public root keys, which can represent accounts from three different business units.

[0119] Method 100 further includes step 100.30 of determining a deterministic association between the identified public root key and one or more public subkeys. In other words, determining the rules for deriving one or more public subkeys that depend on the public root key. (In such cases...) Figure 4 In the specific example shown, deterministic associations define a tree hierarchy in which each of the three identified public root keys is associated with inherited subtree and grandchild tree nodes.

[0120] After the deterministic association is determined in step 100.30, one or more public subkeys associated with at least one root key are determined, and some subkeys are selected using information from the account ledger table in step 100.10. It should be understood that all or only some subkeys that depend on the public root key are determined based on the identifier of the ledger for which account records are to be generated.

[0121] In such Figure 4 In the specific example shown, four public subkeys are selected to generate financial account records: the first subkey of the first public root key, the first subkey and the first grandchild key of the second public root key, and the second subkey or the third root key. For example, the four public subkeys can be associated with specific products or services across three different business units represented by the root keys.

[0122] In a concrete example, a series of inherited deterministic public keys can be determined, where each inherited public key can be determined based on a previous public key. Elliptic curve cryptography (ECC) can be used, for example. In this regard, a subkey can be determined by initially determining a deterministic key (DK) based on a cryptographic hash of a message (M), which can be random, pseudo-random, or predefined. The subkey can then be determined based on a scalar addition of the associated public parent key and a scalar multiplication of the deterministic key (DK) and a generator (G). To re-determine the deterministic key (DK) and thus the subkey, only the message (M) and the generator (G) are needed. In this regard, the message (M) can be stored in the form of metadata of transaction records on the blockchain, such as in the form of a billing number.

[0123] In another example, the message can be rehashed to determine the next generation public subkey.

[0124] The steps for determining the inherited public key, which have been briefly described above, will be further described and explained in detail in the section below entitled "Subkey Generation Method".

[0125] In a further step 100.40, one or more rules are determined to obtain the information to be included in the financial account records for the selected public key. In other words, method step 100.40 determines what information is needed to generate account records for the general ledger and how to obtain that information.

[0126] Specifically, this information may include:

[0127] Transaction inputs / outputs;

[0128] It can be published to its general ledger account;

[0129] It can be reverse-published to its general ledger account;

[0130] Rules used to calculate the value of a transaction;

[0131] Rules used to derive transaction descriptions.

[0132] Extracting information from the blockchain

[0133] Now for reference Figure 5 , Figure 5 A flowchart of method 200, which includes method steps for extracting information from a block chain, is shown.

[0134] First, method 200 includes step 200.10 of identifying one or more blocks of the blockchain to extract transaction information from multiple transactions recorded on the blockchain. For example, step 200.10 of identifying one or more blocks may include identifying a first block number associated with a block containing transaction records that were not previously used to generate financial account records. This can be done by identifying the relevant block number of the block that is part of each transaction record on the blockchain. Alternatively, one or more blocks may be identified based on transaction date or time. As mentioned above, blocks on a blockchain have a defined order, and each block includes a hash of the previous block.

[0135] Once one or more blocks are identified, multiple transaction records associated with the entity's first structure are scanned on the blockchain (step 200.20) to match them with the subkeys identified in step 100.30.

[0136] In a further step 200.30, the rules determined in step 100.40 are run to extract transaction information from the transaction records of each matching blockchain. Therefore, it is determined what information needs to be extracted, how to derive certain information from the extracted information, and where / how to publish the information to the general ledger.

[0137] For example, extract one or more of the following information from multiple transaction records:

[0138] Transaction input values;

[0139] Transaction output value;

[0140] Public key;

[0141] Metadata;

[0142] Rules used to derive transaction input or output values ​​based on information indicating the transaction;

[0143] The timestamp of the transaction; and

[0144] The block number of a block in a P2P distributed ledger.

[0145] Once the transaction records within a block have been scanned and processed, the next block in the blockchain will be scanned to look for transaction records associated with the first entity.

[0146] Subsequently, the extracted information from step 200.30 is used to generate financial account records (step 200.40).

[0147] Transaction records

[0148] The following text will consider transaction records stored on the blockchain in more detail.

[0149] Each transaction record on the blockchain includes at least one first-structure public key associated with the first structure. This indicates that the entity's first structure is involved in transactions stored on the blockchain.

[0150] Furthermore, each transaction (Tx) on the blockchain includes at least information indicating a transaction between a first entity and another entity. It should be noted that entities of any type can exchange and store information between the first entity and another entity within a transaction.

[0151] Examples of transactions can include fiat currency transactions, contracts, and any type of goods and services.

[0152] Release document

[0153] Now for reference Figure 6 , Figure 6 A flowchart illustrating the method steps of method 300 for creating one or more publication files is shown.

[0154] Method 300 includes step 300.10 of writing the account records generated in step 200.40 to one or more publication files. This may include merging specified information for the purpose of publishing the accounts to the general ledger. For example, the generated account records may be merged by date, or each account record may represent a single file.

[0155] One or more publication files can have any suitable format, such as, but not limited to, JSON, XML, or XBRL. The format can be predefined by the ledger.

[0156] Method 300 may also include hashing one or more publication files (step 300.20). For example, the cryptographic hash algorithm may include SHA-256 to create a 256-bit publication file hash.

[0157] Method 300 may also include step 300.30 of signing the hash of the published file. For example, the hash of the published file can be signed with a private key, which is part of an asymmetric cryptographic pair having a private key and an associated public key. In this way, the signed hash of the published file can be verified using the associated public key.

[0158] After step 300.20, which hashes one or more published files, the hash is stored on the blockchain as permanent and immutable evidence (step 300.40). For example, the hash of the published files can be stored as metadata of a transaction record. As described above with reference to P2SH, the published files can be stored as a "fake" public key within a script.

[0159] In a specific example, a proxy application can be used to record the hash value and block number range of a published file on the blockchain as a contract transaction.

[0160] Publish to general ledger

[0161] The method steps of method 400, which publishes one or more publication files to the general ledger of the first entity, will be described below.

[0162] As described above, the general ledger is a set of accounts that summarizes all transactions occurring within an entity. Method 400 for publishing one or more publication files to the general ledger may include securely accessing one or more publication files and verifying that one or more publication files originate from an accredited source. In this regard, method 400 may include obtaining a public key associated with the private signing key used in step 300.30 to verify the signature.

[0163] Once one or more release files have been successfully verified, those release files are applied to the general ledger.

[0164] Dedicated account system

[0165] In one example, financial account records are generated so that these records can be fed back into the entity's dedicated account system. For instance, the entity's account system could be used to execute the entity's dedicated account software.

[0166] It should be understood that a transaction may only form part of a physical trading position. In this case, financial account records generated using transaction records on the blockchain can be incorporated into the existing account model.

[0167] Subkey generation method

[0168] According to the present invention, it is necessary to generate subkeys from the original (master) key. A method for achieving this is now provided, illustrating one way in which this can be done. The following provides illustrative uses of the techniques applicable to or suited to the present invention. References Figures 7 to 13 The following description is provided.

[0169] Figure 7 System 1 is shown, which includes a first node 3 communicating with a second node 7 via a communication network 5. The first node 3 has an associated first processing device 23, and the second node 5 has an associated second processing device 27. The first node 3 and the second node 7 may include electronic devices such as computers, telephones, tablet computers, mobile communication devices, computer servers, etc. In one example, the first node 3 may be a client (user) device, and the second node 7 may be a server.

[0170] First node 3 and possessing the first node's master private key (V) 1C ) and the first node's master public key (P 1C The first asymmetric key pair is associated with the second node (7). The second node (7) is associated with the second node's master private key (V). 1S ) and the second node master public key (P 1S The first and second nodes are associated with a second asymmetric key pair. In other words, the first and second nodes each possess their own public-private key pair.

[0171] First and second asymmetric cryptographic pairs can be generated during the registration process for the corresponding first and second nodes 3 and 7, such as in wallet registration. The public key of each node can be publicly shared, for example, through a communication network 5.

[0172] In order to determine the public key (CS) at the first node 3 and the second node 7, nodes 3 and 7 execute the steps of methods 300 and 400 without transmitting the private key through the communication network 5.

[0173] Method 300 executed by the first node 3 includes step 330, based on at least the first node's master private key (V 1C The generator value (GV) and the first node's second private key (V) are determined by the generator value (GV). 2CThe generator value can be based on a message (M) shared between the first and second nodes, which may include sharing messages via communication network 5, as described in further detail below. Method 300 also includes step 370, based at least on the second node's master public key (P). 1S The second node's second public key (P) is determined by the generator value (GV) and the generator value (P). 2S Method 300 includes step 380, based on the first node's second private key (V). 2C ) and the second public key of the second node (P 2S Determine the public key (CS).

[0174] Importantly, the same public key (CS) can also be determined at the second node 7 via method 400. Method 400 includes step 430, based on the first node's master public key (P... 1C The first node's second public key (P) is determined by the generator value (GV) and the generator value (P). 2C Method 400 also includes step 470, based on the second node's master private key (V). 1S The second node's second private key (V) is determined by the generator value (GV) and the generator value (GV). 2S Method 400 includes step 480, based on the second node's second private key (V). 2S ) and the first node's second public key (P 2C Determine the public key (CS).

[0175] Communication network 5 may include local area networks (LANs), wide area networks (WANs), cellular networks, wireless communication networks, the Internet, etc. In these networks, data can be transmitted via communication media such as wires, fiber optics, or wireless transmission, and the data may be easily eavesdropped on, for example, by an eavesdropper 11. Methods 300 and 400 allow the first node 3 and the second node 7 to independently determine the public secret without sending the public key through communication network 5.

[0176] Therefore, one advantage is that the public secret (CS) can be securely and independently determined by each node, without having to send the private key over a potentially insecure communication network. In turn, the public secret can be used as the secret key (or as the basis for the secret key).

[0177] Methods 300 and 400 may include additional steps. See also Figure 8 Method 300 may include: at the first node 3, based on the message (M) and the first node's second private key (V) 2C Method 300 further includes step 360, sending the first signature message (SM1) to the second node 7 via a communication network. Then, in step 440, the second node 7 can receive the first signature message (SM1). Method 400 also includes the following step: step 450, using the first node's second public key (P...2C Step 460 verifies the first signed message (SM1) and verifies the first node 3 based on the result of verifying the first signed message (SM1). Advantageously, this allows the second node 7 to authenticate that the claimed first node (where the first signed message was generated) is the first node 3. This is based on the assumption that only the first node 3 can access the first node's master private key (V 1C Therefore, only the first node 3 can determine the first node's second private key (V) used to generate the first signed message (SM1). 2C It should be understood that, similarly, a second signature message (SM2) can be generated at the second node 7 and sent to the first node 3, enabling the first node 3 to authenticate the second node 7, for example in a peer-to-peer scenario.

[0178] Message (M) sharing between the first and second nodes can be implemented in various ways. In one example, a message can be generated at the first node 3 and then sent to the second node 7 via the communication network 5. Alternatively, a message can be generated at the second node 7 and then sent to the second node 7 via the communication network 5. In some examples, the message (M) can be public and therefore can be sent via the insecure network 5. One or more messages (M) can be stored in data storage devices 13, 17, 19. Those skilled in the art will recognize that message sharing can be implemented in various ways.

[0179] Advantageously, records that allow the re-creation of public secrets (CS) can be preserved without the records themselves needing to be stored privately or transmitted securely.

[0180] Registration methods 100 and 200

[0181] Reference Figure 9 Examples of registration methods 100 and 200 are described, where method 100 is executed by a first node 3 and method 200 is executed by a second node 7. This includes establishing first and second node asymmetric cryptographic pairs for the corresponding first and second nodes 3 and 7.

[0182] An asymmetric cryptographic pair consists of an associated private key and a public key, such as the key used in public-key encryption. In this example, an asymmetric cryptographic pair is generated using elliptic curve cryptography (ECC) and the properties of elliptic curve operations.

[0183] In methods 100 and 200, this includes steps 110 and 210, where the first and second nodes reach an agreement on the common ECC system and the base point (G). (Note: The base point can be referred to as a common generator, but the term "base point" is used to avoid confusion with the generator value GV). In one example, the common ECC system may be based on secp256K1, where secp256K1 is the ECC system. The base point (G) can be selected, randomly generated, or assigned.

[0184] Regarding the first node 3, method 100 includes step 110, selecting a public ECC system and base point (G). This may include receiving the public ECC system and base point from the second node 7 or the third node 9. Alternatively, user interface 15 may be associated with the first node 3, whereby the user can selectively provide the public ECC system and / or base point (G). In yet another alternative, one or both of the public ECC system and / or base point (G) may be randomly selected by the first node 3. The first node 3 may send an instruction notification to the second node 7 via communication network 5 to indicate the use of the public ECC system with base point (G). In step 210, the second node 7 may select the public ECC system and base point (G) by sending an instruction notification confirming the use of the public ECC system and base point (G).

[0185] Method 100 further includes step 120, whereby the first node 3 generates a first asymmetric cryptographic pair, which includes the first node's master private key (V 1C ) and the first node's master public key (P 1C This includes generating the first node's master private key (V) based at least in part on a random integer within a permissible range specified in public ECC systems. 1C This also includes formulating the first node's master private key (P) according to the following formula. 1C The elliptic curve dot multiplication of the base point (G) and the base point (G) is used to determine the first node's master public key (P). 1C ):

[0186] P 1C = V 1C ×G (Formula 1).

[0187] Therefore, the first asymmetric cipher pair includes:

[0188] V 1C : The first node's master private key, which is kept secret by the first node.

[0189] P 1C : Publicly disclose the known master public key of the first node.

[0190] First node 3 can obtain the first node's master private key (V) 1C ) and the first node's master public key (P 1CThe first node's master private key (V) is stored in the first data storage 13 associated with the first node 3. For security reasons, the first node's master private key (V) is stored in the first data storage 13 associated with the first node 3. 1C The key can be stored in the secure portion of the first data storage 13 to ensure that the key remains private.

[0191] Method 100 further includes step 130, transmitting the first node's master public key (P) through communication network 5. 1C Send to the second node 7, such as Figure 9 As shown. When the second node 7 receives the first node's master public key (P1C) in step 220, it will then transfer the first node's master public key (P1C) in step 230. 1C It is stored in the second data storage 17 associated with the second node 7.

[0192] Similar to the first node 3, the method 200 of the second node 7 includes step 240, generating a second asymmetric cryptographic pair, which includes the second node's master private key (V). 1S ) and the second node master public key (P 1S Second node master private key (V) 1S ) is also a random integer within the allowed range. The second node's master public key (P) 1S It is determined by the following formula:

[0193] P 1S = V 1S ×G (Formula 2).

[0194] Therefore, the second asymmetric cipher pair includes:

[0195] V 1S : The second node's master private key, kept secret by the second node.

[0196] P 1S : Publicly disclose the known master public key of the second node.

[0197] The second node 7 can store the second asymmetric cryptographic pair in the second data storage 17. Method 200 also includes step 250, storing the second node's master public key (P... 1S The public key (P) of the second node is sent to the first node 3. In steps 140 and 150, the first node 3 can receive and store the second node's master public key (P). 1S ).

[0198] It should be understood that in some alternatives, the corresponding public master key can be received and stored in a third-party data store 19 associated with a third node 9 (such as a trusted third party). This can include a third party acting as a public directory, such as a certificate authority. Therefore, in some examples, the first node's master public key (P 1C The public key (CS) can be requested and received by the second node 7 only when it is determined that it is needed (and vice versa).

[0199] The registration process may only need to be performed once as part of the initial setup.

[0200] First node 3 initiates the session and determines the public secret.

[0201] Now refer to Figure 10 Describe an example of determining the public secret (CS). The public secret (CS) can be used for a specific session, time, transaction, or other purpose between the first node 3 and the second node 7, and using the same public secret (CS) may be undesirable or insecure. Therefore, the public secret (CS) can be changed between different sessions, times, transactions, etc.

[0202] The following content is provided to illustrate the secure transmission technologies described above.

[0203] Message generated (M) 310

[0204] In this example, method 300, executed by the first node 3, includes step 310, generating a message (M). The message (M) can be random, pseudo-random, or user-defined. In one example, the message (M) is based on a Unix time and a random number (and arbitrary values). For example, the message (M) could be:

[0205] Message (M) = UnixTime + nonce (Formula 3).

[0206] In some examples, the message (M) is arbitrary. However, it should be understood that the message (M) may have optional values ​​(e.g., account, Unix time, etc.) that may be useful in certain applications.

[0207] Method 300 includes step 315, sending a message (M) to the second node 7 via communication network 3. If the message (M) does not include information about the private key, the message (M) can be sent over an insecure network.

[0208] Determine the generator value (GV) as 320.

[0209] Method 300 also includes step 320, determining a generator value (GV) based on the message (M). In this example, this includes determining a cryptographic hash of the message. Examples of cryptographic hash algorithms include SHA-256 to create a 256-bit generator value (GV). That is:

[0210] GV = SHA-256(M) (Formula 4).

[0211] It should be understood that other hashing algorithms may be used. This can include other algorithms in the Secure Hash Algorithm (SHA) family. Some specific examples include instances in subsets of SHA-3, including SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE 128, and SHAKE256. Other hashing algorithms can include those in the RACE Integrity Primitives Evaluation Message Digest (RIPEMD) family. A specific example can be RIPEMD-160. Other hash functions can include families of hash functions based on the Zemor-Tillich hash function and knapsack-based hash functions.

[0212] Determine the second private key of the first node 330

[0213] Then, method 300 includes using the second node's master private key (V 1C The generator value (GV) and the first node's second private key (V) are determined by the generator value (GV). 2C Step 330. This can be based on the first node's master private key (V). 1C The scalar addition of the generator value (GV) and the generator value (GV) is performed according to the following formula:

[0214] V 2C = V 1C + GV (Formula 5).

[0215] Therefore, the first node's second private key (V) 2C The public key in the encryption pair is not a random value, but is deterministically derived from the first node's master private key. The corresponding public key in the encryption pair is the first node's second public key (P). 2C ), which have the following relationship:

[0216] P 2C = V 2C × G (Formula 6).

[0217] V from Formula 5 2C Substituting into formula 6, we get:

[0218] P 2C = (V 1C + GV)×G (Formula 7).

[0219] The operator "+" refers to elliptic curve point addition. Note that elliptic curve cryptography algebra satisfies the distributive law, and Equation 7 can be expressed as:

[0220] P 2C= V 1C × G + GV× G (Formula 8).

[0221] Finally, substituting Formula 1 into Formula 7, we get:

[0222] P 2C = P 1C + GV×G (Formula 9.1)

[0223] P 2C = P 1C + SHA-256(M) × G (Formula 9.2).

[0224] Therefore, given the first node's master public key (P) 1C In the case of (M) and message (M), the corresponding first node's second public key (P) can be derived. 2C The second node 7 can possess the knowledge to independently determine the second public key (P) of the first node. 2C (This will be discussed in further detail below regarding method 400.)

[0225] Generate a first signed message (SM1) based on the message and the second private key of the first node. 350

[0226] Method 300 further includes step 350 based on message (M) and the determined first node second private key (V). 2C Generate a first signed message (SM1). Generating a signed message involves applying a digital signature algorithm to digitally sign the message (M). In one example, this includes using the first node's second private key (V). 2C The first signed message (SM1) is obtained by applying the Elliptic Curve Digital Signature Algorithm (ECDSA) to a message. Examples of ECDSA include those based on the Elliptic Curve Digital Signature Algorithm for ECC systems with secp256k1, secp256r1, secp384r1, and se3cp521r1.

[0227] The second public key of the first node (P) at the second node 7 can be used. 2C The first node (SM1) can be verified using the first signature message (SM1). The second node (SM1) can be used to authenticate the first node, which will be discussed in method 400 below.

[0228] Determine the second node's second public key 370'

[0229] Then, in step 370, the first node 3 can determine the second public key (P) of the second node. 2SAs mentioned above, the second node's second public key (P) 2S It can be based at least on the second node's master public key (P) 1S The public key is determined as the private key (P) and the generator value (GV). In this example, since the public key is determined as the private key using elliptic curve dot multiplication with a base point (G) (step 370'), the second public key of the second node (P) can be expressed in a manner similar to Equation 6. 2S ),like:

[0230] P 2S = V 2S ×G (Formula 10.1)

[0231] P 2S = P 1S + GV×G (Formula 10.2).

[0232] The mathematical proof of Formula 10.2 is the same as that used above to derive the second public key of the first node (P). 2C The mathematical proof of Formula 9.1 is the same. It should be understood that in step 370, the first node 3 can determine the second public key of the second node independently of the second node 7.

[0233] Determine the public secret 380 at the first node 3

[0234] Then, in step 380, the first node 3 can, based on the determined first node second private key (V... 2C ) and the determined second node second public key (P 2S The public key (CS) is determined by the first node 3 using the following formula:

[0235] S = V 2C × P 2S (Formula 11).

[0236] Method 400 is executed at node 7.

[0237] The corresponding method 400 executed at the second node 7 will now be described. It should be understood that some of these steps are similar to the steps executed by the first node 3 described above.

[0238] Method 400 includes step 410, receiving a message (M) from the first node 3 via the communication network 5. This may include the message (M) sent by the first node 3 in step 315. Then, in step 420, the second node 7 determines a generator value (GV) based on the message (M). Step 420, in which the second node 7 determines the generator value (GV), is similar to step 320 performed by the first node as described above. In this example, the second node 7 performs this determination step 420 independently of the first node 3.

[0239] The next step includes step 430, based on the first node's master public key (P 1C The first node's second public key (P) is determined by the generator value (GV) and the generator value (P). 2C In this example, since the public key is determined as the private key using elliptic curve dot multiplication with a base point (G) (step 430'), the second public key of the first node (P) can be expressed in a manner similar to Equation 9. 2C ),like:

[0240] P 2C = V 2C ×G (Formula 12.1)

[0241] P 2C = P 1C + GV×G (Equation 12.2).

[0242] The mathematical proofs for formulas 12.1 and 12.2 are the same as those discussed above for formulas 10.1 and 10.2.

[0243] Second node 7 authenticates first node 3

[0244] Method 400 may include steps performed by the second node 7 to verify that the claimed first node 3 is indeed the first node 3. As previously described, this includes step 440 of receiving a first signed message (SM1) from the first node 3. The second node 7 can then utilize the first node's second public key (P) determined in step 430. 2C (Step 450) to verify the signature on the first signature message (SM1).

[0245] Verification of the digital signature can be accomplished using the Elliptic Curve Digital Signature Algorithm (ECDSA) as described above. Importantly, this is done using the first node's second private key (V). 2C The first signed message (SM1) should be signed only with the corresponding first node's second public key (P). 2C To verify correctly, because V 2C and P 2C A cryptographic pair is formed. These keys are the first node's master private key (V) generated during the registration of the first node 3. 1C ) and the first node's master public key (P 1C The first signature message (SM1) is deterministic, thus verifying that it can be used as the basis for authentication to verify that the so-called first node that sent the first signature message (SM1) is the same first node 3 as during registration. Therefore, the second node 7 can also perform the step of verifying (460) the first node 3 based on the result of verifying (450) the first signature message, see [link to documentation]. Figure 11 .

[0246] The second node, 7, determines the public key.

[0247] Method 400 may also include: the second node 7 based on the second node's master private key (V 1S The second node's second private key (V) is determined in step 470, along with the generator value (GV). 2S Similar to step 330 executed by the first node 3, the second node's second private key (V) 2S It can be based on the second node's master private key (V) 1S The scalar addition of the generator value (GV) and the generator value (GV) is performed according to the following formula:

[0248] V 2S = V 1S + GV (Formula 13.1)

[0249] V 2S = V 1S + SHA-256(M) (Formula 13.2).

[0250] Then, the second node 7 can operate independently of the first node 3, based on the second node's second private key (V) according to the following formula. 2S ) and the first node's second public key (P 2C To determine (step 480) the public key (CS):

[0251] S = V 2S ×P 2C (Formula 14).

[0252] Proof of the public key (CS) determined by the first node 3 and the second node 7.

[0253] The public key (CS) determined by the first node 3 is the same as the public key (CS) determined at the second node 7. The mathematical proof that Equations 11 and 14 provide the same public key (CS) is now described.

[0254] Switching to the public key (CS) determined by the first node 3, Equation 10.1 can be substituted into Equation 11:

[0255] S = V 2C ×P 2S (Formula 11)

[0256] S = V 2C ×(V) 2S × G)

[0257] S = (V 2C × V 2S )×G (Formula 15).

[0258] Switching to the public key (CS) determined by the second node 7, Equation 12.1 can be substituted into Equation 14, as follows:

[0259] S = V 2S ×P 2C (Formula 14)

[0260] S = V 2S ×(V) 2C × G)

[0261] S = (V 2S × V 2C )×G (Formula 16).

[0262] Since ECC algebra is commutative, Equations 15 and 16 are equivalent because:

[0263] S = (V 2C × V 2S ) × G = (V 2S ×V 2C )×G (Formula 17).

[0264] Public secret (CS) and secret key

[0265] The public secret (CS) can now be used as a secret key, or as the basis for a secret key in a symmetric key algorithm for secure communication between the first node 3 and the second node 7.

[0266] The public secret (CS) can be in the form of elliptic curve points (xs, ys). This can be converted to a standard key format using standard known operations agreed upon by nodes 3 and 7. For example, the xs value can be a 256-bit integer, which can be used as an AES key. 256 The encryption key. It can also be converted to a 160-bit integer using RIPEMD160, for use by any application that requires a key of this length.

[0267] The public secret (CS) can be determined as needed. Importantly, the first node 3 does not need to store the public secret (CS) because it can be re-determined based on the message (M). In some examples, the message (M) used can be stored in data stores 13, 17, 19 (or other data stores), without requiring the same level of security as the master private key. In some examples, the message (M) can be publicly available.

[0268] However, depending on the application, the public secret (CS) can be stored in the first data store (X) associated with the first node, provided that the public secret (CS) is like the first node's master private key (V). 1C Store it as safely as possible.

[0269] Advantageously, this technique can be used to determine multiple public secrets that may correspond to multiple secure secret keys, based on a single master key cryptographic pair.

[0270] Hierarchy of generator values ​​(keys)

[0271] For example, a series of inherited generator values ​​(GVs) can be determined, where each inherited GV can be determined based on a previous generator value (GV). Instead of repeating steps 310 to 370 and 410 to 470 to generate inherited single-purpose keys, the nodes can repeatedly rehash previously used generator values ​​(GVs) to establish a hierarchy of generator values ​​through a prior protocol. In practice, the generator value hashed based on the message (M) can be the next-generation message (M') of the next-generation generator value (GV). This allows for the computation of shared keys across generations without further protocol-established transmissions, specifically multiple messages transmitted for each generation of public key. The next-generation public key (CS') can be computed as follows.

[0272] First, both node 3 and node 7 independently determine the next-generation generator value (GV). This is similar to steps 320 and 420, but adjusted using the following formula:

[0273] M' = SHA-256(M) (Formula 18)

[0274] GV' = SHA-256(M') (Formula 19.1)

[0275] GV' = SHA-256(SHA-256(M)) (Equation 19.2).

[0276] Then, the first node 3 can determine the second public key (P) of the next generation second node. 2S ') and the first node's second private key (V 2C Similar to steps 370 and 330 above, but adjusted using the following formula:

[0277] P 2S '= P 1S + GV'×G (Formula 20.1)

[0278] V 2C '= V 1C + GV' (Formula 20.2).

[0279] Then, the second node 7 can determine the second public key (P) of the next generation first node. 2C ') and the second node's second private key (V 2SSimilar to steps 430 and 470 above, but adjusted using the following formula:

[0280] P 2C ' = P 1C + GV' × G (Formula 21.1)

[0281] V 2S ' = V 1S + GV' (Formula 21.2).

[0282] Then, the first node 3 and the second node 7 can each determine the next-generation public key (CS'). Specifically, the first node 3 determines the next-generation public key (CS') using the following formula:

[0283] CS' = V 2C ' × P 2S ' (Formula 22).

[0284] The second node 7 uses the following formula to determine the next-generation public key (CS'):

[0285] CS' = V 2S '× P 2C ' (Formula 23).

[0286] More generations (CS, CS', etc.) can be computed in the same way to create a chain hierarchy. This technique requires both the first node 3 and the second node 7 to track the original message (M) or the initially computed generator value (GV) and the nodes involved. Since this is public information, there are no security issues regarding the retention of this information. Therefore, this information can be stored on a "hash table" (linking hash values ​​to public keys) and freely distributed via a network 5 (e.g., using Torrent). Furthermore, if any single public secret (CS) in the hierarchy is compromised, as long as the private key V... 1C V 1S This ensures security without compromising the security of any other public secrets within the hierarchy.

[0287] Tree structure of keys

[0288] In addition to the chain (linear) hierarchy described above, tree-structured hierarchies can also be created. Using a tree structure, various keys for different purposes can be identified, such as authentication keys, encryption keys, signing keys, payment keys, etc., all of which are linked to a single, securely maintained master key. Figure 12 The diagram below best illustrates a tree structure 901 with various different keys. Each of these keys can be used to create a shared key with another party. The branching of the tree can be accomplished in several ways, three of which are described below.

[0289] Master key spawning

[0290] In the chain hierarchy, each new "link" (public / private key pair) is created by adding the multiplicative rehashed message to the original master key. For example (for clarity, only the private key of the first node 3 is shown):

[0291] V 2C = V 1C + SHA-256(M) (Formula 24)

[0292] V 2C '= V 1C + SHA-256 (SHA-256(M)) (Formula 25)

[0293] V 2C ''= V 1C +SHA-256(SHA-256(SHA-256(M))) (Formula 26)

[0294] ......etc.

[0295] To create a branch, any key can be used as a child master key. For example, just like a regular master key, it can be created by sending a key to V. 2C Add a hash to use it as a sub-master key (V 3C ):

[0296] V 3C = V 2C '+ SHA-256(M) (Formula 27).

[0297] Sub-master key (V 3C The key itself can have a next-generation key (V). 3C '),For example:

[0298] V 3C '= V 2C '+ SHA-256(SHA-256(M)) (Formula 28).

[0299] Thus, using Figure 13 The master key generation method shown provides a tree structure 903.

[0300] (ii) Logical association

[0301] In this method, all nodes (public / private key pairs) in the tree are generated as a chain (or in any other way), and the logical relationships between nodes in the tree are maintained by a table for each node, in which nodes in the tree are simply associated with their parent nodes in the tree via pointers. Therefore, pointers can be used to determine the associated public / private key pairs to ascertain the public secret (CS) of the session.

[0302] (iii) Message multiplicity

[0303] New private / public key pairs can be generated by introducing new messages at any point in the chain or tree. The message itself can be arbitrary or can carry some meaning or function (e.g., it might be related to a "real" bank account number). It is ideal to securely preserve these new messages used to form new private / public key pairs.

Claims

1. A computer-implemented method for secure extraction of data from a blockchain, comprising the steps of: associating one or more elements of a structure with an encryption sub-key, the encryption sub-key being deterministically derived based on at least a private key of a previous key pair and a generator value, the generator value being determined from a message shared between a first node and a second node in the blockchain, wherein the structure is formed of elements within a hierarchical entity having a plurality of elements organised or associated in a hierarchical relationship; extracting or copying data comprising or involving the encryption sub-key associated with the one or more elements from a blockchain transaction (Tx); and sending the extracted data to a non-blockchain-based computer system associated with the hierarchical entity.

2. The method of claim 1, further comprising the step of: scanning, traversing and / or analysing the blockchain to identify one or more blockchain transactions (TXs) containing the data comprising or involving the encryption sub-key associated with the one or more elements.

3. The method of claim 1 or 2, further comprising the step of: processing the extracted data to generate an output.

4. The method of claim 3, further comprising the step of: communicating the output to a non-blockchain-based computer system associated with the hierarchical entity.

5. A computer device comprising: a processor; and a memory for storing instructions executable by the processor, wherein the processor is configured to execute the instructions stored in the memory to perform the method of any one of claims 1-4.

6. A computer-readable storage medium having stored thereon instructions which, when executed by a computer, cause the computer to perform the method of any one of claims 1-4. ​

Images