WO2021142541A1 - Systèmes et procédés pour la sécurité des actifs numériques - Google Patents

Systèmes et procédés pour la sécurité des actifs numériques Download PDF

Info

Publication number
WO2021142541A1
WO2021142541A1 PCT/CA2021/050030 CA2021050030W WO2021142541A1 WO 2021142541 A1 WO2021142541 A1 WO 2021142541A1 CA 2021050030 W CA2021050030 W CA 2021050030W WO 2021142541 A1 WO2021142541 A1 WO 2021142541A1
Authority
WO
WIPO (PCT)
Prior art keywords
private key
transaction
digital asset
proposed
broadcast
Prior art date
Application number
PCT/CA2021/050030
Other languages
English (en)
Inventor
Patrick Mclaughlin
Original Assignee
Brane Capital
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Brane Capital filed Critical Brane Capital
Priority to CA3167377A priority Critical patent/CA3167377A1/fr
Publication of WO2021142541A1 publication Critical patent/WO2021142541A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G06F21/645—Protecting data integrity, e.g. using checksums, certificates or signatures using a third party
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/40—User authentication by quorum, i.e. whereby two or more security principals are required
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database

Definitions

  • Embodiments of the present disclosure generally relate to the digital asset security, and in particular to systems and methods of verifying digital asset transactions by a plurality of nodes in a blockchain network.
  • Blockchain may be an electronic ledger implemented by a computer-based system having one or more blocks. Respective blocks may include a plurality of transactions, and transactions may be data structures encoding transfer of control of a digital asset among addresses in the blockchain network. In some examples, ownership or attribution of a digital asset to a user or an entity may be controlled based on encryption keys specified by blockchain transactions.
  • Blockchain transactions may encode transfer of control or encumbrances of digital assets.
  • private-public key sharing and verifying operations may be employed for tracking blockchain transactions associated with digital assets.
  • encryption keys may include alphanumeric text strings that may not be comprehensible by users.
  • transfer or encumbrance of digital assets may be based on operations associated a private key of a private-public key pair. Storage of the private key may be associated with custody or control of the digital asset. In the present example, if the private key is duplicated by an unintended user or by an unscrupulous user, custody of the digital asset may be compromised.
  • the present disclosure may provide a computer-implemented method of verifying a digital asset transaction by a plurality of nodes in a blockchain network.
  • the plurality of nodes may have respective private key fragments.
  • the method include: receiving a request to update an encumbrance associated with a digital asset; generating a proposed blockchain transaction based on the request to update the encumbrance, wherein broadcast of the proposed blockchain transaction is based on a reconstituted private key based on a plurality of private key fragments received from at least one other node; receiving a plurality of private key fragments from at least one other node for combination as a collective private key; determining that the collective private key corresponds to the reconstituted private key of a quorum for approving broadcast of the proposed blockchain transaction; and generating a signal to initiate broadcast of the proposed blockchain transaction to an electronic ledger of the blockchain network.
  • the quorum for approving broadcast of the proposed blockchain transaction may be based on determining that a quantity of private key fragments is greater than a private key fragment threshold.
  • the quorum for approving broadcast of the proposed blockchain transaction may be based on determining that a weighted quantity of private key fragments is greater than a weighted private key fragment threshold.
  • the quorum for approving broadcast of the proposed blockchain transaction may be based on identifying that the collective private key is a recovery private key associated with an asset recovery operation is received for the digital asset.
  • the quorum for approving broadcast of the proposed blockchain transaction may be based on determining, in parallel by two or more nodes, that the collective private key corresponds to the reconstituted private key of the quorum, and the method may include selecting one of the two or more proposed blockchain transactions validated in parallel is initiated for propagation to the electronic ledger of the blockchain network.
  • selecting one of the two or more proposed blockchain transactions validated in parallel may be a random selection.
  • the received private key fragments may be based on input provided on a user interface by a user associated with the at least one other node, and the input may be based on single sign-on authentication credentials associated with a hosted authentication platform for private key management.
  • the reconstituted private key may be generated based on a private key generation ceremony associated with the digital asset.
  • the proposed blockchain transaction may be at least one of a Smart Contract or Bitcoin P2SH script.
  • the at least one other node may be configured to audit or approve the proposed blockchain transaction without being able to generate the proposed blockchain transaction for the digital asset.
  • the present disclosure may provide a computing device for verifying a digital asset transaction.
  • the computing device may be a node of a plurality of nodes in a blockchain network.
  • the plurality of nodes may have respective private key fragments.
  • the computing device may include: a processor; and a memory coupled to the processor and storing processor-executable instructions.
  • the processor-executable instructions when executed, may configure the processor to: receive a request to update an encumbrance associated with a digital asset; generate a proposed blockchain transaction based on the request to update the encumbrance, wherein broadcast of the proposed blockchain transaction is based on a reconstituted private key based on a plurality of private key fragments received from at least one other node; receive a plurality of private key fragments from at least one other node for combination as a collective private key; determine that the collective private key corresponds to the reconstituted private key of a quorum for approving broadcast of the proposed blockchain transaction; and generate a signal to initiate propagation of the proposed blockchain transaction to an electronic ledger of the blockchain network.
  • the quorum for approving broadcast of the proposed blockchain transaction may be based on determining that a quantity of private key fragments is greater than a private key fragment threshold. [0019] In some embodiments, the quorum for approving broadcast of the proposed blockchain transaction may be based on determining that a weighted quantity of private key fragments is greater than a weighted private key fragment threshold.
  • the quorum for approving broadcast of the proposed blockchain transaction may be based on identifying that the collective private key is a recovery private key associated with an asset recovery operation is received for the digital asset.
  • the quorum for approving broadcast of the proposed blockchain transaction may be based on determining, in parallel by two or more nodes, that the collective private key corresponds to the reconstituted private key of the quorum, and the computing device may be configured to select one of the two or more proposed blockchain transactions validated in parallel is initiated for propagation to the electronic ledger of the blockchain network.
  • selecting one of the two or more proposed blockchain transactions validated in parallel may be a random selection.
  • the received private key fragments may be based on input provided on a user interface by a user associated with the at least one other node, and the input may be based on single sign-on authentication credentials associated with a hosted authentication platform for private key management.
  • the reconstituted private key may be generated based on a private key generation ceremony associated with the digital asset.
  • the proposed blockchain transaction is at least one of a Smart Contract or Bitcoin P2SH script.
  • the at least one other node may be configured to audit or approve the proposed blockchain transaction without being able to generate the proposed blockchain transaction for the digital asset.
  • a non-transitory computer-readable medium or media having stored thereon machine interpretable instructions which, when executed by a processor may cause the processor to perform one or more methods described herein.
  • the disclosure provides corresponding systems and devices, and logic structures such as machine-executable coded instruction sets for implementing such systems, devices, and methods.
  • FIG. 1 illustrates a system, in accordance with an embodiment of the present disclosure
  • FIG. 2 illustrates a block diagram of an example node in a blockchain network, in accordance with an embodiment of the present disclosure
  • FIG. 3 illustrates a block diagram of nodes collaboratively conducting operations of parallel integrity verification, in accordance with an embodiment of the present disclosure
  • FIG. 4 illustrates a user interface of a digital asset wallet, in accordance with an embodiment of the present disclosure
  • FIG. 5 illustrates a flowchart of a method of verifying a digital asset transaction, in accordance with an embodiment of the present disclosure.
  • FIG. 6 illustrates a block diagram of a computing device, in accordance with an embodiment of the present disclosure.
  • the present disclosure provides a digital asset transaction system and methods for verifying digital asset transactions by a plurality of nodes in a blockchain network.
  • the following disclosure provides examples relating to particular blockchain protocols; however, implementation with other blockchain protocols may be contemplated.
  • blockchain may refer to forms of electronic distributed ledgers.
  • a blockchain may include consensus-based transaction-chain technology, permissioned or un-permissioned ledgers, shared ledgers, or variations of the foregoing.
  • Examples of blockchain technology may include a Bitcoin ledger or an Ethereum ledger. Other blockchain technology examples may be contemplated.
  • a blockchain may be an electronic ledger having one or more blocks.
  • the blocks may include a plurality of transactions.
  • a transaction may be data structure encoding transfer of control of a digital asset among addresses in the blockchain.
  • respective blocks may include a hash of a previous block so that blocks may become chained together to create a substantially unalterable record of all transactions which have been broadcast to the blockchain.
  • decentralized systems may include features for providing reduced susceptibility to single points of failure.
  • Decentralized systems may include features providing increased security for recording transactions.
  • Ownership or attribution to a digital asset of a blockchain system may be controlled based on public-private key pairs.
  • the digital asset may be a token, which may be associated with currency, hard assets (e.g., precious metals, real estate, among other examples), soft assets (such as credits, time, among other examples), computing resources, or the like.
  • Digital assets may be associated with encumbrances associated with an owning user or a custodian entity.
  • blockchain transactions broadcast to the blockchain system may encode transfer of control or updates to encumbrances associated with the digital assets.
  • Encoding transfer of control of digital assets may be implemented with blockchain transactions, such as Smart Contracts (e.g., Ethereum networks) or P2SH scripts (e.g., Bitcoin networks) based on encryption keys, such as private-public keys associated with users or entities. It may be desirable to provide systems and methods of storing, utilizing, or verifying / validating private keys for updating encumbrances associated with digital assets. [0044] In some embodiments, there may be more than one encryption key fragments. A plurality of users or entities may retain an encryption key fragment, thereby requiring a combination of encryption key fragments for transferring or updating encumbrances to a digital asset.
  • encryption keys, blockchain transactions, or other features of blockchain networks may involve non-intuitive computer programming, lengthy alphanumeric text strings that may not be comprehensible to a user, or may include ordered operations for conducting transactions. It may be desirable to provide systems and methods of verifying digital asset transactions based on verification operations that may be intuitive to blockchain node users.
  • FIG. 1 illustrates a block diagram of a system 100, in accordance with an example of the present disclosure.
  • the system 100 may include a blockchain network, such as a peer-to-peer network.
  • FIG. 1 illustrates three nodes being associated with the blockchain network; however, any number of nodes may be contemplated.
  • the blockchain network may include an electronic ledger 110, which may include a plurality of blocks.
  • the respective blocks may include a plurality of transactions.
  • the respective transactions may be data structures for encoding transfer of control of a digital asset or digital asset value.
  • the system 100 may include one or more nodes that may conduct one or more operations disclosed herein.
  • the one or more example nodes (identified by reference numerals 122a, 122b, ... 122n) may be organized into a cluster or group of nodes 120 and may be configured to collaboratively conduct operations associated with digital asset security.
  • the one or more nodes may conduct one or more operations of a secret sharing protocol for distributing or assigning private key shares to respective nodes. Respective private key shares may be collaboratively combined for generating transactions for broadcasting to the electronic ledger 110.
  • the respective nodes of the group of nodes 120 may be electronic devices and may include operations associated with a blockchain protocol of the electronic ledger 110.
  • the respective nodes may include electronic devices such as computing devices (e.g., desktop computers, laptop computers, tablet computers, server computers, etc.), mobile devices (e.g., smartphone devices, wearable computing devices, or the like), or other type of electronic computing devices configured to transmit or receive data messages.
  • the respective nodes may be coupled to another node based on one or more wired or wireless communication technologies.
  • the system 100 may include a network (not explicitly illustrated in FIG. 1) for interconnecting the group of nodes 120.
  • the network may include wired or wireless wide area network (WAN), local area network (LAN), a combination thereof, or the like.
  • the network may include the Internet, Ethernet, coaxial cable, fiber optics, satellite, mobile, wireless, local area network, wide area network, and others, including combination of the foregoing.
  • the system 100 may be configured at least partly over the Internet, and a subset of the nodes may be located in geographically dispersed locations.
  • the respective nodes may maintain the electronic ledger 110.
  • respective nodes may store a copy or a partial copy of a global ledger.
  • One or more transactions based on the electronic ledger 110 may be verified by one or more operations of one or more nodes, such that validity of the electronic ledger 110 may be maintained.
  • Other operations for implementing, maintaining, or verifying a blockchain, such as a Bitcoin or Ethereum network, may be contemplated.
  • the system 100 may include a digital asset store 130.
  • the digital asset store 130 may be a repository of digital assets or records storing encumbering data of the digital assets.
  • digital assets or records storing encumbrance data associated with digital assets may be associated with a single private address, which may be associated with a single private key.
  • the single private key may be copied or uncovered by an unauthorized user, the unauthorized user of a computing device may generate a transaction to transfer or encumber the digital asset.
  • use of a single private key to generate transfer transactions for digital assets may be susceptible to unauthorized transfer of assets. It may be desirable to decentralize generation of transactions for transferring digital assets.
  • the respective nodes may be associated with a user and may conduct one or more workflow operations for digital asset management, such that responsibility / authority for generating transactions for transferring digital assets is based on multiple self sovereign users having private key portions, thereby decentralizing points of failure.
  • features based on redundancy may include generating fragments of private keys, such that no sole node or group of nodes of a blockchain network may independently generate a transaction for transferring or altering an encumbrance on a digital asset.
  • operations described herein may include private key generation operations for generating a plurality of private key fragments.
  • the private key fragments may be distributed to a plurality of users having segregated duties for digital asset management.
  • a defined minimum subset or a threshold number of private key fragments may be required.
  • private keys or private key fragments associated with the group of nodes 120 may be generated by private key generation operations based on physical entropy as root of trust.
  • a source of entropy may be randomly selected during private key generation operations from a large group of entropy sources that may appear to users associated with nodes, thereby reducing likelihood that a user associated with a node may be able to identify an entropy source even having access to such sources.
  • the entropy source may be destroyed prior to conclusion of private key generation operations, thereby reducing likelihood that results of the private key generation operations may be reverse engineered by analyzing entropy sources.
  • users associated with nodes may conduct operations to analyze electromagnetic emanations for inferring operations of entropy sources.
  • private key generation operations among nodes of an electronic ledger may be conducted based on TEMPEST rated or certified shielded environments (e.g., NATO SDIP-27 Ivl A). Hardware employed may be installed based on determined procedures, such as those defined by NATO SDIP-29 and AMSG 799B).
  • hardware associated with various sets of operations of the private key generation operations may be separated from other operations based on TEMPEST shielding and procedures.
  • private key generation operations may include verification operations for validating that generated seeds associated with key pairs may be properly recorded and identified as valid. Randomly generated seeds may be recorded and loaded onto hardware secure module (HSM) devices. A series of hierarchically determined public addresses may be generated on the respective HSM devices, and lists may be compared. Matching lists may mean that the HD seed was properly generated and recorded.
  • HSM hardware secure module
  • one or more nodes associated with an electronic ledger may conduct operations for recovering digital assets associated with a user of the one or more nodes.
  • the owner user or a designated user may broadcast an “escape hatch” transaction to the electronic ledger 110.
  • the recovery operations may be associated with a recovery address generated during prior private key generation operations, and the recovery address may be hard coded in a recovery transaction (e.g., a smart contract, P2SH script, among other examples). Because recovery addresses may be hard coded, it may be desirable to reduce likelihood of errors associated with the recovery transactions. For example, it may be desirable to reduce likelihood of address swapping by an unscrupulous or unintended user.
  • addresses associated with recovery transactions may be generated based on “in-ceremony contract fingerprinting”, and may be based on operations during latter operations of private key generation operations.
  • the “in-ceremony contract fingerprinting” may include operations such as: generating an escape hatch wallet and hard coding an escape hatch public key into a transaction (e.g., smart contract or P2SH script).
  • SHA-3 hash function may be applied to escape hatch code, and the hash function code may be recorded.
  • the transaction may be generated as a “ready to submit” transaction, and the SHA-3 Hash function may be applied to the entire transaction, and the record may be recorded.
  • a resulting hash or digital signature of the generated transaction or fingerprint may be used to verify correctness of the transaction (e.g., smart contract) before the transaction may be deployed to production.
  • the verification operations may be conducted without exposing results of operations of any private key generation operations described in the present disclosure.
  • one or more nodes may verify fingerprints against configuration of correctness. Mismatched fingerprints may indicate that a generated transaction (e.g., smart contract) may not be deployment ready. The one or more nodes may prevent broadcast of that generated transaction.
  • a generated transaction e.g., smart contract
  • the foregoing example operations for reducing likelihood of errors may be conducted in other scenarios where recipient addresses or other transaction data fields may need to be hard coded.
  • respective nodes of the group of nodes 120 may be configured based on operations for segregating duties for digital asset management. For example, when generating transactions for transferring ownership of a digital asset from one digital address to another digital address, one or more nodes may be configured to conduct operations associated with an assigned set of operations. In some examples, the collaborative operations of the group of nodes 120 may include operations that may be conducted based on a sequence or based on a defined threshold of operations.
  • the respective nodes may be associated with a user and may conduct one or more workflow operations for digital asset management.
  • One or more nodes may be associated with a transaction initiation user, which may be configured to generate one or more transactions associated with digital assets.
  • the one or more transactions may identify the digital asset being transferred, a quantity of digital asset being transferred, or the recipient address of a user to whom the digital asset may be transferred.
  • One or more nodes may be associated with an auditor user. Auditor users may review (but may not initiate) one or more transactions. Auditor users may provide input at one or more nodes for verifying that a given transaction is valid, that proper verification operations are completed, or other similar operations.
  • One or more nodes may be associated with a plurality of approver users responsible for approval.
  • one or more transactions associated with digital assets may be approved for broadcasting to the electronic ledger 110 based on approval by a defined quorum of users, such as at least a predetermined M of N number of users (e.g., a majority threshold or a predefined subset of users).
  • one or more transactions associated with digital assets may be approved for broadcasting to the electronic ledger 110 in response to conducting a determined number of workflow operations defined in a smart contract, thereby reducing broadcasting transactions to alter digital asset ownership / encumbrances not based on the determined workflow operations.
  • the group of nodes 120 may not be able to broadcast a transaction to alter digital asset ownership / encumbrance if at least one node associated with an auditor or approver user submits a “decline” vote or transaction among the collaborative operations of the group of nodes 120.
  • the group of nodes 120 may be configured to conduct operations such that any one of the nodes may be able to broadcast a transaction to alter digital asset ownership / encumbrance in response to a majority of “approve” votes or a defined quorum of M of N “approve” votes.
  • the respective nodes of the group of nodes 120 may transmit / receive data messages among each other for collaboratively conducting operations for initiating, auditing, approving, generating, or broadcasting transactions to the electronic ledger 110 for managing digital assets.
  • Weights or thresholds for private key fragments associated with particular users may be associated with defining proportions of combined private key fragments for generating transactions to alter digital asset ownership or encumbrances of digital assets. For example, transactions for successfully altering digital asset ownership may require a defined number of responsible users submit private key fragments or a defined class of users submit private key fragments.
  • weights such that for a transaction to be successfully generated for altering digital asset ownership: (i) a private key fragment be received from a “class A” user (e.g. weighted greatly relative to other private key fragments); (ii) one or more private key fragments be associated with backup scenarios where private key fragments from a “class A” user may not be available; and (iii) one or more private key fragments be associated with a legal escrow or conditional backstop.
  • a transaction for altering digital asset ownership may be generated based on private key fragments associated with a “class A” user in collaboration with either one of private key fragments from “class B” users or “class C” users.
  • a transaction for altering digital asset ownership may be generated based on private key fragments associated with the totality of “class B” users, in the event that private key fragments associated with a “class A” user may not be available.
  • a transaction for altering digital asset ownership may not be generated based solely on private key fragments associated with “class C” users without at least a private key fragment associated with a “class A” user or private key fragments from a totality of “class B” users.
  • private key fragments associated with the plurality of classes described above may further be assigned sub-weights, such that further weighting operations may be provided within respective class of users.
  • FIG. 2 illustrates a block diagram of an example node 240, in accordance with an embodiment of the present disclosure.
  • the node 240 may be a node from the group of nodes 120 illustrated in FIG. 1.
  • the node 240 may include one or more applications including operations for managing one or more digital assets of the digital asset store 130, and to generate or broadcast transactions to the electronic ledger 110.
  • a sole node 240 is illustrated in FIG. 2; however, the node 240 may be any one of the nodes in the group of nodes 120 illustrated in FIG. 1.
  • the node 240 may include a digital asset wallet application 242.
  • the digital asset wallet application 242 may provide a graphical user interface to a user associated with the node 240 for authenticating or signing transactions associated with altering digital asset ownership or encumbrances of digital assets.
  • the digital asset wallet application 242 may not store or have access to private key fragments associated with transaction generation, but may be an interface between a custodian vault application and private key applications / authentication applications.
  • electronic ledger technology such as Bitcoin or Ethereum networks
  • private keys or key fragments may include alphanumeric strings of text that may be incomprehensible to a user. It may be desirable to provide features for a simplified yet secure method for interacting with electronic ledgers.
  • the digital asset wallet application 242 may include features for providing a simplified yet secure interface with electronic ledger technology for digital asset security.
  • the digital asset wallet application 242 may include operations for interfacing with one or more hosted authentication platforms for private key management.
  • the digital asset wallet 242 may include operations for interacting with a hosted private key application 248b via an API proxy 246.
  • Hosted private key applications 248b may be hardware secure module-based services for generating email signature keys or two-factor authentication keys.
  • hosted private key application applications 248b may be based on hardware secure module services such as features from Gemalto or Thales hosted hardware secure module services.
  • the digital asset wallet 242 may include operations for interacting with a portable private key application 248a.
  • Portable private key applications 248a may include offline hardware key storage devices for managing private keys associated with digital asset security. Solely as examples, portable private key applications 248a may include features based on hardware such as TrezorTM, LedgersTM, or CoolWalletTM for managing private keys for digital asset security.
  • the digital asset wallet 242 may include operations for interfacing with one or more parallel user authentication systems.
  • parallel authentication systems may be based on MicrosoftTM active directory credentials, image based (QR code) signed transaction input, or text-based signed transaction input, among other examples.
  • the digital asset wallet 242 may provide features for presenting the proposed transaction to the user and receiving private key or private key fragments from one or more private key applications.
  • the node 240 may include a custodian vault application 244.
  • the custodian vault application 244 may include operations for altering ownership associations or encumbrances among digital assets associated with the digital asset store 130. [0085] In some scenarios, it may be desirable to decentralize operations for altering ownership associations or encumbrances among digital assets. To reduce occurrences of corrupted or compromised operations, in some embodiments, the custodian vault application 244 may include parallel integrity verification operations.
  • FIG. 3 illustrates a block diagram of nodes collaboratively conducting operations of parallel integrity verification operations.
  • a generated transaction may be provided as an input (i) for proposed broadcast to the electronic ledger 110.
  • the proposed transaction, input (i) may be provided by a relay / repeater 310 to a plurality of distributed computing devices.
  • Each of the distributed computing devices 330 may be a client / node for conducting integrity verification operations 320.
  • integrity verification operations 320 may include validation of hash values, addresses associated with digital assets, among other examples.
  • the system may validate that a proposed transaction for altering digital asset ownership associations or encumbrances may be coherent by comparing the outputs of the respective clients shown in FIG. 3.
  • the custodian vault application 244 may include operations for rotating which of the plurality of nodes may broadcast the verified transaction to the electronic ledger 110.
  • determining which of the plurality of nodes broadcasts the verified transaction may be based on a substantially random determination. Accordingly, the same verified transaction may not be submitted to the electronic ledger 110 multiple times.
  • above-described operations of the custodian vault application 244 may reduce disadvantages inherent in single points of failure by leveraging multiple distributed computing resources for verifying integrity of proposed transactions.
  • operations of the custodian vault application 244 may comply with cloud security certification of ISO 27017, or other certification standards.
  • proposed transactions for altering digital asset ownership or encumbrances may be based on collective private keys or private key fragments received from one or more users associated with a node of the blockchain system.
  • multiple users or nodes may be compromised or inaccessible or in the event that multiple private key fragments may be accessed by unintended users (or unscrupulous users)
  • the custodian vault application 244 may provide operations of an “escape hatch” to encumber target digital assets in a predefined and secured asset store.
  • the custodian vault application 244 may conduct hard-coded functions inherent in a smart contract (e.g., smart contract of a Ethereum blockchain node or P2SH script of a Bitcoin blockchain node), such that once triggered may alter the encumbrance of the target digital asset in a known / safe digital asset store.
  • the known / safe digital asset store may be determined during private key generation operations for defining the “escape hatch” location of target digital assets.
  • a transaction may be broadcast to encumber the target digital assets in a predefined and secured asset store independently of other user roles associated with digital asset security, as disclosed herein.
  • the “escape hatch” feature may be triggered by an owning user of target digital assets based on scanning a “quick response” (QR) code, or other predetermined physical code for broadcasting to the electronic ledger 110.
  • QR quick response
  • the QR code may have been generated during operations determining segregated duties for digital asset management.
  • the custodian vault application 244 may include operations for identifying defined conditions or defined addresses specified in smart contracts, P2SH scripts, among other examples, that may signal that an “escape hatch” condition has been met. In response to identifying conditions or addresses that signal the “escape hatch” condition has been met, the custodian vault application 244 may broadcast a transaction to the electronic ledger 110 for altering encumbrance of associated digital assets, thereby preventing digital assets from being encumbered by unscrupulous or unintended users or nodes.
  • the custodian vault application 244 may include operations for validating or verifying digital asset chain of custody of target digital assets associated with blockchain technology logic.
  • an electronic ledger may be implemented with Ethereum technology, where blockchain technology logic may be included with Ethereum smart contracts.
  • an electronic ledger may be implemented with Bitcoin technology, where blockchain technology logic may be included with P2SH scripts.
  • P2SH scripts associated with Bitcoin technology may define chain of custody or escape hatch public addresses, or may define operations for enforcing M of N authentication of transactions.
  • Ethereum smart contracts may similarly define chain of custody or escape hatch public addresses, or may define operations for enforcing M of N authentication transactions.
  • the custodian vault application 244 may include operations for enforcing the logic associated with the chain of custody of target digital assets.
  • the custodian vault application 244 may include operations for enforcing necessary collection of private key fragments for verification prior to generating and broadcasting a transaction to the electronic ledger 110 for altering ownership of digital assets or encumbrances of digital assets.
  • the custodian vault application 244 may validate the “M of N” private key fragment requirements, or may validate assigned weights or thresholds for private key fragments defined for generating transactions to alter digital asset ownership or encumbrances.
  • the custodian vault application 244 may include operations for identifying an “escape hatch” trigger for enabling altering encumbrance of digital assets in a secure digital asset store, such as in scenarios where a predefined user of a node signals that a node of the electronic ledger 110 or one or more private key fragments may have been inadvertently discovered by an unintended or unscrupulous user.
  • the custodian vault application 244 may include operations for altering smart contracts (e.g., Ethereum technology), P2SH scripts (e.g., Bitcoin technology), among other examples, for altering responsibilities of users associated with nodes of the electronic ledger 110. For example, over time, users of nodes may alter responsibilities, and the custodian vault application 244 may include operations to alter roles of initiation users, auditor users, or approver users. In some embodiments, the custodian vault application 244 may include operations for adding or removing users from responsibilities of an initiation user, auditor user, or approver user, among other examples.
  • smart contracts e.g., Ethereum technology
  • P2SH scripts e.g., Bitcoin technology
  • distributed ledger transactions may be susceptible to errors, such as erroneous characters among private key fragments, addresses to which digital assets may be associated, user credentials, among other examples.
  • errors such as erroneous characters among private key fragments, addresses to which digital assets may be associated, user credentials, among other examples.
  • an addition of an extraneous “0” or an erroneous character in a recipient address may be relatively challenging to detect and may result in broadcasting an unintended transaction to the electronic ledger 110. It may be desirable to provide operations for verifying or validating proposed transactions for broadcast to the electronic ledger 110.
  • the custodian vault application 244 may include operations for validating data fields of smart contracts or P2SH scripts (examples disclosed herein) for errors in addresses associated with digital assets, errors with expected private key fragments associated with users, among other examples.
  • the custodian vault application 244 may include operations for identifying addresses associated with users of the system.
  • the custodian vault application 244 may include operations for identifying whether recipient addresses associated with proposed transactions for altering digital asset ownership or encumbrances may be listed on an “allow” list or a “deny” list.
  • Such “allow” or “deny” lists may be digitally signed by digital asset owners and hashed, to reduce occurrences of unintended alterations to the “allow” or “deny” lists.
  • the custodian vault application 244 may include operations for disallowing transactions for broadcasting to the electronic ledger 110 when recipient addresses of the proposed transaction may be included in a “deny” list.
  • smart contracts or P2SH scripts may be configured with timing parameters or timing thresholds.
  • the custodian vault application 244 may include operations for disallowing transactions for broadcasting to the electronic ledger 110 when the proposed transaction may not meet timing thresholds or may not meet defined timing parameters. For example, if a proposed transaction for altering ownership or encumbrance of a digital asset may be greater than a defined value, the custodian vault application 244 may include operations for preventing the proposed transaction from being broadcast to the blockchain within defined periods of time, thereby increasing a likelihood of supporting proper workflow verifications among users having private key fragments.
  • the custodian vault application 244 may include operations for determining “time” elapsed between proposed transactions and the value of respective transactions, and if broadcast of such transactions is greater than defined threshold limits, the custodian vault application 244 may include operations to decline transactions.
  • the custodian vault application 244 may include operations for identifying proposed transactions that have not yet been successfully broadcast to the electronic ledger 110 after a predetermined amount of time (e.g., 12 hours, 24 hours, among other examples), the custodian vault application 244 may include operations for declining the transaction for broadcast to the electronic ledger 110.
  • determining whether a proposed transaction may have exceeded a predetermined period of time may be based on a quantity of elapsed time from a timestamp of a “last vote” by a user of a node associated with the segregated duties for the digital asset management operations.
  • the identified quantity of elapsed time may be based on a time stamp that the last approver user submitted a private key fragment associated with a transaction approval.
  • nodes that broadcast transactions to an electronic ledger 110 may incur transaction processing fees.
  • the transaction processing fees may be deducted from the digital asset associated with the broadcasted transaction.
  • the transaction processing fee may be calculated in “gas” and paid out in Ethereum.
  • the “gas” fees may be deducted from digital assets associated with recipient address.
  • the “gas” may be calculated at the same time as broadcast of the transaction.
  • the custodian vault application 244 may include operations for generating transactions such that transaction processing fees may be allocated based on defined reservoir user addresses.
  • the defined reservoir user addresses may be a hard-coded or pre-authorized digital asset fund for allocating transaction processing fees.
  • transaction processing fees may be variable and may be based on electronic ledger 110 demand and availability (e.g., mining or validation capacity among nodes). It may be desirable to provide operations to reduce transaction times that may otherwise be extended by operations to determine transaction processing fees.
  • the custodian vault application 244 may include operations for monitoring transaction processing fees via a node on the electronic ledger.
  • the custodian vault application 244 may include operations to provide anticipated transaction processing fees (e.g., substantially similar to a latest transaction price, or greater than the last transaction cost by 25%), such that when a node broadcasts a transaction for altering ownership or encumbrance of a digital asset to the electronic ledger 110, the broadcasted transaction may have a high likelihood of being processed in the next block of transactions.
  • anticipated transaction processing fees e.g., substantially similar to a latest transaction price, or greater than the last transaction cost by 25%
  • FIG. 4 illustrates a user interface 400 for a digital asset wallet 242, in accordance with an embodiment of the present disclosure.
  • the user interface 400 may be generated for display at one or more nodes associated with the electronic ledger 110 (FIG. 1).
  • the user interface 400 may be provided for one or more users, such as a transaction initiation user, an auditor user, an approver user, among other examples.
  • the user interface 400 may be configured to display representations of blockchain transactions for one or a plurality of different digital asset accounts.
  • the user interface 400 may be displayed for a user named Jane, and Jane may have multiple digital asset accounts, such as a Bitcoin account for personal Bitcoins, a documents account for signed documents, a Bitcoin account for investment-related Bitcoins, among other examples.
  • the user interface 400 may provide a unified interface for displaying proposed / pending blockchain transactions, prior approved blockchain transactions, historical declined blockchain transactions, among other examples, for each of the multiple digital asset accounts.
  • the user interface 400 may be a front-end interface of the digital asset wallet for summarizing generated transactions that may be broadcast to the electronic ledger 110 upon being approved by one or more users associated with the transaction.
  • the generated transaction may be for altering ownership or encumbrance of digital assets.
  • a summary region 410 may provide a dynamically generated list of proposed transactions for broadcasting to the electronic ledger 110, subject to obtaining approvals represented by or associated with private key fragments from one or more users of the group of nodes 120 (FIG. 1).
  • the user interface 400 may provide a user experience that may reduce complexities associated with managing private keys, recipient addresses, or transaction data field values, among other examples, for users of the electronic ledger 110.
  • a review request user interface 420 may be provided for receiving a user’s approval (in the user’s capacity as a transaction reviewer - e.g., as approver user, auditor user, or other type of user).
  • the review request user interface 420 may include a message that may correspond to a fingerprint for validating authenticity of the proposed transaction, and that there are no apparent errors in fingerprints. From a user’s perspective, the “message” may be a long alphanumeric text string that may be incomprehensible or nonsensical. Accordingly, the user interface 400 may provide features that may reduce the complexity of approving proposed transactions for altering ownership or encumbrances of digital assets.
  • private key fragments associated with the user of the user interface 400 may be associated with private key hosted solutions, such as hardware key devices, private key wallet devices, two-factor authentication methods involving mobile devices, existing single sign-on authentication services already adopted by organizations of which the user is a member of, among other examples.
  • private key hosted solutions such as hardware key devices, private key wallet devices, two-factor authentication methods involving mobile devices, existing single sign-on authentication services already adopted by organizations of which the user is a member of, among other examples.
  • the user interface 400 may receive user input to “sign” the proposed transaction.
  • the node may append one or more private key fragments associated with approval operations of the proposed transactions. Accordingly, a user associated with the node may not need to explicitly manage private key fragments at least because the digital asset wallet 242 provides features to reduce complexity of interacting with the distributed ledger 110.
  • the computing device e.g., node
  • the user interface 400 of FIG. 4 illustrates Bitcoin as an example digital asset, but other digital assets, such as other types of cryptocurrency, tokens, precious metals, real estate, among other examples, may be contemplated.
  • FIG. 5 illustrates a flowchart of a method 500 of verifying a digital asset transaction, in accordance with an embodiment of the present disclosure.
  • the method 500 may be conducted by a processor of a node (FIG. 1).
  • Processor-executable instructions may be stored in memory of the node and may be associated with digital asset security applications or other processor-executable applications.
  • the method 500 may include operations, such as data retrievals, data manipulations, data storage, or other operations, among other computer-executable operations.
  • a user may be a transaction requester and the user may provide on an interface to request to update an encumbrance associated with a digital asset.
  • a user may be the holder of a quantity of Bitcoin, and may wish to send a portion of the owned quantity of Bitcoin to another user (e.g., recipient address).
  • the user may wish to update an encumbrance associated with the owned quantity of Bitcoin.
  • the user may be associated with a node of a blockchain network, and the user may interface with a user interface 400 of FIG. 4 for requesting the transfer of Bitcoin to recipient address.
  • Examples herein include analogies of transferring a digital asset as updating an encumbrance; however, other forms of updating encumbrances associated with digital assets may be contemplated.
  • updating encumbrances associated with digital assets may include assigning custodianship of the digital assets to a custodian user or custodian address for digital asset safekeeping, among other examples.
  • the processor may receive a request to update an encumbrance associated with a digital asset.
  • the request may be received at a user interface displayed at a computing device (e.g., node) associated with a user.
  • the processor may generate a proposed blockchain transaction based on the request to update the encumbrance of the digital asset.
  • an eventual broadcast of the proposed blockchain transaction may be based on verifying that private key fragments collectively provide a private key associated with a quorum for approving broadcast of the proposed blockchain transaction.
  • broadcasting the proposed blockchain transaction to the electronic ledger 110 may effect the encumbrance update associated with the digital asset (e.g., transfer Bitcoin or other digital asset quantity to a recipient address, among other examples).
  • a reconstituted private key may be a private key that may indicate that appropriate approval for a blockchain transaction has been received, and that a quorum for approving the broadcast of the blockchain transaction has been received.
  • the node may determine that a quorum for approving the blockchain transaction is received.
  • a collective private key (e.g., based on received private key fragments) may correspond to a reconstituted private key when a quantity of private key fragments may be greater than a private key fragment threshold.
  • a quantity of private key fragments may be greater than a private key fragment threshold when M of N private key fragments suitable for approving a blockchain transaction have been received.
  • a collective private key may correspond to a reconstituted private key when a weighted quantity of private key fragments may be greater than a weighted private key fragment threshold.
  • weighted private key fragment thresholds may define proportions of private key fragments associated with a particular class or subset group of users. For example, the weighted private key fragment threshold may be defined such that a private key fragment associated with at least one “class A” user be received in addition to one or more of a “class B” or a “class C” user prior to approving broadcast of the blockchain transaction.
  • the weighted private key fragment threshold may be defined such that when no private key fragments of “class A” users are received, private key fragments of all “class B” users must be received.
  • a collective private key may correspond to a reconstituted private key when the collective private key is determined to be a recovery private key associated with a digital asset recovery operation.
  • a digital asset recovery operation may be provided in scenarios where a digital asset owner may believe that the digital asset may become encumbered by an unintended user (e.g., by mistake or by malicious intent), or where one or more private key fragments may be lost (e.g., misplaced by a current digital asset owner or stolen by an unintended user).
  • the proposed blockchain transaction may be configured to encumber the subject digital asset at a specific known or “safe” recipient address, akin to a custodial encumbrance.
  • the proposed blockchain transaction may be associated with a transfer of digital asset that is subject to approval, audit, or other similar type oversight by other users associated with the blockchain network.
  • the proposed blockchain transaction may be subject to an auditor user’s approval to attest that the transaction is supported per defined criteria, or may be subject to one or more approver users’ approval providing cryptographic assurance that the blockchain transaction is legitimate or as intended by an organization.
  • approver users may be subject to provide cryptographic assurance that the blockchain transaction is legitimate or as intended by an organization.
  • Other examples of approval types may be contemplated.
  • the processor may receive, from at least one other node, a plurality of private key fragments. Respective private key fragments may be received from one or more other nodes associated with users assigned to a workflow associated with defined quorum for approving broadcast of the proposed blockchain transaction. In some embodiments, the processor may combine the received plurality of private key fragments for providing a collective private key.
  • the processor may determine that the collective private key corresponds to a reconstituted private key of a quorum for approving broadcast of the proposed blockchain transaction.
  • the reconstituted private key may be associated with a private key fragment threshold, a weighted private key fragment threshold, or a recovery private key, among other examples described in the present disclosure.
  • the processor may generate a signal to initiate broadcast of the proposed blockchain transaction to an electronic ledger of the blockchain network. That is, when the processor determines that the assembled collective private key corresponds to a reconstituted private key of a quorum for approving broadcast of the proposed blockchain transaction, the processor may publish or broadcast that proposed blockchain transaction for updating the encumbrance associated with the digital asset.
  • the received private key fragments, from the plurality of nodes may be based on input provided on a user interface by a user associated with the at least one node.
  • the private key fragments may have been associated with a two- factor authentication operation, a single sign-on authentication credential, or other example hosted authentication platform.
  • Such embodiments of the present disclosure may provide a simplified method for users for interacting with electronic ledgers and blockchain networks, thereby reducing complexity of managing, for example, private keys or other blockchain transaction elements having incomprehensible strings of text.
  • reconstituted private keys may be defined based on private key generation ceremony or operations associated with digital assets at a time when digital assets may be catalogued, associated, or stored at a given digital asset store.
  • the quorum for approving broadcast of the proposed blockchain transaction may be based on determining, in parallel by two or more nodes, that the collective private key corresponds to the reconstituted private key of the quorum.
  • two or more nodes may conduct operations for determining whether the collective private key corresponds to the reconstituted private key of a quorum.
  • the two or more nodes may conduct operations for checking whether hash values, address values, fingerprint values, or other integrity measure values are as expected. The operations may be conducted by two or more nodes illustrated in a parallel workflow, as described with reference to FIG. 3 herein.
  • one or more nodes may be configured to promote or broadcast a verified blockchain transaction to the electronic ledger of the blockchain network. That is, one of the two or more proposed blockchain transactions validated in parallel may be initiated for propagation to the electronic ledger.
  • selection of which of the nodes to retrieve the validated blockchain transaction for broadcasting to the electronic ledger may be a random selection, thereby reducing likelihood of single points of failures and reducing the likelihood that an unscrupulous or unintended entity may be able to compromise a node to alter contents of the proposed blockchain transaction for updating digital asset encumbrance.
  • FIG. 6 illustrates a block diagram of a computing device 600, in accordance with an embodiment of the present disclosure.
  • the one or more nodes in the group of nodes 120 may be implemented using the example computing device 600 of FIG. 6.
  • the computing device 600 may include at least one processor 602, memory 604, at least one I/O interface 606, and at least one network communication circuit 608.
  • the processor 602 may be a microprocessor or microcontroller, a digital signal processing (DSP) processor, an integrated circuit, a field programmable gate array (FPGA), a reconfigurable processor, a programmable read-only memory (PROM), or combination thereof.
  • DSP digital signal processing
  • FPGA field programmable gate array
  • PROM programmable read-only memory
  • the memory 604 may include a computer memory that may be located either internally or externally such as, for example, random-access memory (RAM), read-only memory (ROM), compact disc read-only memory (CD-ROM), electro-optical memory, magneto-optical memory, erasable programmable rad-only memory, and electrically-erasable programmable read-only memory (EEPROM), Ferroelectric RAM (FRAM).
  • RAM random-access memory
  • ROM read-only memory
  • CD-ROM compact disc read-only memory
  • electro-optical memory magneto-optical memory
  • EEPROM electrically-erasable programmable read-only memory
  • FRAM Ferroelectric RAM
  • the I/O interface 606 may enable the computing device 600 to interconnect with one or more input devices, such as a keyboard, mouse or pointing device, image capture device, touch screen device, a microphone device, or one or more output devices such as a display screen or a speaker, among other examples.
  • input devices such as a keyboard, mouse or pointing device, image capture device, touch screen device, a microphone device, or one or more output devices such as a display screen or a speaker, among other examples.
  • the network communication circuit 608 may be configured to receive or transmit data messages to or from other computing devices, to access or connect to network resources, or to perform other computing applications by connecting to a network (or multiple networks) capable of carrying data.
  • connection or “coupled to” may include both direct coupling (in which two elements that are coupled to each other contact each other) and indirect coupling (in which at least one additional element is located between the two elements).
  • the embodiments of the devices, systems and methods described herein may be implemented in a combination of both hardware and software. These embodiments may be implemented on programmable computers, each computer including at least one processor, a data storage system (including volatile memory or non-volatile memory or other data storage elements or a combination thereof), and at least one communication interface.
  • Program code is applied to input data to perform the functions described herein and to generate output information.
  • the output information is applied to one or more output devices.
  • the communication interface may be a network communication interface.
  • the communication interface may be a software communication interface, such as those for inter-process communication.
  • there may be a combination of communication interfaces implemented as hardware, software, and combination thereof.
  • a server can include one or more computers operating as a web server, database server, or other type of computer server in a manner to fulfill described roles, responsibilities, or functions.
  • the technical solution of embodiments may be in the form of a software product.
  • the software product may be stored in a non-volatile or non-transitory storage medium, which can be a compact disk read-only memory (CD-ROM), a USB flash disk, or a removable hard disk.
  • the software product includes a number of instructions that enable a computer device (personal computer, server, or network device) to execute the methods provided by the embodiments.
  • the embodiments described herein are implemented by physical computer hardware, including computing devices, servers, receivers, transmitters, processors, memory, displays, and networks. The embodiments described herein provide useful physical machines and particularly configured computer hardware arrangements. [00150] As can be understood, the examples described above and illustrated are intended to be exemplary only.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Data Mining & Analysis (AREA)
  • Computing Systems (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne des dispositifs informatiques et des procédés de vérification d'une transaction d'actif numérique par une pluralité de nœuds dans un réseau à chaîne de blocs. La pluralité de nœuds peut comprendre des fragments de clé privée respectifs. Le dispositif informatique peut être configuré pour : recevoir une demande de mise à jour d'une charge associée à un actif numérique; générer une transaction de chaîne de blocs proposée sur la base de la demande de mise à jour de la charge, la diffusion de la transaction de chaîne de blocs proposée pouvant être basée sur une clé privée reconstituée sur la base d'une pluralité de fragments de clé privée reçus en provenance d'au moins un autre nœud; recevoir une pluralité de fragments de clé privée de la part d'au moins un autre nœud pour une combinaison en tant que clé privée collective; déterminer que la clé privée collective correspond à la clé privée reconstituée d'un quorum; et générer un signal pour initier la propagation de la transaction de chaîne de blocs proposée à un registre électronique du réseau à chaîne de blocs.
PCT/CA2021/050030 2020-01-13 2021-01-13 Systèmes et procédés pour la sécurité des actifs numériques WO2021142541A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CA3167377A CA3167377A1 (fr) 2020-01-13 2021-01-13 Systemes et procedes pour la securite des actifs numeriques

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202062960654P 2020-01-13 2020-01-13
US62/960,654 2020-01-13

Publications (1)

Publication Number Publication Date
WO2021142541A1 true WO2021142541A1 (fr) 2021-07-22

Family

ID=76863413

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CA2021/050030 WO2021142541A1 (fr) 2020-01-13 2021-01-13 Systèmes et procédés pour la sécurité des actifs numériques

Country Status (2)

Country Link
CA (1) CA3167377A1 (fr)
WO (1) WO2021142541A1 (fr)

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160212109A1 (en) * 2015-01-20 2016-07-21 Ca, Inc. Managing distribution and retrieval of security key fragments among proxy storage devices
US20170011460A1 (en) * 2015-07-09 2017-01-12 Ouisa, LLC Systems and methods for trading, clearing and settling securities transactions using blockchain technology
KR101984254B1 (ko) * 2018-09-21 2019-05-30 김성완 블록체인 네트워크를 구성하는 노드 장치 및 그 노드 장치의 동작 방법
US20190342084A1 (en) * 2018-05-03 2019-11-07 International Business Machines Corporation Blockchain for on-chain management of off-chain storage
WO2019218055A1 (fr) * 2018-05-15 2019-11-21 Kelvin Zero Inc. Systèmes, procédés et dispositifs de transactions de chaîne de blocs sécurisée et sous-réseaux
WO2020051710A1 (fr) * 2018-09-12 2020-03-19 Joe Jay Système et procédé de gestion de jetons de titre numérisés
WO2020176950A1 (fr) * 2019-03-07 2020-09-10 Ziva Connect Pty Ltd Systèmes, procédés et dispositifs pour la fourniture d'un secret

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160212109A1 (en) * 2015-01-20 2016-07-21 Ca, Inc. Managing distribution and retrieval of security key fragments among proxy storage devices
US20170011460A1 (en) * 2015-07-09 2017-01-12 Ouisa, LLC Systems and methods for trading, clearing and settling securities transactions using blockchain technology
US20190342084A1 (en) * 2018-05-03 2019-11-07 International Business Machines Corporation Blockchain for on-chain management of off-chain storage
WO2019218055A1 (fr) * 2018-05-15 2019-11-21 Kelvin Zero Inc. Systèmes, procédés et dispositifs de transactions de chaîne de blocs sécurisée et sous-réseaux
WO2020051710A1 (fr) * 2018-09-12 2020-03-19 Joe Jay Système et procédé de gestion de jetons de titre numérisés
KR101984254B1 (ko) * 2018-09-21 2019-05-30 김성완 블록체인 네트워크를 구성하는 노드 장치 및 그 노드 장치의 동작 방법
WO2020176950A1 (fr) * 2019-03-07 2020-09-10 Ziva Connect Pty Ltd Systèmes, procédés et dispositifs pour la fourniture d'un secret

Also Published As

Publication number Publication date
CA3167377A1 (fr) 2021-07-22

Similar Documents

Publication Publication Date Title
US11588803B2 (en) Systems, methods, and apparatuses for implementing super community and community sidechains with consent management for distributed ledger technologies in a cloud based computing environment
US20230342734A1 (en) Systems, methods, and apparatuses for implementing smart flow contracts using distributed ledger technologies in a cloud based computing environment
US11360963B2 (en) Tracking and verification of physical assets
US11170092B1 (en) Document authentication certification with blockchain and distributed ledger techniques
US20190238316A1 (en) Systems, methods, and apparatuses for implementing intelligent consensus, smart consensus, and weighted consensus models for distributed ledger technologies in a cloud based computing environment
US20190236606A1 (en) Systems, methods, and apparatuses for implementing a virtual chain model for distributed ledger technologies in a cloud based computing environment
US20190236562A1 (en) Systems, methods, and apparatuses for implementing document interface and collaboration using quipchain in a cloud based computing environment
US20210091960A1 (en) Tracking and verification of physical assets
EP4042631A1 (fr) Notification hors chaîne de mises à jour à partir d'une chaîne de blocs privée
US20210194672A1 (en) Partially-ordered blockchain
US20210303713A1 (en) Protecting sensitive data
AU2021210206B2 (en) Index structure for blockchain ledger
US11580098B2 (en) Multi-client transaction validation
US20220329436A1 (en) Token-based identity validation via blockchain
KR20230005353A (ko) 탈중앙화된 데이터베이스에서 허가된 이벤팅
WO2022111175A1 (fr) Récupération de clé dans un réseau à chaîne de blocs par l'intermédiaire d'oprf
US11924348B2 (en) Honest behavior enforcement via blockchain
US20230308276A1 (en) Creating non-fungible token shards
US11314729B2 (en) Multi-candidate data structure for transaction validation
WO2021142541A1 (fr) Systèmes et procédés pour la sécurité des actifs numériques
US20220067028A1 (en) Trustless operations for blockchain networks
US20230412403A1 (en) Secret smart operations in blockchain
US20230081416A1 (en) Anonymous private shared partitions in blockchain networks
WO2023201032A1 (fr) Récupération sécurisée de données hors réseau par des entités de réseau de confiance
WO2023126313A1 (fr) Htlc avec preuve du temps écoulé

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21741229

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 3167377

Country of ref document: CA

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21741229

Country of ref document: EP

Kind code of ref document: A1