CN112968764B - Multilink cipher logic block chain - Google Patents

Multilink cipher logic block chain Download PDF

Info

Publication number
CN112968764B
CN112968764B CN202110194119.7A CN202110194119A CN112968764B CN 112968764 B CN112968764 B CN 112968764B CN 202110194119 A CN202110194119 A CN 202110194119A CN 112968764 B CN112968764 B CN 112968764B
Authority
CN
China
Prior art keywords
blockchain
data
block
key
hash
Prior art date
Legal status (The legal status 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 status listed.)
Active
Application number
CN202110194119.7A
Other languages
Chinese (zh)
Other versions
CN112968764A (en
Inventor
G·艾特内塞
M·T·齐亚拉蒙特
D·特瑞特
B·玛格里
D·文图里
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Accenture Global Solutions Ltd
GSC Secrypt LLC
Original Assignee
Accenture Global Solutions Ltd
GSC Secrypt LLC
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 Accenture Global Solutions Ltd, GSC Secrypt LLC filed Critical Accenture Global Solutions Ltd
Priority to CN202110194119.7A priority Critical patent/CN112968764B/en
Publication of CN112968764A publication Critical patent/CN112968764A/en
Application granted granted Critical
Publication of CN112968764B publication Critical patent/CN112968764B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • 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
    • 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/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0614—Improving the reliability of storage systems
    • G06F3/0619—Improving the reliability of storage systems in relation to data integrity, e.g. data losses, bit errors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/062—Securing storage systems
    • G06F3/0622—Securing storage systems in relation to access
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
    • G06F3/0659—Command handling arrangements, e.g. command buffers, queues, command scheduling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0673—Single storage device
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/085—Secret sharing or secret splitting, e.g. threshold schemes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3218—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • H04L9/3221—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs interactive zero-knowledge proofs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/46—Secure multiparty computation, e.g. millionaire problem
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Human Computer Interaction (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Power Engineering (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Storage Device Security (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Embodiments of the present disclosure relate to a multi-link cryptographic logical blockchain. A cryptographic logic system includes circuitry for rewriting a blockchain in a non-tamper-resistant operation or a tamper-resistant operation using a key held by a trusted party. The blockchain may include a series of blocks protected by a plurality of integrity codes that may prevent non-tamper-proof overwriting by untrusted parties that do not possess the key. In some cases, the key may allow for efficient but tamper-proof overwriting of the blockchain by a trusted entity. Further, in some implementations, tamper-resistant rewrites may be converted to non-tamper-resistant rewrites through multiparty approval.

Description

Multilink cipher logic block chain
The application relates to a split application of Chinese application patent application with a national application number 201780031862.2, an application date 2017, 5 and 23 and an application name of 'multilink cipher logic block chain'.
Priority
The present application claims priority from U.S. patent application Ser. No. 15/596,904, attorney docket No. 15718/112, entitled "Rewritable Blockchain", filed on 5/16 in 2017. The present application also claims priority from U.S. patent application Ser. No. 15/596,899, attorney docket No. 15718/189, entitled "Distributed KEY SECRET for Rewritable Blockchain," filed on 5/16 in 2017. The present application also claims priority from U.S. patent application Ser. No. 15/596,922, attorney docket No. 15718/190, entitled "Multiple-Link Blockchain," filed on 5/16 in 2017. The present application also claims priority from U.S. patent application Ser. No. 15/596,932, attorney docket No. 15718/191, entitled "Rewritable Blockchain," filed on 5/16 in 2017. The present application also claims priority from European patent application 17425018.3, attorney docket A8344EU-ds, entitled "Rewritable Blockchain", filed on month 2 and 17 of 2017. The application also claims priority from European patent application No. 16425086.2, attorney docket A8282EU-ds, entitled "Rewritable Blockchain" filed 8/11/2016. The present application also claims priority from European patent application 16425044.1, attorney docket A8195EU-ds, entitled "Rewritable Blockchain", filed 5.23, 2016.
Technical Field
The present disclosure relates to multi-link cryptographic logical blockchains, and more particularly to data verification, and rewriting in complex real-world systems.
Background
Rapid advances in electronic and communication technology driven by tremendous customer demand have enabled widespread adoption of electronic transactions and record keeping. As one example, electronic money (such as bitcoin) has replaced notes in millions of transactions each year. Improvements in the verification and recordation of such electronic transactions will continue to increase the features and options available to operators engaged in electronic transactions.
Drawings
FIG. 1 shows two example views of a blockchain.
FIG. 2 illustrates two example rewrites to the example blockchain of FIG. 1.
FIG. 3 illustrates an example blockchain processing system.
FIG. 4 illustrates an example blockchain rewriting system.
FIG. 5 illustrates example overwrite management logic.
FIG. 6 illustrates example rewrite logic.
FIG. 7A illustrates two example conflicting searches.
FIG. 7B illustrates an example overwriting of a blockchain using conflicts.
FIG. 8 illustrates an example blockchain portion paired with an example updated blockchain portion.
Fig. 9 illustrates an example dual link blockchain portion.
Fig. 10 illustrates an example hybrid blockchain.
FIG. 11 illustrates an example rewritable blockchain scenario.
Fig. 12 illustrates an example distributed key blockchain overwrite scenario.
FIG. 13 illustrates an example blockchain record maintenance scenario.
FIG. 14 illustrates an example Internet of things rewritable blockchain scenario.
FIG. 15 illustrates an example blockchain loop.
Detailed Description
A blockchain may include a series of blocks of data that include code (such as a cryptographic hash or checksum) that may be consistent with the encoding of the content of previous blocks in the sequence. In some cases, determining multiple different sets of blocks that produce the same integrity code may be unresolvable, computationally complex, or labor intensive enough to defeat attempts to tamper with blockchain content while maintaining self-consistency of the integrity code. However, in some implementations, a trusted party may access a key or a portion of a key such that the trusted party acting alone or with a party that owns the other portion of the key may edit blockchain content without leaving an indication of tampering.
In various systems, multiple parties may use blockchain-based documents or ledgers to maintain tamper-resistant records of events, transactions, or other updates. In some cases, the blockchain may register tampering after a change to the blockchain by an untrusted party (e.g., a party that does not own the key). Thus, the principal can individually verify whether updates by other principals are valid and consistent with previous data block encodings of the blockchain. The self-consistency of the integrity code allows for verification of updates to the blockchain even if the party lacks an archived version of the blockchain for reference. When a rewrite of one or more data blocks in a blockchain does not introduce coding inconsistencies among the integrity output of the blocks and the data block contents in the blockchain, the rewrite may be characterized as preserving the validity of the blockchain.
The blockchain may be protected by an integrity code. When particular data is provided as an input to the integrity code, the integrity code may produce a particular integrity output. In some cases, an integrity code may produce a different integrity output when data other than the particular data is provided as input to the integrity code. In an example scenario, an integrity output of an integrity code generated from particular input data from a data block is stored and the data block is then altered. If the modified data is provided as an input to the integrity code, the integrity code may produce an integrity output that is different from or not consistent with the stored integrity output. Thus, a change may be detected in this example scenario.
A blockchain may include a series of blocks, with each subsequent block in the sequence maintaining an integrity output for the previous block. The series may form a chain of blocks, with each subsequent block maintaining an integrity output generated from data present in an immediately preceding block. Accordingly, if a block is changed, a code that is different from the integrity output stored in a subsequent block may be detected. Since the integrity output is part of the stored data in the block, variations in the integrity output itself can also be detected by encoding inconsistencies. This self-consistency of the integrity code may be used to protect the blockchain from covert tampering.
When protected by an integrity code, tamper-resistant changes may include almost any change in which a non-uniformity of encoding between the integrity output of the integrity code for the blockchain and the data within the blockchain may be detected. For example, the data in the blocks of the blockchain may be hashed, run through checksums, or apply another integrity code. Such a change may be identified as tamper-resistant if the data in the block later found to conflict with the integrity output of the hash, checksum, or other integrity code. Conflicts may occur when the integrity code is applied to the current data in the block when the current data in the block does not produce the same or equivalent integrity output as previously obtained. When a change is made to a block and no later detected code inconsistency with a previously stored integrity output of an integrity code, the change may be non-tamper-proof. In some cases, non-tamper-resistant overwriting may be achieved by replacing the first block with a second block having a different data content that produces the same (or equivalent) integrity output.
In some cases, after logging, some blocks in the blockchain may include information that is no longer suitable for inclusion in the blockchain. For example, a block may expire after a time or after a certain number of subsequent entries, private information may be included in the block, inaccurate entries may be included in the block, information that is detrimental to one or more parties using the blockchain may be included in the block, incomplete information may be included, or other inappropriate information may be included. Accordingly, a trusted party (e.g., a neutral third party, a manager, or a group of individual untrusted parties) may rewrite, remove, or supplement the data included in the block in a non-tamper-resistant manner. The systems and techniques described below implement a technical solution for rewriting blocks in a blockchain to allow trusted parties to edit information from the blockchain without causing the blockchain to fail its intended purpose. For example, parties may use the modified blockchain as if it were an earlier and unmodified blockchain.
Blockchain rewrites may be used to perform low-level (e.g., from a hardware architecture perspective) operations such as memory rewrites, deletions, and additions. Accordingly, these techniques and architectures may improve the operation of the underlying hardware of the computer system because the system may utilize the blockchain protocol for storing data that implements verifiability. For example, operating system software for a security system may be stored in a blockchain payload to protect data from malware, unauthorized parties, unauthorized devices, or other unexpected/unauthorized altered operations.
Additionally or alternatively, a block may represent a minimum delta of data that may be allocated when an update is made. For example, one or more updated blocks may be sent separate from the entire blockchain during an update. However, in some cases, at least the entire blockchain may be allocated with a separate valid update. For example, when a new protected transaction is executed and added to a ledger protected via a blockchain, the entire blockchain (e.g., complete transaction history) may be reassigned with the addition of updated transactions. Blockchain rewriting systems (such as the exemplary embodiments described herein) that allow for truncation, proper resizing, expansion, or other blockchain resizing may improve the operation of the underlying hardware by allowing for adjustment of the data overhead consumed during blockchain updating and allocation.
Additionally, the ability of trusted parties to rewrite blockchains may increase tamper resistance by providing an established rewrite solution. Accordingly, the trusted party may rewrite the existing blockchain without having to discard the blockchain due to improper content. Accordingly, blockchain rewriting significantly improves system efficiency as compared to recreating a new blockchain. Blockchain rewrites can also reduce the likelihood that a malicious party uses a spent blockchain that may be discarded due to improper content to fool the system by informing the system that it did not receive a previous notification of blockchain discard. Accordingly, the rewritable blockchain may have the technical effect of improved data security and tamper resistance. In other words, the techniques and architectures discussed herein include specific, real world applications and improvements of the state of the art in the marketplace.
In addition, the techniques and architectures discussed (including those for rewritable blockchains, distributed keys, double chain blockchains, loops, and others) need to be counter-current to accepted wisdom. In particular, conventional approaches to blockchain distributed databases require blockchain invariance as a fundamental feature. In other words, invariance has been repeatedly explained in previous work as a fundamental feature of the technical value of building blockchains. Invariance in a blockchain is mistakenly treated and indicated as a necessary way to ensure that parties using the blockchain trust the validity of data contained in the blockchain. Accordingly, the technical architecture described herein for adding rewritability to a blockchain violates accepted wisdom. By introducing rewritability while still maintaining high security and thus high technical value of the blockchain, the techniques and architecture of the present invention violate accepted wisdom. Thus, although the techniques and architectures of the present invention are quite different from the teachings of the prior art, the techniques and architectures of the present invention, despite the variability, still provide a high level of trust in the blockchain.
FIG. 1 shows two example diagrams 100, 150 of blockchains, wherein each subsequent block includes an integrity code (e.g., hash, chameleon hash, or other integrity code) that uses the previous block as input. For example, the block B1 104 includes an integrity output IC (B0) in the integrity output field 124 determined from the content of the previous block B0 102 serving as an input of an integrity code. The contents of B0 102 used to determine IC (B0) may include any or all fields within B0, such as data 00 121, [ null ] integrity output field 122 or BlockID 123. The data fields of the block (e.g., data 00 121, data 10 131, and other data fields) may be used to store any type of data. For example, the blockchain data field may hold account data, personal data, transaction data, monetary value, contractual terms, documents, version data, links, pointers, archive data, other data, or any combination thereof.
Fields in a block that are not used to determine the integrity output in subsequent blocks may not necessarily be protected by a blockchain. For example, these fields may be altered without generating coding inconsistencies between blocks. Furthermore, if no integrity output field is used in the determination of the integrity outputs for subsequent blocks in the chain, the blockchain may not have to ensure code consistency between the blocks discussed above, as unprotected integrity outputs may be altered without having to generate evidence of tampering. Accordingly, in various implementations, the integrity output field and at least the protected portion of the data payload of a block are used to determine an integrity output for a subsequent block (e.g., a next block) in the blockchain. Similarly, IC (B1) in integrity output field 125 of block B2 106 may be based on fields within block B1 104, including, for example: any of the integrity output field 124, data field, or BlockID field of block B1 104. In this example, the integrity code IC may be a chameleon hash, as described below.
The blockchain blocks may be locked 152 to each other via the integrity code. In one sense, the blocks are locked to each other because the integrity code output field in each block is based on the content in the previous block at the time the integrity output was generated (e.g., when the block was added to the chain). Accordingly, if a previous block changes after adding the current block, the change will be tamper-resistant, as the change will be inconsistent with the stored integrity output in the current block being encoded. Thus, once a current block having a stored integrity output based on a previous block is added to the blockchain, the contents of the previous block are "locked". In the example blockchain of fig. 1, once B2 106 (including IC (B1) in its integrity output field) is added to the blockchain, the contents of B1 104 may be locked. As a result, the contents of B0 102 locked by B1 104 are further protected by B2 106, because B2 106 prevents B1 104 from being altered in a non-tamper-proof manner.
In an example scenario, as discussed below, a rewritable blockchain may be implemented using discolouration Long Sanlie as an integrity code. However, for a party who does not possess a key that allows editing, virtually any code that is self-evident can be used.
FIG. 2 illustrates two example rewrites 200,250 to the example blockchain of FIG. 1. In the first example 200, the block B2 202 is replaced with a block B2'204 having new content. The new block B2'204 includes content generated using a key such that the integrity output generated when using the block B2'204 as input is the same as the integrity output generated when using the original block B2 202 as input. For example, IC (B2) =ic (B2').
In a second example 250, block B2 202 is removed. Block B1 206 from the original chain may be replaced with block B1'208 to conform to the integrity output code contained in block B3 210. For example, the block B1'208 may include content generated using a key such that the updated block B1'208 may appear to be the correct block (and the correct block in terms of blockchain integrity code) before the subsequent block B3 210. That is, B1 is replaced after deleting block B2 so that B1' can immediately proceed with B3 without violating the blockchain integrity code.
In various implementations, different rewritable blockchains may have different keys. Thus, a trusted party that is able to rewrite a given blockchain may not necessarily be able to act as a trusted party and rewrite a second, different blockchain. The use of different keys for different blockchains may prevent multiple blockchains from being compromised simultaneously by disclosing a single key. However, multiple blockchains using the same "master" key may be generated by the blockchain system (e.g., if a key may be used with multiple different blockchain systems, the key may be the master key). The use of a common key between multiple blockchains may allow for easier management than using different keys for different blockchains.
Additionally or alternatively, the blockchain may have a plurality of different keys that allow non-tamper-resistant editing. In an example scenario, a master key may be used with multiple blockchains, each blockchain having separate keys that do not necessarily allow non-tamper-resistant editing of other blockchains covered by the master key. For example, both blockchains A, B and C may be allowed to be overwritten with the master key MK. Further, blockchain a may have a single overwrite key A1, blockchain B may have a single overwrite key B1, and blockchain C may have a single overwrite key C1. In this example, instead of overwriting with A1 or C1, the processing system may use MK or B1 to overwrite blockchain B.
Further, in some implementations, the grant key may be used to issue a key to a trusted party. For example, the encryption cache EC may include additional keys (e.g., keys a 2..an, bn...bn, C2...cn) for the blockchains A, B and C. The trusted party having the grant key GK decrypts the EC and allows the stored key to be issued to the new trusted party. In some cases, the master key may double as the grant key. For example, the processing system may use the master key to generate block content for overwriting, and the master key may be used as a decryption key for the encryption cache of keys.
In addition, the distributed key scheme discussed below may be applied to the grant key and the master key. In some systems, a trusted party may perform the overwriting of the blockchain separately. However, the same trusted party may combine their keys using any of the distributed key schemes discussed below to obtain the rights associated with the granted key or master key. For example, three separate trusted parties may each perform the overwriting without the consent of the other parties. However, the parties may be forced to combine their keys (e.g., reconcile) to obtain the grant rights and grant their own keys to the fourth party.
In various implementations, increased rights may be obtained by reconciling a particular threshold number of principals, a particular predetermined principal, a principal of a given class, all principals, or another defined group of principals. The distributed key scheme may determine a participation level rule for reconciliation.
In various implementations, keys may be assigned to operators using a key assignment scheme. The key assignment scheme may include an assignment scheme based on operator identity, association, priority, or other basis.
In some cases, the blockchain is marked to indicate that it is to be edited. A flag or field indicating that the blockchain is rewritable may identify trusted parties that have authority to rewrite the blockchain. This may help parties interested in overwriting the blockchain identify trusted parties that can perform the overwriting. For example, a blockchain may be accompanied by metadata describing the purpose of the blockchain, original operating parameters, or other information. The flag for overwriting may be incorporated within the metadata. However, when such metadata is included outside the blockchain, it may be changed without tampered evidence. Allowing metadata to be freely changed may reduce the computational resources required to perform editing and increase the number of participants that may correct metadata errors. In other systems, the processing system may write such metadata in blocks of the blockchain itself, e.g., in dedicated fields or in the data payload of the blocks. Writing metadata to the blockchain itself may prevent unauthorized parties from altering blockchain metadata (e.g., for potentially malicious purposes).
In some implementations, the presence of a trusted party may be kept secret from an untrusted party or a portion of a trusted party. In some cases, the integrity code may not have to provide an indication that the trusted party can edit an entry in the blockchain by checking its operation. That is, the algorithm that generates the integrity code itself does not readily reveal that it supports blockchain rewriting. Keeping the trusted party's store secret may prevent the party from attempting to steal or otherwise obtain the trusted party's key. Furthermore, if a party assumes that the blockchain cannot be edited by another party without significant tampering, the party may have enhanced confidence in the blockchain.
In some implementations, entities with key knowledge can make changes to the blockchain. The key may be owned in whole or in part by an operator, a rights auditor, or other party. Additionally or alternatively, shares (e.g., portions) of the key may be distributed among several separate untrusted parties. The integrity code may be a virtual padlock on a link connecting the two blocks.
The key to open the virtual padlock may be managed according to the requirements of a particular application. For example, in a business negotiation (or other negotiation), a key that allows for modification of proposed contract terms may be held by a neutral third party. Additionally or alternatively, equal portions (e.g., half, one third) of the key may be held by each party in the negotiation so that the terms may be altered under the consent of all parties or defined parties. In a collaborative software design implementation, keys may be distributed in portions to stakeholders to enforce agreements before some software code changes are allowed. Example key distribution schemes, including centralized and distributed schemes, are discussed below. However, other schemes are also possible.
Fig. 3 illustrates an example Blockchain Processing System (BPS) 300.BPS 300 may include system logic 314 to support verification and overwriting of blockchains. The system logic 314 may include a processor 316, memory 320, and/or other circuitry that may be used to implement blockchain processing logic 342. Memory 320 may be used to store blockchain metadata 322 and/or blockchain data 324 used in blockchain rewrites and block additions.
The memory may also include program instructions that implement blockchain processing and one or more supporting data structures (e.g., encoded objects, templates, or other data structures) to support verifying updates to blockchains and detecting evidence of tampering. The memory may also include a flag 323, which may indicate whether a particular blockchain may be edited. In an example, flag 323 may be implemented using bits within a particular field within a blockchain or blockchain metadata to indicate editability. In addition, memory 320 may include a parameter field 326, which may include the identity of contact information for the trusted party, such as name, address, telephone, email, or other contact information.
BPS 300 may also include one or more communication interfaces 312, which may support wireless (e.g., bluetooth, wi-Fi, wireless Local Area Network (WLAN), cellular (third generation (3G), fourth generation (4G), long term evolution advanced (LTE/A)) and/or wireline, ethernet, kilomega Ethernet, optical network protocols.
FIG. 4 illustrates an example Blockchain Rewrite System (BRS) 400. For example, the BRS 400 may be used by a trusted party performing a revision, modification, or supplementation on a blockchain. For example, the supplementing may include adding content to an existing block. Even in blockchains that do not support non-tamper resistant overwriting, an authorized operator may add new blocks, such as new transaction records, to the blockchain. However, changes to existing blocks (including additions) may generate evidence of tampering unless performed by a trusted party that is crowded with a key. The BRS 400 may include system logic 414 to support verification, updating, and overwriting of blockchains. The system logic 414 may include a processor 416, memory 420, and/or other circuitry that may be used to implement blockchain processing logic 442 and Rewrite Management Logic (RML) 441.
Memory 420 may be used to store blockchain metadata 422 and/or blockchain data 424 used in blockchain overwriting and block adding. Memory 420 may further store keys 421, such as encryption key values, trap gate information, or other secret values, which may allow non-tamper resistant overwriting of blockchains. In some cases, the key 421 may be stored in a protected memory 480, such as an encrypted file or data drive, a physically protected drive, a drive coupled to a trigger for anti-theft countermeasures, or a self-deleting drive, to prevent accidental or secret disclosure of the stored key 421. The memory storing the keys may include trusted memory or other memory that is directly or indirectly owned or controlled by a trusted party.
Memory 420 may also include applications and structures, such as encoded objects, templates, or one or more other data structures, to support verification of updates to blockchain and to detect evidence of tampering. The memory may also include a flag 423 that may indicate whether a particular blockchain may be edited and the identity of the trusted party. The BRS 400 may also include one or more communication interfaces 412 that may support wireless (e.g., bluetooth, wi-Fi, WLAN, cellular (3G, 4G, LTE/a)) and/or wired, ethernet, gigabit ethernet, optical network protocols. Communication interface 412 may support communication with other parties that update or perform blockchain transmissions to the blockchain. Additionally or alternatively, the communication interface 412 may support secure information exchange, such as Secure Sockets Layer (SSL) or a public key encryption-based protocol for sending and receiving keys between trusted parties. Furthermore, as discussed below, a security protocol may be used to combine keys between separate untrusted parties each having some portion of the key. The BRS 400 may include a power management circuit 434 and one or more input interfaces 428.
The BRS 400 may also include a user interface 418, which may include a human-machine interface and/or a Graphical User Interface (GUI). The GUI may be used to present data from the blockchain-based verification to an operator of the BRS 400. Additionally or alternatively, the user interface 418 may be used to present the blockchain rewriting tool to an operator.
In some cases, the user interface 418 may include a GUI with tools to facilitate blockchain overwriting and deletion. GUI tools for overwriting may include "what you see is what you get" tools that allow an operator to manipulate the content of the blockchain, such as using a word processor like tool, a web editing like tool, a file browsing like tool, or any combination thereof. Additionally or alternatively, the user interface 418 may include a command line editing tool. Whether text-based or graphics-based, these tools may allow operators to access keys and perform edits on the blockchains they are authorized to. In some cases, these tools may refuse to provide write functionality to operators that lack the appropriate keys to the blockchain they are attempting to edit. However, in some implementations, these tools may allow such unauthorized editing, as this would result in tamper-resistant rewrites that would invalidate unauthorized editing of the blockchain.
Fig. 5 illustrates an example RML 441 that may be implemented in or with circuitry. RML 441 may handle management of keys and implementation of rewrite commands. For example, RML 441 may determine the availability of keys for a particular blockchain and pass those keys to rewrite logic 600 (discussed below) for execution of the rewrite. RML 441 may also handle the receipt of rewrite commands or the receipt of commands for blockchain rewrite automation. 1. Once RML 441 identifies the requested change and the blockchain involved, RML 441 may access the blockchain (502).
The RML 441 may determine whether the memory 420 of the BRS 400 holds a key that allows for overwriting of the accessed blockchain (504). If memory 420 does not store a key, RML 441 may determine whether the key is accessible via secure communications or via a secure combination of portions of the key using communication interface 412 (506). For example, these parts may comprise parts of a key held by separate untrusted parties, but as a group, the trusted parties are formed by combining their parts into a complete key. In some implementations, the key, or portions thereof, may be accessed via secure communications using the communication interface 412, e.g., to prevent interception of the key during communication. If the key is not accessible, RML 441 may indicate via GUI 418 that a non-tamper-resistant overwrite to the blockchain is not available (508). If the key is in memory or accessible via secure communications, RML 441 may prompt the operator to rewrite the blockchain (510).
Additionally or alternatively, RML 441 may automatically obtain the overwrite (511). For example, the rewrites may be obtained from a rewrite queue, embedded within previously received commands, obtained from other block chains, determined from content identified by the system as malicious code or other inappropriate content, or other rewrites automatically obtained by RML 441. The overwrite may be stored as a command identifying a change to be made to one or more blocks and writing the content to the block if the content is to be added by the change. The command itself may include the content to be written to, or alternatively, may include a pointer to the location of the content. RML 441 may invoke rewrite logic 600 (see fig. 6) to perform a rewrite of a block (512). For example, when non-tamper resistant overwriting is available, BRL 441 may invoke overwrite logic 600 to perform overwriting of a block. FIG. 6 illustrates an example rewrite logic 600, which may be implemented in or with circuitry. The rewrite logic 600 may access a blockchain (602). For example, the rewrite logic 600 may access a memory storing a blockchain. Additionally or alternatively, the rewrite logic 600 may access the blockchain via a networking communication interface (e.g., the communication interface 412). In some cases, as described above, rewrite logic 600 may access the blockchain using a protected connection or on a protected memory.
A blockchain may include one or more blocks of data protected by an integrity code. For example, a cryptographic hash function of overwrite protection, such as a hash function without a key for allowing non-tamper-resistant overwriting, chameleon hash, cyclic Redundancy Check (CRC), checksum, or other integrity code, may be used to protect data blocks within a blockchain. In some implementations, individual data blocks may be protected by a particular integrity output consistent with the data content encoding of the block. For example, when an integrity code is applied to the content of a block that produces an integrity output, the integrity output may be consistent with the content encoding of the block. When the integrity output is encoded with the data it protects, the data may be considered valid. As described above, the particular integrity output may be placed within adjacent blocks to prevent or frustrate overwriting of the enterprise graph of data content in a non-tamper-resistant manner. Further, as discussed below with respect to hybrid blockchains, some blockchains may include: portions that may allow non-tamper-proof overwriting (e.g., portions of individual blocks or portions of groups of blocks) and portions that may not necessarily allow non-tamper-proof overwriting by trusted parties.
The rewrite logic 600 may access a key, such as a cryptographic key or trap gate information, that is paired with the blockchain integrity code (604). The key may include data that allows the system (e.g., BRS 400) to calculate a collision, e.g., two different blocks of data that produce the same integrity output for the integrity code. Using the calculated conflict, the device may rewrite the blockchain without the rewritten block being inconsistent with the integrity code encoding. For example, the operator may instruct the BRS 400 to calculate a conflict using the key and rewrite the blockchain.
The rewrite logic 600 may receive a command, e.g., from RML 441, to perform a rewrite on the blockchain (606). For example, the command may have been received from an operator for a trusted party desiring to replace or delete data (e.g., content) from a particular block. The operator may indicate the original data and the replacement data from the input device of the user interface, for example, in a command issued to the BRS 400 through a human-machine interface. Additionally or alternatively, the command to replace data may be received via a network communication interface, for example from a terminal associated with a trusted party. The rewrite logic 600 may receive a command from the RML 441 to perform a rewrite. Further commands to perform the overwriting may originate from automation sources, such as those described above with respect to RML 441.
The rewrite logic 600 may process the key, the replacement data, and the original data to determine additional data for which the replacement data and the additional data produce the same integrity output as the integrity code produced for the original data (608). Accordingly, the replacement data and the additional data can replace the original data without creating evidence of tampering. In an example scenario where the integrity code is a chameleon hash, the key for chameleon hash allows the rewrite logic 600 to determine conflicts for virtually any original data content. In this example scenario, using the key, the rewrite logic 600 may calculate additional data that, when combined with the replacement data selected by the trusted entity, produces the same hash output as any given original data.
The delete operation may be performed in the same or similar manner as the other overwrites. However, instead of selecting replacement data and additional data to be consistent with neighboring block (e.g., blocks immediately after or before the blockchain) encodings. The replacement data and the additional data may be selected to be consistent with other block encodings either further up or further down the blockchain. For example, if the replacement data of a rewritten block conflicts with data of a subsequent block (e.g., a non-adjacent block) further downstream in the blockchain than with data of a block being replaced, one or more subsequent blocks (e.g., one or more consecutive blocks immediately following the rewritten block in the blockchain) may be removed. Additionally or alternatively, if the integrity output field in the replacement data includes an integrity output of a block (which is two or more blocks preceding the block being replaced), one or more blocks preceding the block being replaced may be deleted. Accordingly, when overwriting includes deleting, the overwrite logic 600 may delete one or more blocks before or after the block is overwritten (609).
Once the rewrite logic 600 determines the appropriate additional data, the rewrite logic 600 may generate the additional data (610) and combine the additional data with the replacement data (612). In some implementations, particularly in schemes where the rewritability of the blockchain is kept secret, the presence of additional data may be masked. Thus, a party that does not possess a key will not be able to immediately identify the rewritable blockchain as rewritable simply by noticing the presence of the attached data.
For example, the additional data may be placed in a field within a block containing data having another identified purpose. For example, as discussed below with respect to fig. 8, additional data may be appended to the integrity output field or "randomness" field.
However, in some cases, the rejection of explicitly identifying the blockchain for a particular purpose of additional data (which would otherwise be unintelligible) may be sufficient to prevent an untrusted operator from suspicing that the blockchain they are using is a rewritable blockchain.
In various implementations, the chameleon hash may be identifiable by both trusted and untrusted parties to facilitate verification of the block content.
The rewrite logic 600 may then write replacement data in combination with the additional data in place of the original data (614). For example, the overwrite logic 600 may overwrite original data with combined replacement data and additional data. Because the combined data is consistent with the integrity output encoding of the original data, the overwriting of the original data, at least with respect to the integrity code, may be performed in a non-tamper-proof manner. In other words, the overwrite may be non-tamper-proof even if merely replacing the original data with replacement data would result in a tamper-proof overwrite. As discussed below, double-chain and multi-chain blockchains may be used in some implementations. Accordingly, rewriting the blockchain consistent with the first integrity code encoding of the blockchain may not necessarily result in a completely non-tamper-proof rewrite.
The replacement data may include fully rewritten data, modified versions of the original data (such as revisions of the original data), original data with additions, a complete deletion of the original data, or other data.
The techniques and architectures discussed herein allow for the rewriting of the content of a blockchain that may be implemented in a service (such as a decentralized service) that develops blockchain-based techniques. Non-tamper-proof, validity preservation, or other types of overwriting of blockchains may be used in various scenarios. For example, these scenarios may include: deleting inappropriate content from the blockchain, providing support for applications using rewritable storage, adhering to government regulations such as "forgotten rights" or other scenarios.
The techniques and architectures discussed herein (including for rewritable blockchains, distributed keys, double-chain blockchains, loops, and other techniques and architectures) may be used in conjunction with various blockchain consistency techniques. For example, in some cases, a rewritable blockchain may be used with proof of a work-based consistency mechanism. Accordingly, upon finding a solution to a predefined challenge and displaying a proof of work for the solution, an operator (e.g., an untrusted operator) may be granted the ability to attach blocks to the rewritable blockchain. In some implementations, a consistency mechanism based on "actual bayer fault tolerance" may be implemented. In addition, some implementations may use a "smart contract" type negotiation mechanism in which an operator may append blocks in displaying compliance with terms or rules of a smart contract. The integrity code may be implemented independent of the particular coherency mechanism used in the blockchain. Accordingly, the integrity code (including the integrity code supporting blockchain rewriting) may be implemented using virtually any blockchain consistency mechanism.
In some implementations, a color change Long Sanlie function may be used by the system (e.g., BRS 400) that may allow for efficient determination of hash bursts given a key. In some cases, the system may use a chameleon hash to grant a trusted entity, multiple separate untrusted parties that together make up the trusted party, or other entities the ability to tamper-proof rewrite the blockchain.
In some implementations, the hash function may maintain collision resistance even after a large number of collisions of polynomial stages are found (using keys). This attribute may be referred to as key exposure discretion. As discussed below, the conversion may be used to convert the chameleon hash function into a hash function that additionally satisfies the key exposure degrees of freedom.
Fig. 7A illustrates two example conflicting searches 700, 720. For hash functions lacking the key (H), it may be difficult to find a collision. Accordingly, X and X 'are found such that H (X) =h (X') can be extremely difficult (700). However, for color change Long Sanlie CH, the device that owns key 722 may be able to find X and X 'such that CH (X) =ch (X') (750).
FIG. 7B illustrates an example overwriting of blockchain 760 using conflicts. Block chain 760 includes blocks 762, 764, 766, and 768. Block 766 includes an integrity output 784. When two different blocks 766, 770 with different content produce the same integrity output 786 for an integrity code, the blocks 766, 770 are conflicts for the integrity code (796). Block 766 may be replaced with block 770 and remain consistent with the encoding of subsequent block 768 because blocks 766 and 770 produce the same integrity output. However, if block 770 does not contain an appropriate integrity output (e.g., integrity output 784), block 770 will not be consistent with block 764 encoding. By accessing the key of the integrity code, the principal can specify the integrity output present in block 770 (797). Accordingly, by including integrity output 784, block 770 may be made consistent with block 764 encoding (798). Block 770 still coincides with block 768 encoding because block 770 conflicts with block 766. Alternatively, if block 770 is instead constructed to include integrity output 782, the insertion of block 770 may be used to delete block 764 (799). With integrity output 782, block 770 is encoded with block 762 (as its previous block) and block 768 (as its immediately following block). Accordingly, block 764 may be removed from the blockchain without evidence of tampering.
In some real world applications, only additional ledgers may be implemented for most parties that allow overwriting (for maintaining security). To enable real world applications, the overwriting may be limited so that it may be performed by a trusted party or in a defined environment. Two examples of real world applications are discussed below in connection with fig. 13 and 14.
In some cases, applications such as smart contracts or overlay applications may not necessarily work and scale if the blockchain cannot be edited in a save-efficient or non-tamper-proof manner. The smart contract may include a series of instructions (e.g., calculation instructions) that the party executes in exchange for compensation.
In addition, the rewritable blockchain may provide support for updates to the applications that the blockchain is used to protect. If the blockchain-based system is checked in detail after startup, the blockchain may be rebuilt using the rewritable blockchain to reflect the detailed check.
Annotating
For a string x, its length can be represented by |x|; if X is a set, then |X| can represent the number of elements in X. When X is randomly selected among X, the selection may be expressed as x+$x. When a is an algorithm, y+$a (x) can represent the running of a on input x and output y; if A is randomized, y is a random variable and A (x; r) may represent the operation of A on the input x and randomness r. If A is randomized and r ε {0,1} for any input x, algorithm A is Probabilistic Polynomial Time (PPT). The calculation of A (x; r) may be terminated after up to the poly (|x|) step.
The security parameters may be expressed asFunction v:/>May be negligible (or simply negligible) within the security parameters if its vanishing speed is faster than the inverse of any polynomial in κ (i.e., ν (κ) =κ - ω (1)). For a random variable X, P [ x=x ] may represent the probability that X assumes a particular value X e X (where X is the set defining X). Given two ensembles x= { X κ}κ∈Ν and y= { Y κ}κ∈Ν, x≡y may represent that the two ensembles are identically distributed, and x≡ c Y may represent that the two ensembles are computationally indistinguishable, e.g. for a given scene.
Public key encryption
Public Key Encryption (PKE) schemes are a technique by which information can be exchanged publicly between two or more parties without necessarily requiring public encryption keys, or other secrets. Furthermore, PKE may be implemented without requiring the exchange of a full public key or other secret among the parties. In an implementation, PKE may be performed using the algorithm tuple pke= (KGen, enc, dec) defined as follows: (1) Probability algorithm KGen will be a security parameterAs input, and outputs a public key/key pair (pk, sk). (2) The probabilistic algorithm Enc takes as inputs the public key pk, the message M e M, and the implicit randomness ρe R pke, and outputs the ciphertext c=enc (pk, M; ρ). The set of all ciphertext is represented by C. (3) The deterministic algorithm Dec takes as input the secret key sk and the ciphertext C e C and outputs m=dec (sk, C), which is equal to some message M e M or the error symbol t.
In some cases, PKE or other secure exchange schemes may be used by separate untrusted parties to combine portions or shares of the keys of the integrity code to generate a complete key capable of implementing non-tamper-resistant overwriting of the blockchain. In some cases, a secure exchange scheme may be used to ensure that a third party is not able to obtain part of the key by observing the exchange. Additionally or alternatively, a secure exchange scheme may be used by the separate untrusted party to prevent other separate untrusted parties from acquiring multiple parts during the exchange. For example, in an unprotected exchange, once a separate untrusted party collects parts from other untrusted parties, the collecting party becomes irrevocably a trusted party. However, in a secure exchange, such as how PKE is implemented, an untrusted party may collect portions of the key from other untrusted parties without actually knowing the contents of the various portions collected. Accordingly, the portion of the collection of keys from other individual untrusted parties does not necessarily result in the collector being a trusted party. Thus, the individual untrusted parties may together constitute a trusted party, but after expiration or other invalidation of the combining key, the individual untrusted parties return to their separate untrusted states until they again agree to combine their respective parts. In some cases, the combined key may expire after a predetermined period of time or after a predetermined amount of overwriting is performed. For example, the combining process may specify a predetermined expiration parameter that may depict the number of rewrites, the number of blocks that may be rewritten, the duration, the amount of data that may be changed, a particular list of blocks that may be rewritten, one or more events occurring, or a combination thereof.
In other cases, the keys may be combined in the following manner: the co-working parties may determine additional content that is used to perform non-tamper-resistant overwriting of the blocks. However, neither party has to collect the complete (but encrypted) key so that neither party can determine the additional content on behalf of the other party. Instead, each individual untrusted party within the group that constitutes the trusted party may calculate a portion of the additional content (or perform some portion of the processing). The end result produced by the joint efforts of the individual untrusted parties is used as additional content to support non-tamper-resistant overwriting of individual blocks. For any subsequent rewrites, an individual untrusted party may collaborate again for each particular block designated for overwriting by the group of trusted parties.
The separate untrusted parties may be different operators (e.g., entities, institutions, devices, or other parties) having different operator profiles on a single system. Additionally or alternatively, individual untrusted parties may be distributed over multiple systems. Individual untrusted parties may store their respective key sections in different memory locations, which may have the same or different security features. The respective memory locations may be associated with respective ones of the individual untrusted parties. For example, the memory locations may correspond to memory devices owned or maintained by respective ones of the individual untrusted parties. Similarly, the trusted party may maintain an associated memory location. In some cases, the memory location may be used as an identifier (in whole or in part) of the principal. For example, a memory location for a trusted party may be used to confirm that a key is being controlled by the appropriate trusted party (e.g., access control, read/write control, or other control). For example, if a key is not accessed from a trusted memory location (e.g., a memory location used, indirectly controlled, maintained, or owned by a trusted party), the key may be rejected by the system. Similarly, portions of the key held by an untrusted party may be bound to a specific memory location.
The following describes example implementations that can be used to support the techniques and architectures described above. For example, implementations discussed below may be used to construct a chameleon hash. However, other integrity codes may be used for non-tamper-resistant blockchain rewrites.
Non-interactive zero knowledge
If R {0,1} *×{0,1}* → {0,1} is the NP relationship with respect to pair (x, y), the corresponding language is utilizedNon-interactive arguments for R may allow prover P to convince verifier V that public element y belongs to language L (where both P and V are modeled as PPT algorithms). Prover P may be facilitated by knowing evidence x for y ε L.
Example attribute 1 (non-interactive demonstration). The non-interactive demonstration for NP relation R is tuple nia= (I, P, V) of the effective algorithm as specified below.
Omega. Inter $ I (1 κ): probability algorithm I will security parametersAs input, and outputs a Common Reference String (CRS) ω.
Pi≡≡ P (co-ordinates of the total number of the components of the system, x, y): the probability algorithm P takes CRS ω and pair x, y as inputs, such that R (x, y) =1, and returns proof pi of membership for y e L.
D=v (ω, y, pi): deterministic algorithm V takes CRS ω and pair (y, pi) as inputs and returns decision bit d e {0,1}.
In some cases, the non-interactive demonstration may satisfy three known properties: integrity, zero knowledge, and reliability, as will be discussed below. CRS may be used to facilitate non-interactive zero knowledge conditions.
The integrity attribute may establish that the honest prover (holds valid evidence x) should be able to trust y e L for the verifier.
Example attribute 2 (for demonstrated integrity). Making nia= (I, P, V) a non-interactive demonstration for NP relation R. If R (x, y) =1 for all pairs (R, y), the NIA can satisfy the integrity, there is a negligible function v: So that P [ V (ω, y, pi) =1: pi+$p (ω, x, y); omega+$ I (1 κ) ]. Gtoreq.1-v (κ).
Zero knowledge. The zero knowledge attribute indicates: a potentially malicious verifier may not necessarily obtain knowledge of the evidence, which cannot be obtained by itself. This may be helpful for non-interactive zero knowledge (NIZK).
Example attribute 3 (zero knowledge). Making nia= (I, P, V) a non-interactive demonstration for NP relation R. If there is a PPT simulator S = (S 1,S2), then NIA satisfies zero knowledge so that for all opponents A there is a negligible function v: Make/>
The extractability was simulated. Reliability indicates that: difficulty for malicious provers to be elementsGenerating an acceptable proof pi. In some cases, reliability may still hold even though a malicious prover may access the simulated proof for a true statement. In some implementations, a stricter scheme may allow provers to see proof of possible false statements; see discussion below.
Example attribute 4 (true simulation extractability (tSE)). Let nia= (I, P, V) be the NIZK for NP relation R, where zero knowledge simulator s= (S 1,S2), and let f be the effective computable function. If a PPT extractor E is present, NIA satisfies the true simulation f extractability (abbreviated as f tSE) such that for all PPT opponents A, there is a negligible function v: So that
Where interrogator oτ takes as input pair (x i,yi) and returns pair (x i,yi) as S 2(τ, yi), as long as R (x i,yi) =1 (otherwise return Σ), and Q is the set of all values y i required for interrogator O T.
Note that in the above example attribute 4, only the adversary is allowed to see the simulated proof for the true statement. The stronger variant ensures that even if an adversary is allowed to see a simulated proof for a potentially spurious statement, the simulated extractability is still valid. The latter attribute is also named robust NIZK.
As indicated in tSE, NIZKs are significantly more efficient to construct, indeed, it is often possible to combine NIZKs (such as Groth-Sahai NIZKs) with CCA-safe PKE schemes to obtain them.
Chameleon hash function
The chameleon hash may comprise a cryptographic hash function for which devices possessing a key may compute a conflict. Without the key, the chameleon hash may be designed such that it is computationally impractical to find a conflict. However, knowledge of the key (e.g., cryptographic key, trap gate information, or other secret) may allow for the actual generation of collisions computationally for the hash function. Knowledge of the key may allow for conflict determination and generation for blocks containing at least some arbitrary content.
Color-changing Long Sanlie for secret coin
Example attribute 5 (secret coin color Long Sanlie). The secret coin chameleon Hash function is the tuple ch= (HGen, hash, HVer, HCol) of the effective algorithm specified below.
$ HGen (1 κ): the probability key generation algorithm HGen will be a security parameter As input, and outputs the public hash key hk and the key tk.
$ (H, ζ) +$hash (hk, m): the probabilistic hashing algorithm Hash takes as input a Hash key hk, a digest M e M, and an implicit random coin R e R hash, and outputs a pair (h, ζ) of a Hash output h and a check string ζ.
D= HVer (hk, m, (h, ζ)): the deterministic verification algorithm HVer takes as input the message M e M, the candidate hash output h, and the check string ζ, and returns a bit d equal to 1 (otherwise d is equal to 0) if (h, ζ) is a valid hash/check pair for message M.
Pi '≡$ HCol (tk, (h, m, ζ, m'): the probabilistic collision finding algorithm HCol takes as input the trap gate key tk, the valid tuples (h, M, ζ) and the new message M '∈m, and returns a new check string ζ', such that HVer (hk, M, (h, ζ))= HVer (hk, M ', (h, ζ')) =1. If (h, ζ) is not a valid hash/check pair for message m, then the algorithm returns t.
The hashing algorithm may be random and when some message m is input, it may together produce a hash output h and a verification value ζ that helps verify the correct computation of the hash for a given public hash key. However, the random coin of the hashing algorithm is secret. One particular case is that the check value ζ consists of a random coin used to generate h, since once m and r are fixed, the hash calculation becomes deterministic; this chameleon hash function is referred to as a common coin and is formally defined below.
Example attribute 6 (common coin color change Long Sanlie). The common coin chameleon Hash function is a set of algorithms ch= (HGen, hash, HVer, HCol) as specified in example attribute 5, with the following differences:
Upon input of the Hash key hk and the message M e M, the Hash algorithm Hash returns a pair (h, R), where R e R hash represents the implicit random coin used to generate the Hash output.
The verification algorithm HVer, given as inputs the Hash key hk, the message m and the pair (h, r), returns a 1 if and only if Hash (m; r) =h.
Since the validation algorithm simply re-runs the hashing algorithm, some implementations may delete the validation algorithm from the CH in the case of a public coin chameleon hash.
Example attribute 7 (correctness for chameleon hash). Let ch= (HGen, hash, HVer, HCol) be the chameleon Hash function (secret or public coin) with message space M. If there is a negligible function v for all mε M: CH satisfies correctness such that:
P[HVer(hk,m,(h,ξ))＝1:(h,ξ)←$Hash(hk,m)；(hk,tk)←$HGen(1κ)] ≥1-ν(κ)。
almost any chameleon hash may be used to generate the common coin anti-collision chameleon hash. However, in some cases, the secret coin chameleon hash function may be used for the same applications as public coin applications, in particular for constructing chameleon signatures and online/offline signatures. However, for secret coin chameleon hashing, the system may store a verification value ζ (instead of the randomness r) in order to verify the hash output. Furthermore, hash verification may not necessarily include re-computing the hash.
For some applications of chameleon hashing, the anti-collision capability may not necessarily be sufficient. While the hash function is anti-collision, the party that sees the collision for the hash function can find other collisions or recover the key. Increased anti-collision capability can be used to make it more difficult to find collisions, even after witnessing a large number of collisions at the polynomial level.
Another type of chameleon hash may include a "signed" hash function, where the hash algorithm takes as input an additional value λ called a sign or tag. In some cases, the signed hash function may be resistant to key exposure. For example, for some signed hash functions, even given access to a interrogator that outputs a conflict for other arbitrary signs λ+.λ, the system cannot find a conflict for the "new" sign λ *. The identity-based chameleon hash functions may at least partially address the key exposure problem because they use trusted parties to process identities.
Increased resistance to extrusion. Examples of collisions for secret coins or public coin hash functions are tuples h, (m, ζ), (m ', ζ'), such that m+.m 'and (m, ζ) and (m', ζ ') (respectively) are valid hash/check pairs for m and m'. For the chameleon hash function, there is a security feature that indicates that it should be difficult for the hash function to find a conflict even given access to the conflict-finding algorithm (returning a conflict for the adaptively selected hash output).
Example attribute 8 (increased anti-collision capability). In an example scenario, ch= (HGen, hash, HVer, HCol) may be a (secret or public coin) color change Long Sanlie function. If there is a negligible function v for all PPT breakers B: CH may meet the increased anti-collision performance such that:
Where set Q is the set of all hash outputs queried by B to its interrogator, and interrogator O hk,tk is defined as follows: running HVer (hk, m, (h, ζ)) in the case of a conflicting query of the input form ((h, m, ζ), m') =d; if d=1, return HCol (tk, (h, m, ζ), m'), otherwise return t. If B is not allowed to query interrogator O hk,tk, then CH may be collision resistant without having an increased anti-collision capability.
Universal transformation
An example chameleon hash function that provides increased anti-collision capability includes a hash function based on the Nyberg-Rueppel signature scheme. The security of these example chameleon hash functions may be demonstrated using discrete logarithmic assumptions within the "general set model".
The following example was constructed for color change Long Sanlie based on Nyber-Ruepple principles. For various complexity environments, increased anti-collision capability may be achieved in an unspecified manner. The conversion may be based on the CPA secure PKE scheme and the tSE NIZK.
Let ch= (HGen, hash, HCol) be the public coin chameleon Hash function (with extinguishing space M hash and random space R hash), pke= (KGen, enc, dec) be the PKE scheme (with message space R hash and random space R pk e), and nia= (I, P, V) be the non-interactive demonstration system for language.
(1) An example secret coin chameleon hash function CH *＝(HGen*, Hash*,HVer*,HCol*) may be specified as follows:
HGen *(1κ) runs (hk, tk) +$ HGen (1 κ),(pk,sk)←$KGen(1κ), and ω+$ I (1 κ). The pair (hk *,tk*) is returned so that hk *: = (hk, ω, pk), and tk *: = (tk, sk).
Hash *(hk*, m): the random value R e R hash is sampled and Hash (hk, m; R): =h is run. The random value ρ ε R pke is sampled and c: =enc (pk, R; ρ) is run. Computing evidence pi≡ζp (ω, x, y), where x: = (r, ρ) and y = (pk, c, hk, h, m), and back (h, ζ) such that ζ = (c, pi).
HVer *(hk*, m, (h, ζ)): the ζ= (c, pi) is resolved and the output of V (ω, y, pi) is returned, where y= (pk, c, hk, h, m).
HCol *(tk*, (h, m, ζ), m'): first run HVer (hk *, m, (h, ζ)) =d; if d=0, then output t, otherwise decrypt the randomness R: =dec (sk, c), calculate the collision R '+$ HCol (tk, (h, m, R), m'), sample the randomness p '∈r pke, and encrypt the new randomness c': =enc (pk, R '; p'). Evidence pi '≡$ P (ω, x', y ') is calculated such that x' = (r ', P') and y ': = (pk, c', hk, h, m ') and ζ': = (c ', pi') is returned.
The system may be implemented using a variety of protocols. For example, a system based on a common coin chameleon hash function may implement the Sigma protocol. The Sigma protocol is an interactive attestation scheme in which "attestation" and "verifier" participate in a multi-level communication. During multi-level communication, the prover may trust the verifier that the prover possesses specific information. To implement tSE NIZK, a CCA-safe PKE NIZK attestation system may be used. When the encryption scheme is secure against the predefined ciphertext attack, the encryption scheme is CCA-secure.
Example blockchain
In an example scenario, a block is a triplet of the form b= (s, x, ctr), where s e {0,1} κ, x e {0,1}, andWherein if it
B is valid. Where H {0,1} - {0,1} κ and G: {0,1} - {0,1} κ are anti-collision hash functions, and the parameters areAnd/>The difficulty level of the block and the maximum number of hash queries that the user is allowed to make within a round of protocol, respectively. /(I)
An example blockchain C may be a chain (or sequence) of blocks. In this example, the rightmost block is the Head of the chain, denoted by Head (C). Any chain C with a header Head (C): = (s, x, ctr) can be extended to a new longer chain C ': = c||b ' by appending (valid) blocks B ': = (s ', x ', ctr '), such that s ' =h (ctr, G (s, x)); the Head of the new strand C ' is Head (C ')=b '. Chain C may also be empty and is denoted c=epsilon. The function len (C) represents the length (number of blocks) of the chain C. For a chain C of length n and any k.gtoreq.0,Is a chain resulting from removing the k blocks to the far right of C, and similarly,/>Is a chain that removes k blocks to the far left of C, if k.gtoreq.n, then/>And/>If C is a prefix of C', it can be expressed as/>Furthermore, the difficulty level D may vary among blocks in the chain.
Example rewritable blockchain
In the example rewritable blockchain scenario for the example blockchain above, the block may be tuple B = < s, x, ctr, (h, ζ) >, and the new component (h, ζ) may be a hash/check pair for the secret coin color change Long Sanlie. The function G may be a secret coin color change Long Sanlie ch= (HGen, hash, HVer, HCol). The verification discussion for this modified block may be:
for example, the field of color change Long Sanlie may be adjusted to a size comparable to the application of the blockchain by hashing the demonstrated input Hash with a regular anti-collision Hash of the desired output size.
Verification of the chameleon hash may be calculated using its own verification function (HVer). However, some hash functions (such as those without keys) may be verified by pre-computing the hash.
In some cases, a chain revision algorithm, such as example algorithm 1, may take as inputs the following: chain C to be revised, a set of indices representing the locations of the blocks being revised (in chain C), and another set containing new x' values for the various blocks being revised. The example algorithm may accept as input a chameleon hash trap gate key tk. The intuitive knowledge of the algorithm is that for each block to be revised, the hash for the block is computed against its new content x'. A new chain C' is created by replacing the original block with the modified counterpart. At the end of the execution of algorithm 1, the central authority may broadcast the new revision chain as a special chain so that users of the system employ the new revision chain in place of other chains, even longer chains for example.
/>
In some cases, the impact mutation-resistant hash function may be sensitive to key exposure. For example, for some anti-collision discolouration Long Sanlie functions, the key may be retrieved after viewing the collision for that function. Note that the two proposed algorithms (algorithms 1 and 2) may expose one or more conflicts for revisions. For example, the algorithm may expose conflicts for revisions or for each block that is altered or revised. In some cases, the system may implement a chameleon hash with increased anti-collision capability to avoid key exposure. However, some systems may rely on the controlled level of collision avoidance and conflict exposure.
In some cases, the trusted party may remove the entire block from the rewritable blockchain. For example, use cases may be extensibility maintenance, such as saving disk space and computing power associated with processing larger (non-revised) chains that may be used. To remove block B i, block B i+1 may be modified by dividing s i+1←s1. The system may then calculate a conflict for B i+1, which generates a new block B i'+1, which may be inserted into the chain to replace block B i+1, which places the chain in a code consistent state. At the end of execution of algorithm 2, the central authority may broadcast the new reduced chain as a special chain so that users of the system replace other chains with new revised chains.
Decentralized key exchange
In some implementations, candidate trusted authorities may be explicit. For example, in some fusion transactions, a bank or bank officer may hold a key for an integrity code, such as a color change Long Sanlie. In some cases, peer applications may not necessarily have such explicit candidate trusted parties. This situation can be addressed by using a decentralized key distribution scheme. In this case, the trap gate key may not necessarily be known by any individual party, but rather be shared among some fixed set of users, such that these users together constitute a trusted party. When a revision block is needed, users from the collection participate in a secure multiparty computing protocol (MPC) to compute algorithm 1.
In some cases, a secure key exchange (such as an MPC) may operate by having parties send a start signal. In some cases, some parties may be honest or dishonest. The honest party may strive to work with other parties to obtain the full key. However, a dishonest principal may wish to disrupt this process by sending a false share. Nevertheless, secure key exchange may still involve receiving shares with honest and dishonest parties. After receiving the "start" signal from all honest parties, the system may run (hk, tk) +$ HGen (1 κ) and send hk to dishonest parties. Accordingly, each party in exchange P i may receive shares. Because the shares sent by dishonest parties may constitute a disqualifying set, the system may construct a complete set of shares from dishonest parties (s 1...sn). Once the complete set is formed, the system may send s i to each honest party.
The system may receive shares s i from each party P i and reconstruct the trap gate key tk: =rec (s 1,···,sn). The share of dishonest parties is selected by dishonest parties. When a "calculate collision" signal is received for pairs ((h, m, ζ), m ') from all honest parties, ζ' ≡ HCol (tk, (h, m, ζ), m ') is calculated and sent (h, m, ζ) and ζ' to dishonest parties. Upon receiving an "OK" signal from a dishonest principal, the system may forward the value ζ' to all dishonest principal. However, if "OK" is not received, the system may forward t (e.g., a run-time fault indicator) to all honest parties.
In an example scenario, an example system may include n active users. The subset U e n of users can hold shares of the trap gate key K. The subset U of users may perform a decentralized key generation protocol. At the end of the run, users in subset U get the share of tk s i. When block B k = < s, x, ctr, (h, ζ) > is revised as a modified blockAt that time, the user may examine their own blockchain and find block B k. The users in the subset may then perform a distributed hash collision protocol to calculate the value/>The user can input their own private shares s i, values s, x, h, ζ, and/>, of tkAt the end of the protocol, users in subset U receive the block/>Values/>The user can use the block/>Replacement block B k updates their own blockchain and broadcasts this new rewritten chain. In some cases, the user may broadcast the new chain as a new special chain. In some implementations, overwriting of blockchains may occur infrequently. The use of special chain broadcasts may not necessarily cause frequent breaks. However, in various implementations, both special and non-special transmissions may be used.
An example selection for set U is to pick a subset of online users. However, the choice may depend on the application. Some users in U are also handled as malicious in nature and their goal is to learn tk or prevent the problem of their correct reconstruction.
Specific examples
In some example implementations, the system may be constructed using color change Long Sanlie (CH), which is described in Giuseppe Ateniese and "On the key exposure problem in chameleon hashes" of b.de Medeiros (SCN, pages 165-179, 2004). As described above, example CH constructs that may be implemented have a dual Nyberg-Rueppel signature and increased anti-collision capability, such as a CH that shows example attribute 8. The parameters for this function may include random primes q and p=2q+1. Parameters may also includeA generator g of subgroups of the second order remainders Q p and an anti-collision hash function H.
$ HGen (1 κ): the key is the random value tk e 1, q-1, and the hash key is hk≡g tk.
H: =hash (m, r, s): to use random valuesThe message M e M is hashed, calculated and returned h: =r- (hk H(m,r)g8 mod p) mod q.
{0,1}: = HVer (h, m, r, s): for verification, only Hash (m, r, s) =h is returned.
· (R ', s ') $ HCol (h, m, r, s, m '): to calculate the collision for message m ', a random number k ε [1, q-1] is chosen, r ' ≡h+ (g k mod p) mod q is calculated, and s ' ≡k-H (m ', r '). Tk mod q is calculated. Return (r ', s').
Semi-honest scenes. In an example scenario, users in subgroup U are semi-trusted. In this scenario, the semi-honest users in subgroup U may be trusted to execute the protocol and operate according to rules, e.g., users in subgroup U may be relied upon to enter the correct shares. For this semi-honest scenario, a sum-based n-threshold key sharing scheme is described below:
sharing:
the dealer selects the secret s and n shares s i such that
N principals P i receive their respective key shares s i.
Reconstruction stage:
The dealer receives share s i from principal P i and reconstructs the key
In an example scenario, user U e U individually selects random number x i e [1, q-1] as their respective key share and broadcasts value y i←gxi. The hashed trap gate key may beX i mod q, and the hash key may be hk≡g tk. The protocol may be non-interactive in that it may not necessarily require any exchange of messages between users. Furthermore, a set without n-1 users may have to be able to reconstruct tk. Furthermore, the system may hinder attempts to learn information about tk because the shares are only random elements.
In an example scenario, user U e U may agree on a pair ((h, m, r, s), m'). The user individually selects the corresponding random number k i e1, q-1, broadcasts g ki, and then calculatesIn some cases, the system of individual users may calculate H ' ≡h (m ', r '), without having to receive additional input from other users in the subgroup. To calculate s ', the user may execute the MPC protocol to calculate the multiplications s "≡h ' ·tk by entering the user's corresponding tk shares. The user may calculate the difference s' ≡k-s "by entering the previously selected share of k to execute an additional and further MPC protocol.
Dishonest scenes. Additionally or alternatively, example scenarios may include some users, entities, parties, devices, or other entities, which may be dishonest. For example, dishonest users may deviate from the protocol specification in an attempt to learn key shares of other users. To maintain security in such a scenario, a robust secret sharing scheme for key sharing may be implemented. In some cases, the robust secret sharing may support a threshold number (e.g., integer t < n) of potentially dishonest users. Users performing a robust secret sharing can reconstruct the correct key from a given share, even if (up to) a threshold number of users are dishonest. The robust secret sharing scheme may be implemented using a Shamir secret sharing scheme plus a Reed-Solomon (RS) error correction code. In the key reconstruction phase, an RS code is used in each share before reconstructing the key. In some cases, shamir secret sharing schemes paired with RS error correction can operate with up to one third of users actively dishonest. In some example approaches, any dishonest user threshold may be supported, for example, this may include a threshold that allows less than most users to be dishonest.
The users in the subgroup can select and parse the corresponding random string ρ i e intoSo that the subgroups can agree on the polynomial P (X). The polynomial may be defined as P (X): =tk+p 1·X+P2·X2+···+Pn-1·Xn-1, where/> And P (0) = Σ i∈[n]tki. To allocate shares, the user may execute the MPC protocol to calculate the share for each user i. For user i, the corresponding share may be sum/> During the reconstruction phase, the user's shares may be decoded using the RS code.
In some implementations, sharing schemes may be used, such as those described in Tal Rabin and Michael Ben-Or, pages "Verifiable secret sharing and multiparty protocols with honest majority(extended abstract)"(ACM STOC,, pages 73-85, 1989). For example, the sharing scheme discussed therein may use a broadcast channel and be able to operate successfully with the integrity of most parties.
Furthermore, some implementations may use schemes with optimizable share sizes described in "Essentially optimal robust secret sharing with maximal corruptions"(IACR Cryptology ePrint Archive,2015：1032,2015 of Allison Bishop, valerio Pastro, rajmohan Rajaraman, and DANIEL WICHS). For example, the sharing scheme discussed therein may have a defect setting that lacks a linear correlation between share size and number of parties n. In some cases, the share size may increase linearly with k, where 2 -k is the probability of failure.
Block level structure
FIG. 8 illustrates an example blockchain portion 800 paired with an example updated blockchain portion 850. In this example, the outer hash H of the blockchain portion 800, 850 is paired with the inner hash G. The internal hash may be nested within the external hash such that the output of the internal hash is provided as input to the external hash. In this example, the blockchain portion, the internal hash G, may be a color change Long Sanlie function. The external hash H may be a chameleon hash function or another hash function. These blocks may include HashPrev (e.g., previous hashes) 802 fields, which may include a repository, e.g., s', s, for holding the hash output corresponding to the previous block. Blocks 820,822,832, 834 may not necessarily include a hashed output of their own inputs. However, the hash output for a block is shown above the block to indicate the link 803 to the next block (e.g., link 803 between blocks 832 and 820 and between 820 and 834). Blocks 820,822,832, 834 may also include a payload 804 field that may hold data protected within the block (e.g., x', x "), such as transaction information, smart contract content, a value, a monetary denomination, or other protected data.
Counter fields 806, such as ctr, ctr', ctr, may also be included. The counter field 806 may include a counter or random number that may be used for proof of work (PoW) calculation, billing, block tracking, or other purposes. In a cryptocurrency implementation, a PoW may be used to verify the validity of a monetary reward for a particular party. The PoW may include a solution to the computational problem, where the calculation of the solution is complex but the calculation of the validation is relatively simple. PoW may also be used in intelligent contracts to verify that a particular party has completed their obligations in the contract.
The randomness 808 field may be updated when the block is revised, for example, when a conflict is calculated. In some cases, the randomness field may hold third data (e.g., r', r "), which may be paired with replacement data to allow non-tamper-resistant overwriting of the blockchain. When block 820 is revised, the values s ', x', ctr 'and r' may be replaced by s ',x', ctr 'and r'. In an example scenario, s ' and ctr ' may not necessarily be modified, as ctr ' may be used by the external hash to calculate PoW and is a link to the previous block that remains unchanged. Using the chameleon hash key for the internal hash function G, a collision can be found such that G (s ', x', and r ')=g (s',x ', and r'). Accordingly, H (ctr ', G (s', x ', and r')) =h (ctr ', G (s',x ', and r')). As a result, s "can be kept unchanged by the revision. The updated block portion 850 includes a replacement block 822 having values x 'and r'.
In some implementations, the system may delete the Block by replacing s i+1 with s i in Block i+1 and then running the revision process on Block i+1. Additionally or alternatively, the system may delete a Block by pointing the value s i+1 in Block i+1 to Blcok i-1. In some cases, the ctr value in Block i-1 may be changed to maintain coding consistency with the updated value S i+1 in Block i+1.
Multi-chain blockchain
In some implementations, the trusted entity may perform revisions that may be hidden, and the user may not know that the new blockchain has replaced the original blockchain. That is, unless an old copy of the blockchain can be restored, the user may not necessarily be able to detect whether the portion of the blockchain has been revised.
However, in some implementations, the revision may advantageously be made apparent. For example, in a system that reviews the revision, a previous protocol may require evidence when the revision is performed, or tamper-resistant revisions may be advantageous in other cases where evidence of the revision is advantageous or otherwise preferred. In a revision-evident system, content removal or modification may leave a overwrite identifier or "trace" (e.g., overwrite artifact) that may not necessarily be removable by anyone, including trusted parties. However, in some implementations, traces may be removed by a subset of trusted parties or by coordination of multiple parties, as discussed below.
In some implementations where revisions are apparent, a single blockchain may include multiple chains, one based on a write-locked chain (e.g., a hash function lacking a key or a hash function with an unknown key), and one based on a rewritable blockchain (e.g., a color change Long Sanlie). If in both chains the write lock and rewritable chain are complete, there is no revision and the block is original. If the write lock chain is broken and the chameleon chain is complete, then a revision is made by the trusted entity. However, if the rewritable chain is broken, then the blockchain is edited by an untrusted entity and the blockchain may be invalidated. In some cases, if the rewritable chain is broken, the blockchain may be invalidated regardless of the state of the write lock chain. Accordingly, in this case, the integrity of the blockchain is ensured by the chameleon chain, while the write-lock chain acts as a detection mechanism. Thus, in blockchains that support overwriting with trace evidence, the effectiveness of the blockchain is logically separated from the creation of the tampered record.
In some implementations, multiple chains may be used to distinguish between different trusted entities. Accordingly, multiple rewritable chains may be included in a blockchain along with zero or more write lock chains. In a tracking blockchain of trusted entities, the chain corresponding to the trusted entity making the revision will not break, while other chains (including chains corresponding to other trusted entities or write-locked chains) may be broken. In some implementations, including multiple rewritable chains provides tamper traces or overwrite identifiers without accompanying write-locked chains, as only chains corresponding to trusted entities that make edits may remain unbroken, while other chains, while being rewritable by other trusted entities, may also be broken as a result of the edits. In some cases, the trace may be subsequently removed when another trusted entity or an entity owning keys of other chain(s) approves editing by a previously trusted party. This may protect the blockchain from untracked unilateral editing by one trusted party, but still allow Xu Shan trusted parties to quickly delete sensitive information without requiring coordination among multiple parties.
Furthermore, in some schemes, some trusted entities may be authorized to make edits without trace, while other trusted parties may leave trace when making edits. For example, in a multiple rewritable chain scheme, one trusted party may have keys for all chains, while the other parties have keys for only a portion of the chains. Parties that own all keys may edit without leaving a trace, while parties that own only a portion of the keys may leave a trace when editing. The multi-chain scheme may be combined with the distributed key scheme such that the parties may aggregate their keys for traceless editing in the event that the parties are left to act alone.
FIG. 9 illustrates an example double-chain blockchain portion 900, 950, with block B2 902 modified. A key 903 held by one or more trusted parties allows the trusted party to open link 904 and change block B2 902. However, the write lock chain 906 or other link where the trusted party lacks a key may be broken to indicate that a revision has occurred. Referring to 950, the old block B2 902 with possibly sensitive information may be removed, but the broken chain 956 acts as a non-abradable mark or trace that provides a permanent record of the occurrence of the revision that produced the new block B2' 952.
A hybrid blockchain having a non-rewritable blockchain space paired with a rewritable blockchain space may also be generated using the multi-chain blockchain. For example, the system may utilize an integrity code that lacks a key to protect a first of each block in a set of blocks in a blockchain. Accordingly, attempts by any party to rewrite these parts of the block will be tamper-resistant. An example system may protect the remainder of a block with integrity code that supports overwriting by a trusted party. These rewritable portions may be altered by a trusted party without generating tamper evidence. Accordingly, an operator may use a hybrid blockchain to generate a blockchain system with immutable core data paired with tertiary data that may be rewritten by a limited number of trusted parties.
Fig. 10 illustrates an example hybrid blockchain 1000. The hybrid blockchain 1000 includes blocks 1010, 1020, 1030, 1040 having a core 1002 portion and a tertiary portion 1004. The block portions 1012, 1022, 1032, 1042 making up the core portion 1002 are protected by the core integrity code 1006, which core integrity code 1006 may not necessarily support non-tamper resistant overwriting by any party. Conversely, the block portions 1014, 1024, 1034, 1044 that make up the third level portion 1004 of the blocks 1010, 1020, 1030, 1040 may be protected by the third level integrity code 1008 supporting non-tamper resistant overwriting.
In various implementations, the core 1006 and third level 1008 integrity codes themselves may implement multiple chains. For example, as discussed above, the core integrity code 1006 or the third level integrity code 1008 may support marking such that valid overwrites may be performed on the portions 1002, 1004, but these changes still generate evidence of tampering, although the changes are valid. Additionally or alternatively, the core 1006 and third level 1008 integrity codes may support approval by multiple trusted parties or require a different number of key portions to support editing. For example, editing of core portion 1002 may depend on approval by two trusted parties to perform a non-tamper resistant rewrite, while non-tamper resistant editing of a third level portion may be performed by a single trusted party. For a distributed key system, the example system may allow non-tamper-proof overwriting of the tertiary portion 1004 using M portions of the key, while allowing non-tamper-proof overwriting of the core portion 1002 only when N portions of the key (where N > M) are combined.
In an example scenario, a hybrid blockchain may be used to construct ledgers with completely immutable transaction data that is paired with transaction description/annotation data that may be rewritten by a selection set for an administrator of the ledger. In some cases, the ledger entry may include a size restriction or constraint in the data type that may be entered. Limiting the allowed rewrites may frustrate attempts to write irrelevant or malicious content to the immutable ledger portion of the block. Description/annotation fields within the rewritable portion of a block may suffer less from entry restrictions. However, an administrator may alter or remove previously written content in the description/comment field if the change is not tamper-resistant.
FIG. 11 illustrates an example rewritable blockchain scenario 1100. In the rewritable blockchain scenario 1100, a trusted party 1101 of the control key 1150 (or master key) may perform the overwriting 1172 itself. For example, the trusted party may have full control of the key because the trusted party does not have to coordinate with other parties to perform the overwriting 1172. For example, the trusted party 1101 may control the BRS 400 directly or from one or more terminals 1110, and the BRS 400 may store the key 1150 in the memory 420 (e.g., the protected memory 480) or access/receive the key 1150 from a remote location (such as the terminal 1110, cloud storage, or other network location). The terminal 1110 can include various communication devices such as a computer, a network server, a notebook computer, a cellular telephone, a smart phone, a tablet computer, an internet connection device, an internet of things device, or other communication devices. BRS 400 may execute RML 441 and/or rewrite logic 600 to perform blockchain rewrite 1172. The untrusted party 1102 may access the BRS 400, other BRS 400 systems, terminals 1110, or BPS 300, which may verify the blockchain and/or append blocks 1174 (e.g., add new blocks to the end of the blockchain).
Some untrusted parties may control the BRS 400, including BRSs 400 under the control of the trusted party. However, an untrusted party cannot access the stored key 1150. For example, some untrusted parties may lack user account rights on the BRS 400 to access the key 1150 of the trusted party, but may still access other functions of the BRS 400. Additionally or alternatively, an untrusted party with respect to a first rewriteable blockchain may act as a trusted party with respect to other blockchains. Accordingly, a single BRS 400 may provide overwrite operations 1172 for a plurality of different blockchains to a plurality of different trusted parties.
The BRS 400 may access the blockchain. When indicated under the authority of a trusted party, BRS 400 may use key 1150 to perform a rewrite of the accessed blockchain.
Fig. 12 illustrates an example distributed keychain blockchain rewrite scenario 1200. In the example scenario 1200, the multiple parties may include a separate untrusted party IUP (1299), a trusted party 1101, and an untrusted party 1102.IUP 1299 may control portion 1260 of the key while trusted party 1101 may control the entire key 1150. In an example scenario, overwriting 1272 may be performed when IUP 1299 combines their key portions 1260 (e.g., through PKE or other secret exchange schemes, as discussed above) or unilaterally overwrites 1172 with their keys 1150 under the authorization of trusted party 1101. However, in various other example distributed keychain rewrite scenarios, no single principal may have full control of the key 1150, and accordingly, non-tamper-resistant blockchain rewrites 1272 are possible when IUPS combines their portions 1260.
Referring again to the example distributed key blockchain rewrite scenario 1200, iup 1299 may combine their portions to perform non-tamper resistant rewrite 1272.IUP 1299 may store their key portion 1260 on BRS 400, BPS 300, terminal 1110, or other memory location. IUP 1299 may use one of the above-described exchange schemes to combine portions thereof. Once the combined key 1262 is available, the BRS 400 may access the combined key 1262 to perform non-tamper resistant overwriting.
Turning now to a discussion of real world applications of rewritable blockchains, blockchains may be used to maintain records (e.g., by private companies). For example, a service provider (e.g., a bank, financial institution, or other business) may maintain a blockchain that maintains transaction records.
Fig. 13 illustrates an example blockchain record maintenance scenario 1300. In some cases, the blockchain 1302 that may be rewritten may be maintained in a common location by the service provider 1304, wherein upon completion of a transaction by a party, the party 1308 to the transaction may append a block 1310 (e.g., containing a transaction record 1399) to the end of the blockchain 1302. Service provider 1304 holds key 1350 and is a trusted party. Because the party 1308 performing the transaction is untrusted, the service provider 1304 may rely on only the additional nature of the blockchain to prevent tampering with past records.
In some jurisdictions (such as the European Union), individuals may have forgotten rights. Further, because the blockchain 1302 includes transaction records 1399 and is publicly available, the blockchain 1302 may provide public records 1398 of fraudulent activity by past users. Because an individual may have extensive rights to remove a criminal reference from the public domain after completing a decision on a past crime, service provider 1304 may have legal obligations to remove public records 1398 of fraudulent activity. If the blockchain 1302 cannot be rewritten, the service provider 1304 may be forced to invalidate the blockchain 1302 or clear the entire blockchain 1302 to comply with the law. However, since service provider 1304 may perform non-tamper-proof overwriting of blockchain 1302, the service provider may remove common record 1398 without tamper evidence that would invalidate the blockchain. Accordingly, the above-described rewritable blockchain techniques and architectures provide specific technical solutions to the true application of public record keeping and legal compliance.
In another real world application, a rewritable blockchain may be used in maintaining data stream records from internet of things (IoT) devices. Fig. 14 illustrates an example IoT rewritable blockchain scenario 1400.IoT security camera 1402 may record audio-visual (a/V) data 1404 and store the a/V data within rewritable blockchain 1408. Enterprises 1410 operating IoT security cameras 1402 may use it to monitor areas open to third party clients 1499 (e.g., parking lots at retail locations). When a dispute (e.g., a minor car accident) occurs between clients 1499, enterprise 1410 may provide a/V data 1404 within blockchain 1408 to clients 1499.
Accordingly, enterprise 1410 may be confident that individual clients 1499 are not able to alter a/V data 1404. Thus, the authenticity of A/V data 1404 may be verified by the customer 1499 itself (or by nearly any party, such as an insurer, moderator, or court). As a result, providing video within the blockchain may reduce the potential burden to enterprise 1410 in terms of authenticating A/V data 1404 for customer 1499. In addition, because the blockchain 1408 is rewritable, the enterprise can intercept the A/V data 1404 and provide the segment 1420 with the associated A/V data. Without the ability to rewrite blockchain 1408, enterprise 1410 may be at risk of providing an irrelevant a/V segment or removing blockchain protection option and of having more burdensome certification requirements. In various implementations, the segments 1420 may be packaged into closed blockchain loops, as discussed below.
Rewritable blockchain technologies and architectures may support blockchain forms that are impractical or infeasible without a technical solution of the rewritable capability. For example, in the case of blockchain rewrite support, the blockchain may be "packaged" into a loop form by a trusted party. In other words, the first block of a given linear blockchain may be rewritten to include an integrity output consistent with subsequent block encodings of the blockchain. This at least partially reforms the blockchain into a loop. Without rewrite support, it is impossible or impractical to build a loop within a blockchain unless the contents of all blocks within the loop are known before the first block is added in the loop. In some cases, a branch (e.g., having two separate possible blocks that may follow the first block) is an indicator of a blockchain failure. Without branches, open loops (e.g., loops that do not connect both ends of a blockchain) cannot be constructed. Accordingly, open loop may be active in implementations where the presence of a branch does not necessarily invalidate the blockchain.
Where the first block is the oldest block in the blockchain and the subsequent block is the newest block, the trusted party reassembles the blockchains into a closed blockchain loop. The blockchain loop may be used by multiple parties to provide self-consistent tamper resistance for blockchains of limited length. For example, where the blockchain covers a series of transactions that have been completed, the blockchain may be packaged into a closed loop to provide a self-consistent record without having to rely on future block additions to ensure security.
FIG. 15 illustrates an example encapsulation blockchain 1530, 1550. The example block chaining way 1530 is open loop. The example blockchain 1500 is a closed loop. Trusted party 1504 may encapsulate a blockchain into an open-loop blockchain 1530 by selecting at least one non-end block (e.g., a block from group 1532) to lock to another block. Alternatively, trusted party 1504 may package the blockchain into closed loop blockchain 1550 by selecting two end blocks (e.g., two blocks from group 1552).
For the open loop 1530, the block 1538 may be overwritten with the content 1546 such that the integrity output 1536 stored in the block 1534 indicates that the block 1538 precedes the block 1534 (e.g., the integrity output 1536 should be consistent with the content 1546 encoding). Since block 1534 remains unchanged, the contents of block 1542 may also be consistent with the integrity output 1536 code stored in block 1534. Integrity output 1536 may be written into block 1544 to ensure that block 1538 is consistent with block 1544 encoding after being rewritten. The block 1544 may be rewritten with the integrity output 1536 such that the integrity output 1548 of the block 1558 remains consistent with the block 1544 encoding after being rewritten.
For the closed loop blockchain 1550, the block 1554 may be overwritten with an integrity output 1556, the integrity output 1556 indicating that the block 1558 precedes the block 1554 (e.g., the integrity output 1556 should be consistent with the content 1558 encoding). The block 1554 may be rewritten with the integrity output 1556 such that the integrity output 1566 of the block 1541 remains consistent with the block 1554 encoding after being rewritten. Accordingly, after the closed loop 1550 is created by the trusted party 1504, the rewrite block 1558 by the untrusted party will be inconsistent with the integrity output 1556 encoding and tamper resistant. In addition, in implementations where the branches disable the blockchain, additional blocks after block 1558 will disable the closed loop 1550. Accordingly, in implementations where branches invalidate blockchains, the closed loop blockchain 1550 may be protected from both non-tamper-resistant overwriting and non-tamper-resistant addition.
The methods, devices, processes and logic described above may be implemented in many different ways and in many different combinations of hardware and software. For example, all or part of an implementation may be a circuit including an instruction processor, such as a Central Processing Unit (CPU), microcontroller, or microprocessor; an Application Specific Integrated Circuit (ASIC), a Programmable Logic Device (PLD), or a Field Programmable Gate Array (FPGA); or a circuit comprising discrete logic or other circuit components (including analog circuit components, digital circuit components, or both); or any combination thereof. For example, the circuitry may include discrete interconnected hardware components and/or may be implemented in a multi-chip module (MCM) that is combined on a single integrated circuit die, distributed among multiple integrated circuit chips, or multiple integrated circuit dies in a common package.
The circuitry may further include or access instructions for execution by the power supply. Instructions may be implemented as a signal and/or data stream and/or may be stored in a tangible storage medium other than a transitory signal, such as flash memory, random Access Memory (RAM), read Only Memory (ROM), erasable Programmable Read Only Memory (EPROM); or stored on a magnetic or optical disk, such as a Compact Disk Read Only Memory (CDROM), hard Disk Drive (HDD) or other magnetic or optical disk; or stored in or on another machine-readable medium. An article of manufacture, such as a computer program product, may comprise, inter alia, a storage medium and instructions stored in or on the medium, and the instructions, when executed by circuitry in a device, may cause the device to implement any of the processes described above or shown in the accompanying drawings.
The implementations may be distributed as circuitry (e.g., hardware and/or a combination of hardware and software) among multiple system components, such as among multiple processors and memories, optionally including multiple distributed processing systems. Parameters, databases, and other data structures may be separately stored and managed, may be combined into a single memory or database, may be logically and physically organized in many different ways, and may be implemented in many different ways, including as a data structure such as a linked list, hash table, array, record, object, or implicit storage mechanism. The programs may be portions of a single program (e.g., subroutines), separate programs, distributed across several memories and processors, or implemented in many different ways, such as in libraries, such as shared libraries (e.g., dynamic Link Libraries (DLLs)).
The techniques and architectures described herein may be used in various implementations. As one example, a method may be performed in a hardware security system. The method may include: receiving, at the processing circuit, a first portion of the key via a key exchange protocol; combining, with processing circuitry, the first portion with a second portion of the key to obtain the key; determining, with the processing circuitry, to overwrite original data in a selected block of the blockchain with altered data that is different from the original data previously stored in the selected block; and determining, with the processing circuitry and using the key, conflicting data comprising altered data, the conflicting data being consistent with a previously determined integrity output encoding, the integrity output being stored within a particular block of the blockchain following the selected block, the previously determined integrity output being generated in response to and consistent with the original data encoding.
As another example, a system may include: a memory, a blockchain stored within the memory, and a rewrite circuit in data communication with the communication interface. The blockchain may include: a selected block comprising raw data; and a specific block including an integrity output, the integrity output being determined as an input using the raw data. The communication interface may be configured to: a portion that performs a key exchange operation to receive a key, the portion being transmitted by a plurality of separate untrusted parties; a command is received in coordination with the key exchange protocol, the command to overwrite the original data with the altered data. The rewrite circuit may be configured to: obtaining a partial combination using the portions of the key; when the count of portions exceeds a threshold count for overwrite rights, conflicting data comprising altered data is calculated, the conflicting data is consistent with an integrity output encoding, and calculating the conflicting data is performed using the portion combination and the altered data as inputs.
In some implementations, the rewrite circuitry may be further configured to: when the count does not exceed the threshold count for the overwrite authority, the conflict data cannot be calculated.
In some implementations, the rewrite circuitry may be configured to: the collision data cannot be calculated by: determining that the count does not exceed a threshold; and in response to determining that the count does not exceed the threshold, aborting the calculation of the conflicting data.
In some implementations, the rewrite circuitry may be configured to: the collision data cannot be calculated by: generating invalid data by attempting to calculate conflicting data using incomplete knowledge of the key, the invalid data not being consistent with the integrity output code; and performing tamper-resistant overwriting of the blockchain by overwriting at least the original data with the invalid data.
In some implementations, a particular block may follow a selected block within the blockchain.
In some implementations, a particular block may include a block adjacent to a selected block within the blockchain.
In yet another example, a method may be performed in a hardware security system. The method may include: determining, with the processing circuitry, to overwrite original data in a selected block of the blockchain with altered data that is different from the original data previously stored in the selected block; identifying a particular block of the blockchain, the particular block including a first integrity code and a second integrity code; determining, with the processing circuitry and using the key, conflicting data comprising altered data; and utilizing the processing circuitry to perform tamper-resistant overwriting on the blockchain by replacing the original data with conflicting data. The conflicting data is consistent with a first integrity output code stored within a particular block of the blockchain and inconsistent with a second integrity output code stored within the particular block. The first and second integrity outputs are generated in response to and in accordance with the original data encoding.
In another example, a system may include: memory, a blockchain stored within the memory, and a rewrite circuit. The blockchain may include: a first block including raw data; and a second block comprising a first integrity output calculated using the raw data as input; and a second integrity output calculated using the raw data as input. The rewrite circuit may be configured to: trace is generated in the blockchain by overwriting a first block with altered data that is different from the original data, the altered data consistent with the first integrity output encoding but inconsistent with the second integrity output encoding.
In another example, a system may include: the memory, the communication interface circuit, and the rewriting circuit in data communication with the communication interface and the memory. The memory may be configured to store a key for the protection of the chameleon hash of the blockchain. The communication interface circuit may be configured to: a blockchain in the memory is accessed, the blockchain including a selected block, a second block following the selected block on the blockchain, and a third block preceding the selected block on the blockchain. The selected blocks may include: a payload field operable to store the original data; a first previous hash field operable to store a first chameleon hash output; a randomness field. The second block may include a second previous hash field operable to store a second color change Long Sanlie output. The first chameleon hash output may be generated using the content of the third chunk as an input. The communication interface circuit may be further configured to: receiving a trusted party instruction to perform a non-tamper-resistant overwrite on a payload field, the instruction specifying altered data that will replace original data previously stored in the payload field; to facilitate execution of the instructions, an authorization to access a key within the memory is received, the authorization initiated by a trusted party to the blockchain, and a rewrite instruction for the blockchain is sent. The rewrite circuit may be configured to: determining random data to be written to the random field using the payload field, the first previous hash field, and the key as inputs, selecting the random data such that when the payload field contains modified data and the random field contains random data, the second color change Long Sanlie output is consistent with the selected block encoding; generating a rewriting instruction; causing the communication interface to transmit a overwrite instruction. The rewrite instruction may include: a first command to write the randomness data into the randomness field; and a second command to replace the original data with the modified data.
In another example, a system may include a memory and a rewrite circuit. The memory may be configured to store a blockchain. The blockchain may include: a selected block comprising raw data; and a particular block, including an integrity output. The rewrite circuitry may be configured to perform non-tamper-resistant rewriting of the selected block, the particular block, or both.
In some implementations, the rewrite circuitry may be configured to perform non-tamper-resistant rewriting by encapsulating the blockchain into loops.
In some implementations, the rewrite circuitry may be configured to package the blockchain into a loop by replacing the original data with altered data consistent with the integrity output encoding.
In some implementations, the rewrite circuitry may be configured to package the blockchain into a loop by packaging the blockchain into a closed loop, an open loop, or both.
In some implementations, a blockchain may include a third level part and a core part.
In another example, a system may include a memory and a hybrid blockchain stored on the memory. The hybrid blockchain may include a core portion and a third level portion. Meeting criteria for overwrite rights may qualify a principal to overwrite a third level portion but not a core portion.
In some implementations, the criteria may include combining a first threshold number of key portions.
In some implementations, the core may be protected by an integrity code that lacks an associated key.
In another example, a system may include: a memory; a blockchain stored in memory, the blockchain including blocks having raw data, the blockchain being protected by a first integrity output for a first integrity code, the first integrity code configured to generate the first integrity output when applied to the raw data; and a rewriting circuit in data communication with the memory. The rewriting circuit is configured to: accessing a blockchain; accessing a key for a first integrity code, the key facilitating identification of conflicting data, the conflicting data being different from the original data, the first integrity code configured to generate a first integrity output when applied to the conflicting data; receiving a command to overwrite original data in the block with altered data different from the original data, the first integrity code not producing a first integrity output when applied to the altered data; generating additional data in response to the key and the altered data; generating conflict data based on the altered data and the additional data; and overwriting the block with conflicting data.
In some implementations, the altered data includes: a revised version of the original data, supplemental data relative to the original data, or both.
In some implementations, wherein the first integrity code includes a cryptographic hash, a chameleon hash, or both.
In some implementations, the blockchain includes a double chain constructed from a first integrity code and a second integrity code.
In some implementations, the second integrity code does not generate a second integrity output when applied to conflicting data.
In some implementations, the second integrity output is configured to be used as a overwrite identifier to mark the blockchain as overwritten.
In some implementations, the first integrity code includes a first chameleon hash and the second integrity code includes a overwrite protection password hash, a second chameleon hash, or both.
In some implementations, the first integrity code includes an internal hash nested within an external hash.
In some implementations, the internal hash includes a chameleon hash configured to provide a hash output to the external hash; and the external hash comprises a overwrite protection password hash.
In some implementations, the rewrite circuitry is configured to access the key by combining portions of the key.
In some implementations, the multiple portions are stored in separate memory locations maintained by separate untrusted parties that together make up the trusted party.
In some implementations, the rewrite circuitry is configured to combine the plurality of parts using a public key exchange protocol.
In another example, a method includes: in a hardware security system, a processing circuit is used to access keys for a blockchain; determining, with processing circuitry, to overwrite original data in a selected block of the blockchain with altered data that is different from original data previously stored in the selected block; and determining, with the processing circuitry and using the key, conflicting data comprising altered data, the conflicting data being encoded in accordance with a previously determined integrity output stored within a particular block of the blockchain that follows the selected block, the previously determined integrity output being generated in response to and in accordance with the original data encoding.
In some implementations, overwriting the original data with the altered data includes: the original data is overwritten with a revised version of the original data, the original data is overwritten with supplemental data relative to the original data, or both.
In some implementations, the blockchain is protected by an integrity code that includes a cryptographic hash, a chameleon hash, or both; and the key is integrity code specific.
In some implementations, the blockchain includes a double chain that uses the first integrity code and the second integrity code.
In some implementations, the modified data includes a code inconsistency with a second integrity output of the second integrity code, the second integrity output different from the previously determined integrity output.
In some implementations, the encoding of the second integrity output other than the second integrity code is configured to serve as a overwrite identifier marking the blockchain as overwritten.
In some implementations, the first integrity code includes a first chameleon hash; and the second integrity code includes a overwrite protection password hash, a second chameleon hash, or both.
In some implementations, the first integrity code includes an internal hash nested within an external hash.
In some implementations, the internal hash includes a chameleon hash configured to provide a hash output to the external hash; and the external hash comprises a overwrite protection password hash.
In some implementations, the access key includes multiple portions of a combined key.
In another example, a computer program or product may include: a machine readable medium other than a transient signal; and instructions stored on a machine-readable medium. These instructions, when executed, may cause the system to: accessing raw data within the blockchain, the raw data being protected by a first integrity output for an integrity code, the integrity code configured to generate the first integrity output when applied to the raw data; determining to overwrite original data in the block with altered data different from the original data such that overwriting the original data with the altered data produces tamper-resistant overwriting; accessing a key in memory; and in response to the key, performing a non-tamper-proof overwrite that replaces the blockchain of the first data with at least the altered data such that the integrity code is configured to generate a first integrity output when applied to the non-tamper-proof overwrite.
In some implementations, the modified data includes a revised version of the original data, supplemental data relative to the original data, or any combination thereof.
In some implementations, the integrity code includes a color change Long Sanlie.
In some implementations, the instructions are further configured to access the key by combining multiple portions of the key.
In some implementations, the multiple portions are stored in separate memory locations maintained by separate untrusted parties that together make up the trusted party for the blockchain.
In some implementations, the instructions are further configured to prevent the individual untrusted parties from individually obtaining overall knowledge of the key by combining the multiple parts using a public key exchange protocol.
In another example, a method includes accessing, via a rewrite circuit, a blockchain stored on a memory, wherein the blockchain includes a block having first data; and the blockchain is protected by a first integrity output for an integrity code configured to generate the first integrity output when applied to the original data. The method may further comprise: accessing, via the rewrite circuit, a key for an integrity code that facilitates identification of conflicting data that is different from the original data, the integrity code configured to generate a first integrity output when applied to the conflicting data; determining to overwrite original data in the block with altered data different from the original data, the integrity code not producing a first integrity output when applied to the altered data; generating additional data in response to the key and the altered data; generating conflict data based on the altered data and the additional data; and overwriting the block with conflicting data.
In some implementations, the access key includes multiple portions of the combined key that are stored in separate memory locations maintained by separate untrusted parties that together make up the trusted party.
In another example, a method includes, in a hardware security system: accessing, using the processing circuitry, a key for the blockchain; determining, with the processing circuitry, to overwrite original data in a selected block of the blockchain with altered data that is different from the original data previously stored in the selected block; and determining, with the processing circuitry and using the key, conflicting data comprising altered data, the conflicting data being consistent with a previously determined integrity data encoding stored within a particular block following the selected block in the blockchain, the previously determined integrity output being generated in response to and consistent with the original data encoding.
In some implementations, the blockchain is protected by an integrity code that includes a cryptographic hash, a chameleon hash, or both. The key is integrity code specific.
In some implementations, the blockchain includes a double chain that uses the first integrity code and the second integrity code.
In some implementations, the modified data includes a code inconsistency with a second integrity output of the second integrity code, the second integrity output different from the previously determined integrity output.
In some implementations, the encoding of the second integrity output other than the second integrity code is configured to serve as a overwrite identifier marking the blockchain as overwritten.
In some implementations: the first integrity code includes a first chameleon hash; and the second integrity code includes a overwrite protection password hash, a second chameleon hash, or both.
In some implementations, the first integrity code includes an internal hash nested within an external hash.
In some implementations: the internal hash includes a chameleon hash configured to provide a hash output to the external hash; and the external hash comprises a overwrite protection password hash.
In another example, a system includes a communication interface circuit and a rewriting circuit in data communication with the communication interface circuit. The communication interface circuit is configured to receive, at the processing circuit, a first portion of the key via a key exchange protocol. The rewriting circuit is configured to: combining the first portion with a second portion of the key to obtain the key; determining to overwrite original data in a selected block of the blockchain with altered data that is different from original data previously stored in the selected block; and determining conflict data including the altered data using the key, the conflict data being encoded in accordance with a previously determined integrity output stored in a particular block of the blockchain following the selected block, the previously determined integrity output being generated in response to and in accordance with the original data encoding.
In some implementations, a particular block follows a selected block within the blockchain.
In some implementations, a particular block includes a block adjacent to a selected block within the blockchain.
In some implementations, the communication interface circuit is configured to receive the first portion of the key via the key exchange protocol by receiving the first portion of the key via the public key exchange protocol.
In some implementations, the communication interface circuit is configured to receive the first portion of the key and the key exchange protocol by executing the key exchange protocol under the authorization of a plurality of separate untrusted parties.
In some implementations, the rewrite circuitry is further configured to access the second portion of the key in the protected memory prior to combining the first portion and the second portion of the key.
In some implementations, the rewrite circuitry is further configured to grant the third portion of the key to the previously untrusted party using the key.
In some implementations, the rewrite circuitry is configured to grant the third portion of the key by decrypting a cache storing portions of the key using the key.
In some implementations, the rewrite circuitry is configured to determine to overwrite original data in a selected block of the blockchain with altered data by determining to remove detectable rewrite artifacts left by performing a rewrite without accessing the first portion, the second portion, or both.
In another example, a method includes accessing a blockchain in memory, the blockchain including: a selected block comprising raw data; and a specific block including an integrity output, the integrity output being determined from the raw data as input. The method may further include, at the communication interface circuit: performing key exchange operations to receive portions of keys, the portions being transmitted by a plurality of separate untrusted parties; a command is received in coordination with the key exchange operation, the command specifying overwriting the original data with the altered data. The method may further include, at the rewrite circuit: obtaining a partial combination from the portion of the key; and when the count of portions exceeds a overwrite threshold for the overwrite rights, calculating conflicting data comprising altered data, wherein: the conflicting data is consistent with the integrity output code and the conflicting data is algorithmically determined from the partial combination and altered data as inputs.
In some implementations, the method further includes failing to calculate conflicting data when the count does not exceed the overwrite threshold for the overwrite rights.
In some implementations, the inability to calculate conflicting data includes: determining that the count does not exceed the overwrite threshold; and discarding the calculation of conflicting data in response to determining that the count does not exceed the overwrite threshold.
In some implementations, the inability to calculate conflicting data includes: generating invalid data by attempting to calculate conflicting data using incomplete knowledge of the key, the invalid data not being consistent with the integrity output code; and performing tamper-resistant overwriting of the blockchain includes overwriting at least the original data with invalid data.
In some implementations, the method further includes decrypting the cache of key portions when the count exceeds an granted threshold for the key grant rights.
In another example, a method includes, in a hardware security system: receiving, at the processing circuit, a first portion of the key via a key exchange protocol; combining, with processing circuitry, the first portion with a second portion of the key to obtain the key; determining, with the processing circuitry, to overwrite original data in a selected block of the blockchain with modified data that is different from the original data previously stored in the selected block; and determining, with the processing circuitry and using the key, conflicting data comprising altered data, the conflicting data being consistent with a previously determined integrity output encoding stored in a particular block following the selected block in the blockchain, the previously determined integrity output being generated in response to and consistent with the original data encoding.
In some implementations, a particular block follows a selected block within the blockchain.
In some implementations, a particular block includes a block adjacent to a selected block within the blockchain.
In some implementations, receiving the first portion of the key via a key exchange protocol includes: the first portion of the key is received via a public key exchange protocol.
In some implementations, receiving the first portion of the key via a key exchange protocol includes: the key exchange protocol is performed under the authority of a plurality of separate untrusted parties.
In some implementations, the method further includes: the second portion of the key is accessed in the protected memory before combining the first portion and the second portion of the key.
In some implementations, the method further includes: the key is used to grant a third portion of the key to a previously untrusted party.
In some implementations, granting the third portion of the key includes: the key is used to decrypt the cache that stores portions of the key.
In some implementations, determining to overwrite original data in a selected block of the blockchain with the altered data includes: it is determined to remove detectable overwrite artifacts left by performing the overwrite without accessing the first portion, the second portion, or both.
In another example, a system includes a memory, a blockchain stored within the memory, the blockchain including: a selected block comprising raw data; and
A specific block including an integrity output, the integrity output being determined from the raw data as input; the communication interface circuit is configured to: performing a key exchange operation to receive portions of the key, the portions being received on behalf of a plurality of separate untrusted parties; receiving a command coordinated with the key exchange operation, the command specifying overwriting the original data with the altered data; and a rewriting circuit in data communication with the communication interface circuit, the rewriting circuit configured to: obtaining a partial combination from the portion of the key; and when the count of portions exceeds the overwrite threshold for the overwrite rights, calculating conflicting data comprising altered data, wherein: the conflicting data is consistent with the integrity output encoding and the conflicting data is algorithmically determined from the partial combination and altered data as inputs.
In some implementations, the rewrite circuitry is further configured to fail to calculate the conflicting data when the count does not exceed a rewrite threshold for the rewrite authority.
In some implementations, the rewrite circuitry is configured to fail to calculate the conflicting data by: determining that the count does not exceed the overwrite threshold, and discarding the conflicting calculations in response to determining that the count does not exceed the overwrite threshold.
In some implementations, the rewrite circuitry is configured to fail to calculate the conflicting data by: generating invalid data by attempting to calculate conflicting data using incomplete knowledge of the key, the invalid data being inconsistent with the integrity output code; and performing tamper-resistant overwriting of the blockchain by overwriting at least the original data with the invalid data.
In some implementations, a particular block includes a block adjacent to a selected block within the blockchain.
In some implementations, the re-write circuit is further configured to decrypt the cache of key portions when the count exceeds a grant threshold for the key grant rights.
In another example, a method includes, in a hardware security system: accessing a blockchain stored in memory, the blockchain including: a first block including raw data; and a second block comprising a first integrity output calculated using the raw data as input and a second integrity output calculated using the raw data as input. The method further comprises the steps of: the rewrite circuitry is used to generate rewrite artifacts in the blockchain by overwriting a first block with altered data that is different from the original data, the altered data being consistent with the first integrity output code but inconsistent with the second integrity output code.
In some implementations, generating the overwrite rewrite artifact in the blockchain includes: the first block is overwritten with the altered data by performing an efficient overwriting of the chain of blocks.
In some implementations, the method further includes: the overwrite artifact is removed by using the approval key to overwrite the first block with approval data consistent with the first integrity output and the second integrity output encodings.
In some implementations, the approval data includes modified data; and overwriting the first block with the approval data by performing multiple trusted party overwrite approval for the blockchain.
In some implementations, overwriting the first block with the altered data includes using the key to overwrite the first block with the altered data; and the method further comprises: the key is generated by combining portions of the key in a key exchange before overwriting the first block with the altered data.
In some implementations, combining the plurality of portions includes: the plurality of portions are combined when the count of the plurality of portions exceeds a first threshold for valid tamper resistant overwriting.
In some implementations, combining the plurality of portions includes: the plurality of portions are combined when the count of the plurality of portions exceeds a first threshold for valid tamper-resistant overwrites but does not exceed a second threshold for valid non-tamper-resistant overwrites, the valid non-tamper-resistant overwrites being encoded with the second integrity output.
In another example, a computer program or product includes: a machine readable medium other than a transient signal; and instructions stored on a machine-readable medium configured to, when executed, cause a system to: determining to overwrite original data in a selected block of the blockchain with altered data that is different from original data previously stored in the selected block; identifying a particular block of the chain of blocks, the particular block including a first integrity output and a second integrity output; determining conflicting data comprising altered data using the first key; and performing tamper-resistant overwriting of the blockchain by replacing the original data with the conflicting data. In the event that conflicting data is consistent with the first integrity output encoding and inconsistent with the second integrity output encoding, the first and second integrity outputs are generated in response to and consistent with the original data encoding.
In some implementations, the instructions are configured to: the processing circuitry is caused to perform tamper-resistant overwriting consistent with the first integrity output encoding by performing an active overwriting of the blockchain.
In some implementations, the instructions are configured to: the processing circuitry is caused to perform tamper-resistant overwrite inconsistent with the second integrity output encoding by generating an overwrite artifact marking the blockchain as overwritten.
In some implementations, the instructions are further configured to: the processing circuitry is caused to determine, after performing tamper-resistant overwriting of the blockchain, to overwrite conflicting data with approval data using the second key, the approval data being consistent with the first integrity output and the second integrity output encodings.
In some implementations, the approval data includes modified data; and the instructions are configured to: the processing circuitry is caused to determine to overwrite conflicting data with the approval data by determining that multiple trusted parties performing tamper-resistant overwriting of the blockchain approve.
In some implementations, the instructions are further configured to cause the processing circuit to generate the first key by combining the portions of the first key in a key exchange.
In some implementations, the instructions are configured to: the processing circuit is caused to combine the plurality of parts by combining the plurality of parts when the count of the plurality of parts exceeds a first threshold for valid tamper resistant overwriting.
In some implementations, the instructions are configured to: the processing circuitry is caused to combine the plurality of portions by combining the plurality of portions when the count of the plurality of portions exceeds a first threshold for valid tamper-resistant overwrites but does not exceed a second threshold for valid non-tamper-resistant overwrites, the valid non-tamper-resistant overwrites being consistent with the second integrity output code.
In another example, a method includes, in a hardware security system: determining, with the processing circuitry, to overwrite original data in a selected block of the blockchain with the altered data, different from original data previously stored in the selected block; identifying a particular block of the blockchain, the particular block including a first integrity output and a second integrity output; determining, with the processing circuitry and using the first key, conflicting data comprising altered data, the conflicting data being consistent with the first integrity output encoding; and inconsistent with the second integrity output encoding, the first and second integrity outputs being generated in response to and encoded with the original data; and performing tamper-resistant overwriting of the blockchain by replacing the original data with conflicting data with processing circuitry.
In some implementations, performing tamper-resistant overwriting consistent with the first integrity output encoding includes: efficient overwriting of the blockchain is performed.
In some implementations, performing tamper-resistant overwriting that is inconsistent with the second integrity output encoding includes: a rewrite artifact is generated that marks the blockchain as rewritten.
In some implementations, the method further includes: after performing tamper-resistant overwriting of the blockchain, it is determined to overwrite conflicting data with approval data using the second key, the approval data being consistent with the first integrity output and the second integrity output encoding.
In some implementations, the approval data includes modified data; and determining to overwrite the conflicting data with the approval data comprises: multiple trusted party approvals for performing tamper-resistant overwriting of blockchains are determined.
In some implementations, the method further includes: the first key is generated by combining portions of the first key in a key exchange.
In some implementations, combining the plurality of portions includes: the plurality of portions are combined when the count of the plurality of portions exceeds a first threshold for valid tamper resistant overwriting.
In some implementations, combining the plurality of portions includes when: the plurality of portions are combined when the count of the plurality of portions exceeds a first threshold for valid tamper-resistant overwrites but does not exceed a second threshold for valid non-tamper-resistant overwrites.
In another example, a system includes: a memory; a blockchain stored within the memory, the blockchain comprising: a first block including raw data; and a second block comprising: a first integrity output calculated using the raw data as input; and a second integrity output calculated using the raw data as input; and a rewriting circuit configured to: the method includes generating a rewrite artifact in a blockchain by overwriting a first block with altered data that is different from original data, the altered data consistent with a first integrity output encoding but inconsistent with a second integrity output encoding.
In some implementations, the rewrite circuitry is configured to: the overwrite artifact is generated in the blockchain by performing an active overwrite to the blockchain to overwrite the first block by utilizing the altered data.
In some implementations, the rewrite circuit is further configured to: the approval data is encoded consistent with the first integrity output and the second integrity output by using the approval key to overwrite the first block with the approval data to eliminate overwriting artifacts.
In some implementations, the approval data includes modified data; and the rewrite circuitry is configured to rewrite the first block with the approval data by performing multiple trusted party rewrite approval of the blockchain.
In some implementations, the rewrite circuitry is configured to: using the key to overwrite the first block with the altered data; and generating a key by combining the portions of the key in a key exchange prior to overwriting the first block with the altered data.
In some implementations, the rewrite circuitry is configured to: the plurality of parts are combined by combining the plurality of parts when the count of the plurality of parts exceeds a first threshold for valid tamper resistant overwriting.
In some implementations, the rewrite circuitry is configured to: the plurality of portions are combined by combining the plurality of portions when the count of the plurality of portions exceeds a first threshold for valid tamper-resistant overwrites, but does not exceed a second threshold for valid non-tamper-resistant overwrites, the valid non-tamper-resistant overwrites being consistent with the second integrity output code.
In another example, a method includes, in a hardware security system: accessing, via the communication interface circuit, a blockchain database configured to store blockchains protected by chameleon hashes, the blockchains comprising: a selected block including a payload field and a randomness field; a particular block, subsequent to the selected block on the blockchain, the particular block including a first previous hash field operable to store a first chameleon hash output; and an intermediate block, between the selected block and the particular block on the blockchain, the first chameleon hash output generated using the contents of the intermediate block as an input. The method further includes, in the hardware security system: receiving trusted party instructions to delete intermediate blocks from the blockchain; to facilitate execution of the instructions, receiving an authorization to access a key for the chameleon hash, the authorization initiated by a trusted party for the blockchain; using the payload field, the first previous hash field, and the key as inputs to determine the randomness data to write to the randomness field, selecting the randomness data such that the discolouration Long Sanlie is configured to produce the first chameleon hash output is when the middle chunk is deleted from the blockchain and the discolouration Long Sanlie is applied to the selected chunk. The method further comprises the steps of: generating a delete instruction at the rewrite circuit; and sending a delete instruction to the blockchain database via the communication interface circuit. The deletion instruction includes: a first command to write the randomness data into the randomness field; and a second command to delete the middle block from the blockchain.
In some implementations, the intermediate block includes one of a plurality of blocks between the selected block and the particular block on the blockchain.
In some implementations, the color change Long Sanlie includes a rewritable cryptographic hash nested in a overwrite protection cryptographic hash.
In some implementations, the particular block further includes a third previous hash field that includes a write-protected hash output generated using a overwrite protection cryptographic hash that protects the blockchain in parallel with the color change Long Sanlie.
In some implementations, the overwrite protection password hash does not produce a write protection hash output when the intermediate block is deleted from the blockchain and the overwrite protection password hash is applied to the selected block.
In some implementations, the trusted party includes a plurality of separate untrusted parties; and the method further comprises: a public key encryption based exchange protocol is used to combine multiple key portions controlled by separate untrusted parties.
In some implementations, determining the randomness data includes: the random data is successfully generated when the count of the plurality of key portions exceeds a threshold for the overwrite rights.
In some implementations, each of the plurality of key portions contributes equally to the count.
In some implementations, a first key portion of the plurality of key portions contributes more than a second key portion of the plurality of key portions.
In some implementations, the randomness field is nested within a first previous hash field within a particular block to mask the presence of the randomness field.
In some implementations, sending the delete instruction includes adhering to a data privacy rule.
In another example, a computer program or product includes: a machine readable medium other than a transient signal; and instructions stored on a machine-readable medium. The instructions are configured to, when executed, cause the system to access a blockchain database configured to store blockchains protected by chameleon hashes, the blockchains comprising: a selected block including a payload field and a randomness field; a particular block, subsequent to the selected block on the blockchain, the particular block including a first previous hash field operable to store a first chameleon hash output; and an intermediate block, between the selected block and the particular block on the blockchain, the first chameleon hash output generated using the contents of the intermediate block as an input. The instructions are further configured to, when executed, cause the system to: receiving trusted party instructions to delete intermediate blocks from the blockchain; to facilitate execution of the instructions, receiving an authorization to access a key for the chameleon hash, the authorization initiated by a trusted party for the blockchain; the random data written to the random field is determined using the payload field, the first previous hash field, and the key as inputs, the random data selected such that the color change Long Sanlie is configured to produce a first chameleon hash output when the intermediate block is deleted from the blockchain and color change Long Sanlie is applied to the selected block. The instructions are further configured to, when executed, cause the system to: and generating a deleting instruction and sending the deleting instruction to the blockchain database. The delete instruction includes a first command to write the randomness data to the randomness field and a second command to delete the middle block from the blockchain.
In another example, a system includes: a memory configured to store a key for a chameleon hash of a protection blockchain; a communication interface circuit configured to access a blockchain in memory, the blockchain including a selected block including a payload field operable to store original data, a first previous hash field operable to store a first chameleon hash output, and a randomness field, a second block following the selected block on the blockchain, the second block including a second previous hash field operable to store a second chameleon Long Sanlie output, and a third block preceding the selected block on the blockchain, the first chameleon hash output generated using content of the third block as input, receiving a trusted party instruction to perform a non-tamper rewrite on the payload field, the trusted party instruction specifying altered data to replace the original data previously stored in the payload field; to facilitate execution of the instructions, receiving an authorization to access a key within the memory, the authorization initiated by a trusted party of the blockchain; and sending a rewrite instruction for the blockchain; and a rewriting circuit in data communication with the communication interface circuit and the memory, the rewriting circuit configured to: determining random data to write to the random field using the payload field, the first previous hash field, and the key as inputs, selecting the random data such that the discolouration Long Sanlie is configured to produce a second discolouration Long Sanlie output when the payload field contains altered data, the random field includes the random data, and the chameleon hash is applied to the selected block; generating a rewrite instruction, the rewrite instruction comprising:
A first command to write the randomness data into the randomness field; and a second command to replace the original data with the modified data; and causing the communication interface circuit to transmit the overwrite instruction.
In some implementations, the color change Long Sanlie includes a rewritable cryptographic hash nested within a overwrite protection cryptographic hash.
In some implementations, the second block further includes a third previous hash field that includes a write protection hash output generated using a overwrite protection password hash that protects the blockchain in parallel with the color change Long Sanlie.
In some implementations, when the payload field contains altered data, the randomness field contains randomness data, and the overwrite protection password hash is applied to the selected block, the overwrite protection password hash does not produce a write protection hash output:
In some implementations, the trusted party includes a plurality of separate untrusted parties; and the rewrite circuit is configured to: a public key encryption based exchange protocol is used to combine multiple key portions controlled by separate untrusted parties.
In some implementations, the rewrite circuitry is configured to: the random data is successfully generated when the count of the plurality of key portions exceeds a threshold for the overwrite rights.
In some implementations, each of the plurality of key portions contributes equally to the count.
In some implementations, a first key portion of the plurality of key portions contributes to the count more than a second key portion of the plurality of key portions.
In some implementations, the randomness field is nested in a first previous hash field within the selected block to mask the presence of the randomness field.
In some implementations, the altered data relative to the original data includes: data is added to the payload field, a revision of data from the payload field, or both.
In some implementations, the altered data relative to the original data includes a revision of the data from the payload field; and the rewrite circuit is configured to replace the original data with the altered data to comply with the data privacy rule.
In some implementations, the system further includes a trigger configured to deploy an anti-theft countermeasure when activated; and the memory includes a protected memory coupled to the flip-flop.
In another example, a method includes, in a hardware security system: accessing, via the communication interface circuit, a blockchain database configured to store a blockchain protected by a chameleon hash, the blockchain including a selected block including a payload field operable to store original data, a first previous hash field operable to store a first chameleon hash output, and a randomness field, a second block, subsequent to the selected block on the blockchain, including a second previous hash field operable to store a second chameleon Long Sanlie output, and a third block, prior to the selected block on the blockchain, the first chameleon hash output generated using content of the third block as input; receiving, via the communication interface circuit, a trusted party instruction to perform a non-tamper-proof overwriting of the payload field, the instruction specifying altered data to replace original data previously stored in the payload field; to facilitate execution of the instructions, receiving an authorization to access a key of the chameleon hash, the authorization initiated by a trusted party to the blockchain; and in the rewrite circuitry of the hardware security system, determining the randomness data using the payload field, the first previous hash field, and the key as inputs to write the randomness field, selecting the randomness data such that the discolouration Long Sanlie is configured to produce a second discolouration Long Sanlie output when the payload field contains modified data, the randomness field contains randomness data, and the discolouration hash is applied to the selected block; generating a rewrite instruction, the rewrite instruction comprising: a first command to write the randomness data into the randomness field; and a second command to replace the original data with the modified data; and sending the rewrite instruction to the blockchain database via the communication interface circuitry.
In some implementations, the color change Long Sanlie includes a rewritable cryptographic hash nested within a overwrite protection cryptographic hash.
In some implementations, the second block further includes a third previous hash field that includes a write protection hash output generated using a overwrite protection password hash that protects the blockchain in parallel with the color change Long Sanlie.
Various implementations have been described in detail. However, many other implementations are possible. Headings and/or sub-headings are used herein only for assisting the reader in understanding the described implementations. The invention is defined by the claims.

Claims (9)

1. A cryptographic logic system, comprising:
A memory (320);
a blockchain (100, 150) stored within the memory (320), the blockchain (100, 150) comprising:
A first block (B2, 106, 202) comprising raw data; and
A second block comprising:
A first integrity output (IC (B0)) calculated using the raw data as input; and
A second integrity output (IC (B0)) calculated using the raw data as input; and
The method is characterized in that: the system comprises:
Circuitry configured to:
Using the first key (421) to determine conflicting data comprising altered data, the conflicting data: consistent with the first integrity output (IC (B0),..ic (Bn-1)) encoding and inconsistent with the second integrity output (IC (B0),..ic (Bn-1)) encoding;
-performing tamper-resistant overwriting of the blockchain (100, 150) by replacing the original data with the conflicting data; and
-Generating a overwrite artifact in the blockchain (100, 150) by overwriting the first block (B2, 106, 202) with the altered data different from the original data, the altered data being consistent with the first integrity output (IC (B0), -an IC (Bn-1)) encoding but inconsistent with the second integrity output (IC (B0), -an IC (Bn-1)) encoding.
2. The system of claim 1, wherein the circuitry is configured to: the overwrite artifact is generated in the blockchain (100, 150) by performing an active overwrite to the blockchain (100, 150) to overwrite the first block (B2, 106, 202) with the altered data.
3. The system of claim 1 or 2, wherein the circuitry is further configured to: the first block (B2, 106, 202) is overwritten with approval data to remove the overwrite artifact by using an approval key, the approval data being consistent with the first integrity output (IC (B0),...
4. A system according to claim 3, wherein:
the approval data includes the altered data; and
The circuitry is configured to rewrite approval by a multiple trusted party for the blockchain (100, 150) to rewrite the first block (B2, 106, 202) with the approval data.
5. The system of claim 1 or 2, wherein the circuitry is configured to:
-using the first key to overwrite the first block (B2, 106, 202) with the altered data; and
The first key is generated by combining parts of the first key in a key exchange before overwriting the first block (B2, 106, 202) with the altered data.
6. The system of claim 5, wherein the circuitry is configured to: the plurality of portions are combined when the count of the plurality of portions exceeds a first threshold for valid tamper-resistant overwrites.
7. The system of claim 5, wherein the circuitry is configured to: combining the plurality of portions when a count of the plurality of portions exceeds a first threshold for valid tamper-resistant overwrites, but does not exceed a second threshold for valid non-tamper-resistant overwrites, the valid non-tamper-resistant overwrites being consistent with the second integrity output (IC (B0),...
8. The system of claim 1 or 2, wherein the circuitry is further configured to:
Determining to overwrite the original data in the first block (B2, 106, 202) of the blockchain (100, 150) with the altered data, the altered data being different from the original data previously stored in the first block (B2, 106, 202); and
-Performing tamper-resistant overwriting of the blockchain (100, 150) by replacing the original data with the conflicting data; and
Wherein the first integrity output and the second integrity output are generated in response to the original data and are consistent with the original data encoding.
9. The system of claim 1 or 2, wherein the circuit comprises a rewrite circuit (441), or wherein the circuit is a rewrite circuit (441).
CN202110194119.7A 2016-05-23 2017-05-23 Multilink cipher logic block chain Active CN112968764B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110194119.7A CN112968764B (en) 2016-05-23 2017-05-23 Multilink cipher logic block chain

Applications Claiming Priority (17)

Application Number Priority Date Filing Date Title
EP16425044 2016-05-23
EP16425044.1 2016-05-23
EP16425086.2 2016-08-11
EP16425086 2016-08-11
EP17425018.3 2017-02-17
EP17425018 2017-02-17
US15/596,922 2017-05-16
US15/596,922 US9785369B1 (en) 2016-05-23 2017-05-16 Multiple-link blockchain
US15/596,899 2017-05-16
US15/596,904 2017-05-16
US15/596,932 US9967096B2 (en) 2016-05-23 2017-05-16 Rewritable blockchain
US15/596,904 US9967088B2 (en) 2016-05-23 2017-05-16 Rewritable blockchain
US15/596,932 2017-05-16
US15/596,899 US9774578B1 (en) 2016-05-23 2017-05-16 Distributed key secret for rewritable blockchain
CN202110194119.7A CN112968764B (en) 2016-05-23 2017-05-23 Multilink cipher logic block chain
PCT/EP2017/062242 WO2017202758A1 (en) 2016-05-23 2017-05-23 Multiple-link cryptologic blockchain
CN201780031862.2A CN109417478B (en) 2016-05-23 2017-05-23 Multi-link cipher logical block chain

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
CN201780031862.2A Division CN109417478B (en) 2016-05-23 2017-05-23 Multi-link cipher logical block chain

Publications (2)

Publication Number Publication Date
CN112968764A CN112968764A (en) 2021-06-15
CN112968764B true CN112968764B (en) 2024-05-21

Family

ID=59886899

Family Applications (3)

Application Number Title Priority Date Filing Date
CN201780031864.1A Active CN109417479B (en) 2016-05-23 2017-05-23 Cryptographic logic rewritable block chains
CN202110194119.7A Active CN112968764B (en) 2016-05-23 2017-05-23 Multilink cipher logic block chain
CN201780031862.2A Active CN109417478B (en) 2016-05-23 2017-05-23 Multi-link cipher logical block chain

Family Applications Before (1)

Application Number Title Priority Date Filing Date
CN201780031864.1A Active CN109417479B (en) 2016-05-23 2017-05-23 Cryptographic logic rewritable block chains

Family Applications After (1)

Application Number Title Priority Date Filing Date
CN201780031862.2A Active CN109417478B (en) 2016-05-23 2017-05-23 Multi-link cipher logical block chain

Country Status (6)

Country Link
US (12) US9967096B2 (en)
EP (6) EP3443707B1 (en)
CN (3) CN109417479B (en)
AU (2) AU2017269736B2 (en)
SG (2) SG11201809661SA (en)
WO (4) WO2017202759A1 (en)

Families Citing this family (259)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8874477B2 (en) 2005-10-04 2014-10-28 Steven Mark Hoffberg Multifactorial optimization system and method
US9185095B1 (en) 2012-03-20 2015-11-10 United Services Automobile Association (Usaa) Behavioral profiling method and system to authenticate a user
US11277412B2 (en) 2018-05-28 2022-03-15 Royal Bank Of Canada System and method for storing and distributing consumer information
US10979410B1 (en) 2015-05-04 2021-04-13 United Services Automobile Association (Usaa) Systems and methods for utilizing cryptology with virtual ledgers in support of transactions and agreements
US10366247B2 (en) 2015-06-02 2019-07-30 ALTR Solutions, Inc. Replacing distinct data in a relational database with a distinct reference to that data and distinct de-referencing of database data
US10263981B1 (en) 2015-12-02 2019-04-16 United Services Automobile Association (Usaa) Public authentication systems and methods
US10262164B2 (en) 2016-01-15 2019-04-16 Blockchain Asics Llc Cryptographic ASIC including circuitry-encoded transformation function
US10454677B1 (en) 2016-02-24 2019-10-22 United Services Automobile Associate (USAA) Cryptographic key generation from biometric data
US9967096B2 (en) 2016-05-23 2018-05-08 Accenture Global Solutions Limited Rewritable blockchain
US10204341B2 (en) * 2016-05-24 2019-02-12 Mastercard International Incorporated Method and system for an efficient consensus mechanism for permissioned blockchains using bloom filters and audit guarantees
US11854011B1 (en) 2016-07-11 2023-12-26 United Services Automobile Association (Usaa) Identity management framework
US10097344B2 (en) 2016-07-15 2018-10-09 Mastercard International Incorporated Method and system for partitioned blockchains and enhanced privacy for permissioned blockchains
CN106897348B (en) * 2016-08-19 2020-10-27 创新先进技术有限公司 Data storage method, data verification method, data source tracing method and equipment
KR101849918B1 (en) * 2016-10-26 2018-04-19 주식회사 코인플러그 Method for issuing and paying money in use of unspent transaction output based protocol, and server using the same
US10367645B2 (en) * 2016-10-26 2019-07-30 International Business Machines Corporation Proof-of-work for smart contracts on a blockchain
US10171509B2 (en) * 2016-11-10 2019-01-01 International Business Machines Corporation Filtering and redacting blockchain transactions
CN106991334B (en) 2016-11-24 2021-03-02 创新先进技术有限公司 Data access method, system and device
WO2018103850A1 (en) * 2016-12-08 2018-06-14 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for creating a finite blockchain
US10389518B2 (en) 2017-01-27 2019-08-20 Entit Software Llc Blockchain hash value recomputation
US10291413B2 (en) 2017-02-17 2019-05-14 Accenture Global Solutions Limited Hardware blockchain corrective consensus operating procedure enforcement
US9998286B1 (en) 2017-02-17 2018-06-12 Accenture Global Solutions Limited Hardware blockchain consensus operating procedure enforcement
EP3593305A4 (en) 2017-03-08 2020-10-21 IP Oversight Corporation System and method for creating commodity asset-secured tokens from reserves
US10762506B1 (en) 2017-05-11 2020-09-01 United Services Automobile Association Token device for distributed ledger based interchange
US10462213B2 (en) * 2017-05-18 2019-10-29 Bank Of America Corporation Block chain encoding with fair delay for distributed network devices
US10749670B2 (en) * 2017-05-18 2020-08-18 Bank Of America Corporation Block chain decoding with fair delay for distributed network devices
DE102017209014A1 (en) * 2017-05-30 2018-12-06 Robert Bosch Gmbh Method and apparatus for attaching transactions to a block chain
US10805072B2 (en) * 2017-06-12 2020-10-13 Change Healthcare Holdings, Llc System and method for autonomous dynamic person management
CN107291862A (en) * 2017-06-12 2017-10-24 腾讯科技（深圳）有限公司 Business datum storage method, device, storage medium and electronic equipment
GB201710176D0 (en) 2017-06-26 2017-08-09 Nchain Holdings Ltd Computer-implemented system and method
JP2019012415A (en) * 2017-06-30 2019-01-24 株式会社ｂｉｔＦｌｙｅｒ Method for building consensus in network and nodes constituting network
JP6990055B2 (en) * 2017-07-12 2022-01-12 株式会社日立製作所 How and systems to recover data in distributed computing systems
US10984134B2 (en) 2017-07-14 2021-04-20 Microsoft Technology Licensing, Llc Blockchain system for leveraging member nodes to achieve consensus
GB201711878D0 (en) 2017-07-24 2017-09-06 Nchain Holdings Ltd Computer - implemented system and method
US10805085B1 (en) 2017-08-24 2020-10-13 United Services Automobile Association (Usaa) PKI-based user authentication for web services using blockchain
CN107590738A (en) 2017-08-24 2018-01-16 阿里巴巴集团控股有限公司 Processing method, device and the server of selection common recognition node
US10476855B1 (en) * 2017-08-29 2019-11-12 Salesforce.Com, Inc. Identity confirmation using private keys
US10296248B2 (en) 2017-09-01 2019-05-21 Accenture Global Solutions Limited Turn-control rewritable blockchain
US10803022B2 (en) 2017-09-08 2020-10-13 ULedger, Inc. Systems and methods of providing immutable records
US11403424B2 (en) * 2017-09-14 2022-08-02 Sony Corporation Information processing apparatus and information processing method
CN107862215B (en) 2017-09-29 2020-10-16 创新先进技术有限公司 Data storage method, data query method and device
US11455643B2 (en) * 2017-10-09 2022-09-27 Koninklijke Kpn N.V. Blockchain with transaction cancellation
WO2019077126A1 (en) 2017-10-20 2019-04-25 Koninklijke Kpn N.V. Primary and secondary blockchain device
US10862672B2 (en) * 2017-10-24 2020-12-08 Intuit, Inc. Witness blocks in blockchain applications
DE102017126349A1 (en) * 2017-11-10 2019-05-16 Bundesdruckerei Gmbh METHOD FOR CONNECTING A FIRST DATA BLOCK TO A SECOND DATA BLOCK, METHOD FOR VERIFYING THE INTEGRITY OF A BLOCK CHAIN STRUCTURE, DEVICE AND COMPUTER PROGRAM PRODUCT
US11502828B2 (en) * 2017-11-15 2022-11-15 International Business Machines Corporation Authenticating chaincode to chaincode invocations of a blockchain
US10944566B2 (en) * 2017-11-15 2021-03-09 International Business Machines Corporation Methods and systems for supporting fairness in secure computations
US10567168B2 (en) * 2017-11-16 2020-02-18 International Business Machines Corporation Blockchain transaction privacy enhancement through broadcast encryption
EP3711260A1 (en) * 2017-11-16 2020-09-23 Accenture Global Solutions Limited Blockchain operation stack for rewritable blockchain
TWI653864B (en) * 2017-11-21 2019-03-11 國立交通大學 High security blockchain data transmission method
CN108171494A (en) 2017-11-23 2018-06-15 阿里巴巴集团控股有限公司 A kind of data processing method and device
US11146532B2 (en) 2017-11-27 2021-10-12 Kevin Tobin Information security using blockchain technology
US10937111B2 (en) * 2017-11-28 2021-03-02 International Business Machines Corporation Managing energy purchase agreements on a blockchain
US11159537B2 (en) 2017-11-30 2021-10-26 Bank Of America Corporation Multicomputer processing for data authentication and event execution using a blockchain approach
WO2019109003A1 (en) 2017-11-30 2019-06-06 Visa International Service Association Blockchain system for confidential and anonymous smart contracts
US10949511B2 (en) 2017-11-30 2021-03-16 Bank Of America Corporation Multicomputer processing for data authentication using a blockchain approach
US11243945B2 (en) * 2017-12-11 2022-02-08 International Business Machines Corporation Distributed database having blockchain attributes
GB201721021D0 (en) * 2017-12-15 2018-01-31 Nchain Holdings Ltd Computer-implemented methods and systems
US11139979B2 (en) 2017-12-18 2021-10-05 Koninklijke Kpn N.V. Primary and secondary blockchain device
US10831911B2 (en) * 2017-12-19 2020-11-10 Industrial Technology Research Institute Method, computer program product and processing system for generating secure alternative representation
US10686586B2 (en) 2017-12-22 2020-06-16 Intuit, Inc. Re-encrypting data on a hash chain
US11082203B2 (en) * 2017-12-27 2021-08-03 Nokia Solutions And Networks Oy Method and apparatus for accelerating the blockchain for secure and high throughput applications
CN108063826B (en) * 2017-12-27 2020-08-14 上海唯链信息科技有限公司 Sharing and tracing system of Internet of vehicles based on block chain technology
US11544708B2 (en) 2017-12-29 2023-01-03 Ebay Inc. User controlled storage and sharing of personal user information on a blockchain
US10715323B2 (en) 2017-12-29 2020-07-14 Ebay Inc. Traceable key block-chain ledger
US11249982B2 (en) * 2018-01-19 2022-02-15 Acronis International Gmbh Blockchain-based verification of machine learning
CN108269185B (en) * 2018-01-19 2020-12-15 创新先进技术有限公司 Method and device for generating fund flow report table and electronic equipment
US10671709B2 (en) 2018-01-22 2020-06-02 Intuit, Inc. Data isolation in distributed hash chains
CN108520410B (en) * 2018-02-09 2020-09-11 北京欧链科技有限公司 Feedback processing method and device in block chain
CN108519985B (en) * 2018-02-09 2020-09-11 北京欧链科技有限公司 Bidirectional block chain, data processing method and device
KR102093010B1 (en) * 2018-02-12 2020-03-24 박성배 Node device, operation method baed on block chain and system for processing data
US11387981B2 (en) * 2018-02-13 2022-07-12 Accenture Global Solutions Limited Platform for multi-party digital records using distributed ledger system
US10614253B2 (en) 2018-02-14 2020-04-07 Fortune Vieyra Systems and methods for state of data management
US10817829B2 (en) * 2018-02-23 2020-10-27 Bank Of America Corporation Blockchain-based supply chain smart recall
US11055658B2 (en) 2018-02-23 2021-07-06 Bank Of America Corporation Blockchain-based supply chain certification systems and methods
EP3759630A4 (en) * 2018-03-02 2021-11-24 Blocksafe Technologies, Inc. Systems and methods for controlling access to a blockchain
US10489780B2 (en) 2018-03-05 2019-11-26 Capital One Services, Llc Systems and methods for use of distributed ledger technology for recording and utilizing credit account transaction information
US11836720B2 (en) 2018-03-12 2023-12-05 The Pen Infinitely scalable cryptocurrency system with fast, secure verification
US10372943B1 (en) 2018-03-20 2019-08-06 Blockchain Asics Llc Cryptographic ASIC with combined transformation and one-way functions
US10304062B1 (en) 2018-03-23 2019-05-28 Td Professional Services, Llc Computer architecture incorporating blockchain based immutable audit ledger for compliance with data regulations
US11315369B2 (en) 2018-03-23 2022-04-26 The Boeing Company Blockchain configuration history for vehicle maintenance, modification, and activity tracking
US10567390B2 (en) 2018-03-26 2020-02-18 Bank Of America Corporation Peer to peer internet of things (“IoT”) validation system
CN108616574B (en) * 2018-03-30 2020-06-16 华为技术有限公司 Management data storage method, device and storage medium
JP7091791B2 (en) * 2018-04-06 2022-06-28 富士通株式会社 Data management device, data management program and data management method
US10275400B1 (en) * 2018-04-11 2019-04-30 Xanadu Big Data, Llc Systems and methods for forming a fault-tolerant federated distributed database
US10084600B1 (en) * 2018-04-16 2018-09-25 Xage Security, Inc. Decentralized information protection for confidentiality and tamper-proofing on distributed database
US11563557B2 (en) 2018-04-24 2023-01-24 International Business Machines Corporation Document transfer processing for blockchains
US10404454B1 (en) 2018-04-25 2019-09-03 Blockchain Asics Llc Cryptographic ASIC for derivative key hierarchy
US11030217B2 (en) 2018-05-01 2021-06-08 International Business Machines Corporation Blockchain implementing cross-chain transactions
US11194837B2 (en) 2018-05-01 2021-12-07 International Business Machines Corporation Blockchain implementing cross-chain transactions
US11150271B2 (en) 2018-05-15 2021-10-19 International Business Machines Corporation Method or system for management of a device for energy consumption by applying blockchain protocol
US10592873B2 (en) * 2018-05-21 2020-03-17 Microsoft Technology Licensing, Llc Edit transactions for blockchains
WO2019226986A1 (en) 2018-05-24 2019-11-28 Walmart Apollo, Llc Nested blockchain system
WO2019227052A1 (en) 2018-05-24 2019-11-28 Walmart Apollo, Llc System and methods for multi-variant tracking
US20190361869A1 (en) * 2018-05-24 2019-11-28 Imagerights International, Inc. Systems, devices, and methods for tracking creation and modification of digital records
WO2019227025A1 (en) * 2018-05-24 2019-11-28 Walmart Apollo, Llc System and methods for exception handling in a distributed computing environment
US10693716B2 (en) 2018-05-29 2020-06-23 At&T Mobility Ii Llc Blockchain based device management
US11521232B2 (en) * 2018-06-04 2022-12-06 Yahoo Ad Tech Llc Method and system for identifying recipients of a reward associated with a conversion
US11269839B2 (en) 2018-06-05 2022-03-08 Oracle International Corporation Authenticated key-value stores supporting partial state
US11244316B2 (en) 2018-06-07 2022-02-08 International Business Machines Corporation Biometric token for blockchain
US20190378128A1 (en) * 2018-06-08 2019-12-12 Rocket Lawyer Incorporated Cryptographic Contract Payment and Dispute Resolution System
GB2574628B (en) * 2018-06-13 2020-12-09 Arm Ip Ltd Attestation of processing
US10771240B2 (en) 2018-06-13 2020-09-08 Dynamic Blockchains Inc Dynamic blockchain system and method for providing efficient and secure distributed data access, data storage and data transport
WO2019237275A1 (en) * 2018-06-13 2019-12-19 汪华东 Block chain technology-based authenticity check system
CN108830602B (en) * 2018-06-27 2022-03-29 电子科技大学 Permission chain construction and management and control method based on chameleon hash function
US11516013B2 (en) * 2018-06-28 2022-11-29 Intel Corporation Accelerator for encrypting or decrypting confidential data with additional authentication data
CN109242699A (en) * 2018-06-28 2019-01-18 平安科技（深圳）有限公司 Medical insurance Claims Resolution method, system and computer equipment based on block chain
US11836721B2 (en) 2018-06-29 2023-12-05 Intel Corporation Protection of information in an information exchange
CN110661610B (en) * 2018-06-29 2020-11-03 创新先进技术有限公司 Input acquisition method and device of secure multi-party computing protocol
US10855749B2 (en) * 2018-07-03 2020-12-01 Wandisco Inc. Methods, devices and systems for a distributed coordination engine-based exchange that implements a blockchain distributed ledger
CN108960829A (en) * 2018-07-06 2018-12-07 佛山伊苏巨森科技有限公司 A kind of distributed recording system based on block chain
CN108932620A (en) * 2018-07-06 2018-12-04 佛山伊苏巨森科技有限公司 A kind of block catenary system and its execute method
US20210281570A1 (en) * 2018-07-12 2021-09-09 Nokia Technologies Oy Enabling access to devices in a communication network
CN109002527B (en) * 2018-07-13 2020-12-01 江苏开放大学（江苏城市职业学院） Block chain-based network examination system and method for managing network examination
US10721073B2 (en) * 2018-07-27 2020-07-21 Hrl Laboratories, Llc Bidirectional blockchain
US11374753B2 (en) 2018-07-27 2022-06-28 Hrl Laboratories, Llc System and method for selective transparency for public ledgers
EP3831013A4 (en) * 2018-07-27 2022-04-20 HRL Laboratories, LLC System and method to protect data privacy of lightweight devices using blockchain and multi-party computation
CN109040227B (en) * 2018-07-27 2021-08-03 江西贪玩信息技术有限公司 Service request response method and device based on block chain and computer equipment
CN109274481B (en) * 2018-08-01 2020-03-27 中国科学院数据与通信保护研究教育中心 Data traceable method of block chain
CN109145053B (en) * 2018-08-01 2021-03-23 创新先进技术有限公司 Data processing method and device, client and server
US11196555B1 (en) * 2018-08-02 2021-12-07 Timofei A Mouraveiko System and method for capturing, recording, monitoring, examining, filtering, processing, limiting and controlling intra-network and extra-network data communications
US11263124B2 (en) 2018-08-03 2022-03-01 Micron Technology, Inc. Host-resident translation layer validity check
CN109359971B (en) 2018-08-06 2020-05-05 阿里巴巴集团控股有限公司 Block chain transaction method and device and electronic equipment
CN109194718A (en) * 2018-08-09 2019-01-11 玄章技术有限公司 A kind of block chain network and its method for scheduling task
CN109241016B (en) * 2018-08-14 2020-07-07 阿里巴巴集团控股有限公司 Multi-party security calculation method and device and electronic equipment
CN109359470B (en) 2018-08-14 2020-09-01 阿里巴巴集团控股有限公司 Multi-party security calculation method and device and electronic equipment
US10721069B2 (en) 2018-08-18 2020-07-21 Eygs Llp Methods and systems for enhancing privacy and efficiency on distributed ledger-based networks
CN112651740A (en) 2018-08-30 2021-04-13 创新先进技术有限公司 Block chain transaction method and device and electronic equipment
WO2020047281A1 (en) 2018-08-30 2020-03-05 Ideola, Inc. System and method for memetic authentication and identification
CN109299053B (en) * 2018-09-04 2021-03-02 中国联合网络通信集团有限公司 File operation method, device and computer storage medium
US11032292B2 (en) 2018-09-04 2021-06-08 Allen Gluck Systems and methods for hybrid blockchain control
US11044104B2 (en) 2018-09-05 2021-06-22 International Business Machines Corporation Data certification as a service powered by permissioned blockchain network
KR20200034020A (en) 2018-09-12 2020-03-31 삼성전자주식회사 Electronic apparatus and control method thereof
RU2718480C2 (en) * 2018-09-14 2020-04-08 Общество С Ограниченной Ответственностью "Яндекс" Method and system for authorizing website in web browser
US11232221B2 (en) 2018-09-17 2022-01-25 International Business Machines Corporation Right to be forgotten on an immutable ledger
EP3627372A1 (en) * 2018-09-18 2020-03-25 Siemens Aktiengesellschaft Sensor data assembly and manufacturing device
CN109241192B (en) * 2018-09-18 2021-06-15 百度在线网络技术（北京）有限公司 Data modification and block verification method, device, equipment and medium for block chain
CN109344631B (en) * 2018-09-18 2020-11-06 百度在线网络技术（北京）有限公司 Data modification and block verification method, device, equipment and medium for block chain
CN109246341A (en) * 2018-09-19 2019-01-18 深圳市安思科电子科技有限公司 A kind of camera convenient for handling based on block chain technology
CN109584055B (en) 2018-09-20 2020-07-03 阿里巴巴集团控股有限公司 Transaction method and device based on block chain and remittance side equipment
US10715313B2 (en) * 2018-09-21 2020-07-14 Blockchain Certified Data Sas Systems and computer-based methods of document certification and publication
CN109492049B (en) * 2018-09-21 2021-05-04 上海点融信息科技有限责任公司 Data processing, block generation and synchronization method for block chain network
US10852964B2 (en) * 2018-09-25 2020-12-01 Micron Technology, Inc. Host-resident translation layer validity check techniques
CN111833057A (en) 2018-09-30 2020-10-27 创新先进技术有限公司 Transaction method and device based on block chain and node equipment
US11301452B2 (en) 2018-10-09 2022-04-12 Ebay, Inc. Storing and verification of derivative work data on blockchain with original work data
CN109462540A (en) * 2018-10-12 2019-03-12 彩讯科技股份有限公司 Mail deposits card methods, devices and systems
US11146399B2 (en) 2018-10-19 2021-10-12 Eygs Llp Methods and systems for retrieving zero-knowledge proof-cloaked data on distributed ledger-based networks
US11416475B2 (en) * 2018-10-19 2022-08-16 Adobe Inc. Block quantity reduction in distributed ledgers
US11240001B2 (en) * 2018-11-06 2022-02-01 International Business Machines Corporation Selective access to asset transfer data
CN110046517B (en) * 2018-11-07 2020-05-05 阿里巴巴集团控股有限公司 Method and device for hiding transaction written into block chain
US10974851B2 (en) 2018-11-09 2021-04-13 Textron Innovations Inc. System and method for maintaining and configuring rotorcraft
EP3654578B1 (en) 2018-11-16 2022-04-06 SafeTech BV Methods and systems for cryptographic private key management for secure multiparty storage and transfer of information
CN109164780B (en) * 2018-11-22 2020-06-16 北京八分量信息科技有限公司 Industrial field device control method, device and system based on edge calculation
DE102018220224A1 (en) 2018-11-26 2020-05-28 Deutsche Bahn Ag Method for tamper-proof storage of data in an electronic memory using a chained blockchain structure
US20200174990A1 (en) * 2018-11-29 2020-06-04 Anthony Turner Pratkanis Accountably Redactable Data Structures
EP3660770A1 (en) * 2018-11-30 2020-06-03 Mastercard International Incorporated Methods and systems for secure product tracking data storage and verification
CN109361504B (en) * 2018-12-04 2021-10-08 桂林电子科技大学 Block chain-based multi-user communication key negotiation method
US10909261B2 (en) 2018-12-12 2021-02-02 Industrial Technology Research Institute Method and computer program product for generating secure alternative representation for numerical datum
US11151512B2 (en) * 2018-12-14 2021-10-19 The Boeing Company Interlocking blockchains for aircraft part history and current aircraft configuration
EP3668036A1 (en) * 2018-12-14 2020-06-17 Siemens Aktiengesellschaft Creation of a blockchain with blocks comprising an adjustable number of transaction blocks and multiple intermediate blocks
US11226907B2 (en) 2018-12-19 2022-01-18 Micron Technology, Inc. Host-resident translation layer validity check techniques
US10979213B2 (en) * 2018-12-19 2021-04-13 Verizon Media Inc. Blockchain compression using summary and padding blocks
US11032064B2 (en) 2018-12-19 2021-06-08 Verizon Media Inc. Blockchain ledger growth management
US11139960B2 (en) 2018-12-20 2021-10-05 International Business Machines Corporation File redaction database system
CN110046156A (en) * 2018-12-20 2019-07-23 阿里巴巴集团控股有限公司 Content Management System and method, apparatus, electronic equipment based on block chain
US11025430B2 (en) 2018-12-20 2021-06-01 International Business Machines Corporation File provenance database system
US11151236B2 (en) 2018-12-20 2021-10-19 International Business Machines Corporation File verification database system
US10861008B2 (en) 2018-12-21 2020-12-08 Capital One Services, Llc System and method for optimizing cryptocurrency transactions
US11226894B2 (en) 2018-12-21 2022-01-18 Micron Technology, Inc. Host-based flash memory maintenance techniques
US10637644B1 (en) * 2018-12-21 2020-04-28 Capital One Services, Llc System and method for authorizing transactions in an authorized member network
US11588643B2 (en) * 2018-12-27 2023-02-21 Paypal, Inc. Blockchain management system
US11902448B2 (en) * 2018-12-28 2024-02-13 The Flowchain Foundation Limited Hybrid blockchain architecture with computing pool
US11416854B2 (en) 2018-12-29 2022-08-16 Advanced New Technologies Co., Ltd. System and method for information protection
US10402823B1 (en) * 2018-12-30 2019-09-03 Alexander Vladimirovich Vlasov System for exchanging private keys for mutual settlements between users of a cryptocurrency outside blockchains
US11115186B2 (en) 2019-01-02 2021-09-07 Bank Of America Corporation Blockchain management platform for performing asset adjustment, cross sectional editing, and bonding
US11012232B2 (en) 2019-01-02 2021-05-18 Bank Of America Corporation Blockchain management platform for performing asset adjustment, cross sectional editing, and bonding
US11018848B2 (en) 2019-01-02 2021-05-25 Bank Of America Corporation Blockchain management platform for performing asset adjustment, cross sectional editing, and bonding
CN109672529A (en) * 2019-01-07 2019-04-23 苏宁易购集团股份有限公司 A kind of method and system for going anonymization of combination block chain and privacy sharing
US11095660B2 (en) 2019-01-30 2021-08-17 Toyota Motor Engineering & Manufacturing North America, Inc. Blockchain enabled encryption
JP2020126409A (en) * 2019-02-04 2020-08-20 株式会社日立製作所 Data managing system and data managing method
CN109714165B (en) * 2019-02-28 2021-12-07 矩阵元技术（深圳）有限公司 Key management method for client to generate key components respectively and electronic equipment
US11397814B2 (en) * 2019-03-25 2022-07-26 Micron Technology, Inc. Local ledger block chain for secure electronic control unit updates
US11120040B2 (en) 2019-03-26 2021-09-14 International Business Machines Corporation Multi-ledger blockchain management
US11151261B2 (en) 2019-04-03 2021-10-19 Cisco Technology, Inc. Blockchain system with severable data and cryptographic proof
CN110209347B (en) * 2019-04-04 2020-08-11 特斯联（北京）科技有限公司 Traceable data storage method
US11677563B2 (en) 2019-04-15 2023-06-13 Eygs Llp Systems, apparatus and methods for local state storage of distributed ledger data without cloning
US11316691B2 (en) 2019-04-15 2022-04-26 Eygs Llp Methods and systems for enhancing network privacy of multiple party documents on distributed ledger-based networks
US11502838B2 (en) 2019-04-15 2022-11-15 Eygs Llp Methods and systems for tracking and recovering assets stolen on distributed ledger-based networks
US11943358B2 (en) 2019-04-15 2024-03-26 Eygs Llp Methods and systems for identifying anonymized participants of distributed ledger-based networks using zero-knowledge proofs
US11128482B2 (en) * 2019-04-19 2021-09-21 Microsoft Technology Licensing, Llc Metering cloud workloads at edge computing devices
CN110061850B (en) * 2019-04-24 2021-04-23 电子科技大学 Collision calculation method of chameleon hash function and editable block chain construction method
US11150978B2 (en) 2019-04-26 2021-10-19 Bank Of America Corporation Automated system for intelligent error correction within an electronic blockchain ledger
US11206138B2 (en) 2019-05-02 2021-12-21 Ernst & Young U.S. Llp Biosignature-based tokenization of assets in a blockchain
CN110231979A (en) * 2019-05-07 2019-09-13 深圳壹账通智能科技有限公司 Transaction methods, device, equipment and storage medium based on block chain
CN110086633B (en) * 2019-05-13 2020-08-14 广东辰宜信息科技有限公司 Ciphertext anti-tampering method in block chain technology
CN111949315A (en) * 2019-05-16 2020-11-17 富士通株式会社 Management device and method for block chain account book data
US11469886B2 (en) 2019-05-22 2022-10-11 Salesforce.Com, Inc. System or method to implement record level access on metadata driven blockchain using shared secrets and consensus on read
US11120160B2 (en) 2019-05-31 2021-09-14 Advanced New Technologies Co., Ltd. Distributed personal data storage and encrypted personal data service based on secure computation
US11115191B2 (en) 2019-05-31 2021-09-07 Hcl America Inc System and method for modifying content stored in a blockchain
EP3982591A4 (en) * 2019-06-05 2022-07-27 Sony Group Corporation Information processing device and information processing method
US11223475B2 (en) 2019-06-05 2022-01-11 International Business Machines Corporation Document validation
US20220239489A1 (en) * 2019-06-05 2022-07-28 Sony Group Corporation Identity verification program, identity verification method, user terminal, and user authentication program
US11606442B2 (en) * 2019-06-07 2023-03-14 Microsoft Technology Licensing, Llc Subscription to edits of blockchain transaction
CN110377609B (en) * 2019-06-17 2021-11-02 北京航空航天大学 Intelligent contract dynamic deployment and evolution method and device based on block chain
CN110445840B (en) * 2019-07-09 2020-07-03 北京健网未来科技有限公司 File storage and reading method based on block chain technology
CN110427774B (en) * 2019-07-18 2021-01-12 创新先进技术有限公司 Block chain-based data storage method, data verification method and related device
US11088828B2 (en) 2019-07-18 2021-08-10 Advanced New Technologies Co., Ltd. Blockchain-based data evidence storage method and apparatus
US11201746B2 (en) 2019-08-01 2021-12-14 Accenture Global Solutions Limited Blockchain access control system
SG10201907330WA (en) * 2019-08-08 2020-01-30 Alibaba Group Holding Ltd Methods And Devices For Executing N-Time Hashed Time Lock Contracts
US11232439B2 (en) 2019-08-09 2022-01-25 Eygs Llp Methods and systems for preventing transaction tracing on distributed ledger-based networks
CN110474762B (en) * 2019-08-22 2021-05-25 电子科技大学 Method for constructing ring-type editable block chain
WO2021040773A1 (en) * 2019-08-28 2021-03-04 Micro Focus Llc Blockchain data forgetability
US11567927B2 (en) * 2019-09-18 2023-01-31 Boardwalktech, Inc Creating blocks in instance blockchain base on a promised block in a generic blockchain
US11431473B2 (en) * 2019-09-20 2022-08-30 Mastercard International Incorporated Method and system for distribution of a consistent ledger across multiple blockchains
US11115804B2 (en) 2019-10-04 2021-09-07 Microsoft Technology Licensing, Llc Subscription to dependencies in smart contracts
JPWO2021070838A1 (en) * 2019-10-11 2021-04-15
CN110751853B (en) * 2019-10-25 2021-05-18 百度在线网络技术（北京）有限公司 Parking space data validity identification method and device
US20210135855A1 (en) * 2019-10-30 2021-05-06 EMC IP Holding Company LLC Threshold-Based Override of Data Privacy Using Distributed Ledgers and Key Shares
US11481841B2 (en) 2019-11-20 2022-10-25 Eygs Llp Systems, apparatus and methods for identifying distinguishing characteristics of fungible assets using zero-knowledge proof on a distributed ledger-based network
US11587189B2 (en) * 2019-11-27 2023-02-21 International Business Machines Corporation Formal verification of smart contracts
US11403281B2 (en) * 2020-01-09 2022-08-02 Eternal Paradise Limited Parallel blockchain processing
CN111428278A (en) * 2020-03-24 2020-07-17 国网山西省电力公司信息通信分公司 Electronic evidence management method and device
CN111526009B (en) * 2020-04-09 2021-06-15 西南交通大学 Forward security editable block chain construction method suitable for alliance chain
CA3180231A1 (en) 2020-04-15 2021-10-21 Eygs Llp Intelligent assertion tokens for authenticating and controlling network communications using a distributed ledger
DE102020205993B3 (en) * 2020-05-13 2021-09-16 Volkswagen Aktiengesellschaft Concept for the exchange of cryptographic key information
US20210374843A1 (en) * 2020-05-26 2021-12-02 Mitsubishi Electric Research Laboratories, Inc. Debt Resource Management in a Distributed Ledger System
US11947659B2 (en) 2020-05-28 2024-04-02 Red Hat, Inc. Data distribution across multiple devices using a trusted execution environment in a mobile device
US11971980B2 (en) 2020-05-28 2024-04-30 Red Hat, Inc. Using trusted execution environments to perform a communal operation for mutually-untrusted devices
US11546315B2 (en) * 2020-05-28 2023-01-03 Hewlett Packard Enterprise Development Lp Authentication key-based DLL service
US11777720B2 (en) 2020-06-12 2023-10-03 Nagravision Sàrl Distributed anonymized compliant encryption management system
SG10202006451QA (en) 2020-07-03 2021-02-25 Alipay Labs Singapore Pte Ltd Managing transactions in multiple blockchain networks
SG10202006447VA (en) * 2020-07-03 2021-04-29 Alipay Labs Singapore Pte Ltd Managing transactions in multiple blockchain networks
CN112054990B (en) * 2020-07-21 2022-09-16 杜晓楠 Method for preventing Hash flood attack in blockchain system, computer readable medium and blockchain system
CN111753335B (en) * 2020-08-28 2023-09-01 支付宝(杭州)信息技术有限公司 Editing method and device for block content
US10965461B1 (en) * 2020-08-31 2021-03-30 Syniverse Technologies, Llc Method of verifying telecommunications messaging traffic based on decentralized identifiers
US11848924B2 (en) 2020-10-12 2023-12-19 Red Hat, Inc. Multi-factor system-to-system authentication using secure execution environments
CN112070501B (en) * 2020-11-10 2021-03-02 支付宝(杭州)信息技术有限公司 Block chain transaction initiating and verifying method and system
US20220179997A1 (en) * 2020-12-04 2022-06-09 Microchip Technology Incorporated Higher-layer-processing data in time-sensitive data blocks at a physical-layer-interface device
US11720540B2 (en) 2020-12-30 2023-08-08 Itron, Inc. Secure blockchain data recovery
US11588620B2 (en) 2020-12-30 2023-02-21 Itron, Inc. Forming a blockchain in low-bandwidth, resource-constrained network
US11762844B2 (en) 2020-12-30 2023-09-19 Itron, Inc. Secure trimming of blockchain in a resource-constrained network
CN112380584B (en) * 2021-01-13 2021-04-16 北京笔新互联网科技有限公司 Block chain data updating method and device, electronic equipment and storage medium
JPWO2022153425A1 (en) * 2021-01-14 2022-07-21
CN112436940B (en) * 2021-01-27 2021-04-30 电子科技大学 Internet of things equipment trusted boot management method based on zero-knowledge proof
US11544014B2 (en) 2021-01-28 2023-01-03 Kyocera Document Solutions Inc. Printing system and device for processing transactions in a distributed ledger
WO2022225468A1 (en) 2021-04-20 2022-10-27 Angel Time Co., Ltd. Multi dimension blockchain
CN113268542A (en) * 2021-05-10 2021-08-17 西安交通大学 Block chain rewriting method and system based on multi-party authorization
US20220407681A1 (en) * 2021-06-21 2022-12-22 Research Foundation Of The City University Of New York Redactable blockchain
WO2023288205A1 (en) * 2021-07-10 2023-01-19 Artema Labs, Inc Artifact origination and content tokenization
US11979484B2 (en) * 2021-07-21 2024-05-07 Bank Of America Corporation System for electronic data encryption and decryption using a consensus draft process
CN113468517A (en) * 2021-09-02 2021-10-01 北京交研智慧科技有限公司 Data sharing method, system and storage medium based on block chain
WO2023060284A1 (en) * 2021-10-09 2023-04-13 Artema Labs, Inc. Cryptographic content co-creation mechanisms and linking physical elements to cryptographic elements
CN113810430B (en) * 2021-11-19 2022-02-11 北京亿赛通网络安全技术有限公司 Access authentication method and system for protecting cloud data privacy
US12015706B2 (en) * 2021-12-14 2024-06-18 Micron Technology, Inc. Combined cryptographic key management services for access control and proof of space
US11941254B2 (en) 2021-12-14 2024-03-26 Micron Technology, Inc. Test memory sub-systems through validation of responses to proof of space challenges
US11960756B2 (en) 2021-12-14 2024-04-16 Micron Technology, Inc. Management of storage space in solid state drives to support proof of space activities
US11977742B2 (en) 2022-02-02 2024-05-07 Micron Technology, Inc. Solid state drives configurable to use storage spaces of remote devices in activities involving proof of space
US20230308285A1 (en) * 2022-03-25 2023-09-28 Micro Focus Llc Retroactively adding encryption and/or authentication levels to a blockchain
CN115208554B (en) * 2022-09-13 2022-12-13 三未信安科技股份有限公司 Management method and system for key self-checking, self-correcting and self-recovering
US11880836B1 (en) * 2022-10-04 2024-01-23 Veri Labs, Inc. Gated control for blockchain units

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5608178A (en) * 1993-12-29 1997-03-04 Yamaha Corporation Method of storing and editing performance data in an automatic performance device
CN105404701A (en) * 2015-12-31 2016-03-16 浙江图讯科技股份有限公司 Peer-to-peer network-based heterogeneous database synchronization method
CN105488665A (en) * 2015-11-25 2016-04-13 布比（北京）网络技术有限公司 Decentralized transaction method
CN105592098A (en) * 2016-01-16 2016-05-18 杭州复杂美科技有限公司 Management method of vote and CA certificate of block chain

Family Cites Families (91)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE69332633T2 (en) 1992-07-20 2003-11-06 Compaq Computer Corp Procedure and system for discovering aliases based on certification
US20020013898A1 (en) 1997-06-04 2002-01-31 Sudia Frank W. Method and apparatus for roaming use of cryptographic values
US6708274B2 (en) 1998-04-30 2004-03-16 Intel Corporation Cryptographically protected paging subsystem
US6292897B1 (en) 1997-11-03 2001-09-18 International Business Machines Corporation Undeniable certificates for digital signature verification
US6108783A (en) * 1998-02-11 2000-08-22 International Business Machines Corporation Chameleon hashing and signatures
EP1203332A4 (en) 1999-02-12 2002-09-25 Mack Hicks System and method for providing certification-related and other services
US7167565B2 (en) 2001-03-06 2007-01-23 Arcot Systems, Inc. Efficient techniques for sharing a secret
US7043637B2 (en) * 2001-03-21 2006-05-09 Microsoft Corporation On-disk file format for a serverless distributed file system
US7451310B2 (en) 2002-12-02 2008-11-11 International Business Machines Corporation Parallelizable authentication tree for random access storage
JP4176533B2 (en) 2003-03-31 2008-11-05 株式会社エヌ・ティ・ティ・ドコモ Terminal device and program
GB2403107B (en) 2003-06-19 2006-06-14 Hewlett Packard Development Co Policy enforcement
US20050071640A1 (en) 2003-09-25 2005-03-31 General Instrument Corporation Method and apparatus for authenticating data
US7730319B2 (en) * 2004-08-27 2010-06-01 Ntt Docomo, Inc. Provisional signature schemes
US8019988B2 (en) 2005-08-22 2011-09-13 The State Of Oregon Acting By And Through The State Board Of Higher Education On Behalf Of The University Of Oregon Security protocols for hybrid peer-to-peer file sharing networks
US8989390B2 (en) 2005-12-12 2015-03-24 Qualcomm Incorporated Certify and split system and method for replacing cryptographic keys
JP4642845B2 (en) 2005-12-19 2011-03-02 日本電信電話株式会社 Terminal identification method, server, terminal, and program
WO2007087363A2 (en) 2006-01-24 2007-08-02 Brown University Efficient content authentication in peer-to-peer networks
US20070226514A1 (en) 2006-03-24 2007-09-27 Atmel Corporation Secure biometric processing system and method of use
US8190915B2 (en) 2006-06-14 2012-05-29 Oracle International Corporation Method and apparatus for detecting data tampering within a database
EP2061178A4 (en) * 2006-09-01 2011-10-12 Nec Corp Electronic signature system and electronic signature verifying method
US8943332B2 (en) 2006-10-31 2015-01-27 Hewlett-Packard Development Company, L.P. Audit-log integrity using redactable signatures
US7606795B2 (en) * 2007-02-08 2009-10-20 International Business Machines Corporation System and method for verifying the integrity and completeness of records
JP4456137B2 (en) 2007-07-11 2010-04-28 富士通株式会社 Electronic document management program, recording medium recording the program, electronic document management apparatus, and electronic document management method
US8150038B2 (en) 2007-11-01 2012-04-03 Oracle America, Inc. Revocation of a system administrator in an encrypted file system
JP4477678B2 (en) * 2008-01-21 2010-06-09 富士通株式会社 Electronic signature method, electronic signature program, and electronic signature device
US7904450B2 (en) 2008-04-25 2011-03-08 Wilson Kelce S Public electronic document dating list
US20100037056A1 (en) 2008-08-07 2010-02-11 Follis Benjamin D Method to support privacy preserving secure data management in archival systems
JP2010050760A (en) * 2008-08-22 2010-03-04 Hitachi Ltd Content protection apparatus, and content utilization apparatus
US20100153732A1 (en) 2008-12-15 2010-06-17 Stmicroelectronics Rousset Sas cache-based method of hash-tree management for protecting data integrity
JP5239849B2 (en) 2008-12-26 2013-07-17 富士通株式会社 Electronic signature method, electronic signature program, and electronic signature device
EP2441207B8 (en) 2009-06-12 2020-08-05 Orange Cryptographic method for anonymous authentication and separate identification of a user
US8682903B2 (en) 2009-06-30 2014-03-25 International Business Machines Corporation System and method for synchronized content directories on cluster devices
US9569771B2 (en) 2011-04-29 2017-02-14 Stephen Lesavich Method and system for storage and retrieval of blockchain blocks using galois fields
US20130121410A1 (en) * 2011-11-14 2013-05-16 Mediatek Inc. Method and Apparatus of Video Encoding with Partitioned Bitstream
US8984582B2 (en) 2012-08-14 2015-03-17 Confidela Ltd. System and method for secure synchronization of data across multiple computing devices
US9876775B2 (en) 2012-11-09 2018-01-23 Ent Technologies, Inc. Generalized entity network translation (GENT)
US20140245020A1 (en) 2013-02-22 2014-08-28 Guardtime Ip Holdings Limited Verification System and Method with Extra Security for Lower-Entropy Input Records
WO2013189619A1 (en) 2013-04-05 2013-12-27 Nec Europe Ltd. Method and system for modifying an authenticated and/or encrypted message
US20160110261A1 (en) 2013-05-07 2016-04-21 Axcient, Inc. Cloud storage using merkle trees
WO2014201059A1 (en) 2013-06-10 2014-12-18 Certimix, Llc Secure storing and offline transfering of digitally transferable assets
KR102238681B1 (en) 2013-07-01 2021-04-12 삼성전자주식회사 Method of generating and verifying signature information and system thereof
US9767469B2 (en) 2013-07-16 2017-09-19 Fujitsu Limited Customer-centric energy usage data sharing
US20150046337A1 (en) * 2013-08-06 2015-02-12 Chin-hao Hu Offline virtual currency transaction
WO2015024603A1 (en) 2013-08-23 2015-02-26 Nec Europe Ltd. Method and system for authenticating a data stream
US9530010B2 (en) * 2013-11-07 2016-12-27 Fujitsu Limited Energy usage data management
US9338013B2 (en) 2013-12-30 2016-05-10 Palantir Technologies Inc. Verifiable redactable audit log
US9209971B2 (en) 2014-01-21 2015-12-08 Cofactor Computing Llc Method and system for shielding data in untrusted environments
US20160125403A1 (en) * 2014-04-28 2016-05-05 Chin-hao Hu Offline virtual currency transaction
US10340038B2 (en) * 2014-05-13 2019-07-02 Nant Holdings Ip, Llc Healthcare transaction validation via blockchain, systems and methods
US9704143B2 (en) 2014-05-16 2017-07-11 Goldman Sachs & Co. LLC Cryptographic currency for securities settlement
US9818092B2 (en) 2014-06-04 2017-11-14 Antti Pennanen System and method for executing financial transactions
US10089626B2 (en) * 2014-06-23 2018-10-02 The Toronto-Dominion Bank Systems and methods for authenticating user identities in networked computer systems
GB2513260B (en) 2014-06-27 2018-06-13 PQ Solutions Ltd System and method for quorum-based data recovery
US10356094B2 (en) 2014-06-30 2019-07-16 Vescel, Llc Uniqueness and auditing of a data resource through an immutable record of transactions in a hash history
US10454970B2 (en) 2014-06-30 2019-10-22 Vescel, Llc Authorization of access to a data resource in addition to specific actions to be performed on the data resource based on an authorized context enforced by a use policy
US9836908B2 (en) 2014-07-25 2017-12-05 Blockchain Technologies Corporation System and method for securely receiving and counting votes in an election
US20160098723A1 (en) * 2014-10-01 2016-04-07 The Filing Cabinet, LLC System and method for block-chain verification of goods
US9846642B2 (en) * 2014-10-21 2017-12-19 Samsung Electronics Co., Ltd. Efficient key collision handling
US20160162897A1 (en) * 2014-12-03 2016-06-09 The Filing Cabinet, LLC System and method for user authentication using crypto-currency transactions as access tokens
WO2016100920A1 (en) 2014-12-18 2016-06-23 Bittorrent, Inc. Distributed device management and directory resolution
US9667416B1 (en) 2014-12-18 2017-05-30 EMC IP Holding Company LLC Protecting master encryption keys in a distributed computing environment
US10230526B2 (en) 2014-12-31 2019-03-12 William Manning Out-of-band validation of domain name system records
US9413735B1 (en) 2015-01-20 2016-08-09 Ca, Inc. Managing distribution and retrieval of security key fragments among proxy storage devices
US9973341B2 (en) 2015-01-23 2018-05-15 Daniel Robert Ferrin Method and apparatus for the limitation of the mining of blocks on a block chain
US9436923B1 (en) 2015-02-26 2016-09-06 Skuchain, Inc. Tracking unitization occurring in a supply chain
US20160292396A1 (en) 2015-03-30 2016-10-06 Iperial, Inc. System and method for authenticating digital content
US10812274B2 (en) 2015-05-07 2020-10-20 Blockstream Corporation Transferring ledger assets between blockchains via pegged sidechains
US10067953B2 (en) * 2015-05-08 2018-09-04 International Business Machines Corporation Indexing a chameleon schema
CN106251144A (en) 2015-06-05 2016-12-21 地气股份有限公司 Electronic money management method and electronic money node apparatus
US11062303B2 (en) 2015-06-08 2021-07-13 Blockstream Corporation Cryptographically concealing amounts transacted on a ledger while preserving a network's ability to verify the transaction
US20170109735A1 (en) * 2015-07-14 2017-04-20 Fmr Llc Computationally Efficient Transfer Processing and Auditing Apparatuses, Methods and Systems
WO2017015212A1 (en) * 2015-07-17 2017-01-26 Jet.com, Inc. Merchant management system for adaptive pricing
US20170031676A1 (en) 2015-07-27 2017-02-02 Deja Vu Security, Llc Blockchain computer data distribution
US9871775B2 (en) 2015-08-10 2018-01-16 Cisco Technology, Inc. Group membership block chain
US10402792B2 (en) 2015-08-13 2019-09-03 The Toronto-Dominion Bank Systems and method for tracking enterprise events using hybrid public-private blockchain ledgers
CA3002034A1 (en) 2015-10-14 2017-04-20 Cambridge Blockchain, LLC Systems and methods for managing digital identities
US20170132615A1 (en) 2015-11-11 2017-05-11 Bank Of America Corporation Block chain alias for person-to-person payments
US10805393B2 (en) 2015-12-02 2020-10-13 Olea Networks, Inc. System and method for data management structure using auditable delta records in a distributed environment
US9948467B2 (en) 2015-12-21 2018-04-17 Mastercard International Incorporated Method and system for blockchain variant using digital signatures
US10713654B2 (en) 2016-01-21 2020-07-14 International Business Machines Corporation Enterprise blockchains and transactional systems
US9679276B1 (en) 2016-01-26 2017-06-13 Stampery, Inc. Systems and methods for using a block chain to certify the existence, integrity, and/or ownership of a file or communication
US10108812B2 (en) 2016-01-28 2018-10-23 Nasdaq, Inc. Systems and methods for securing and disseminating time sensitive information using a blockchain
AU2017216289A1 (en) 2016-02-04 2018-09-27 Nasdaq Technology Ab Systems and methods for storing and sharing transactional data using distributed computer systems
US11057198B2 (en) 2016-03-04 2021-07-06 Assured Enterprises, Inc. Utilization of a proxy technique in escrow encryption key usage
US10346406B2 (en) 2016-03-28 2019-07-09 International Business Machines Corporation Decentralized autonomous edge compute coordinated by smart contract on a blockchain
CN109219940B (en) 2016-03-31 2022-01-11 比特飞翔区块链株式会社 Private node and processing method in private node
SG11201809963XA (en) 2016-05-11 2018-12-28 Nasdaq Inc Application framework using blockchain-based asset ownership
US9967096B2 (en) 2016-05-23 2018-05-08 Accenture Global Solutions Limited Rewritable blockchain
US10614239B2 (en) 2016-09-30 2020-04-07 Amazon Technologies, Inc. Immutable cryptographically secured ledger-backed databases
US20180218003A1 (en) 2017-01-30 2018-08-02 General Electric Company Ephemeral blockchain data structure
WO2018165248A1 (en) 2017-03-07 2018-09-13 Mastercard International Incorporated Method and system for recording point to point transaction processing

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5608178A (en) * 1993-12-29 1997-03-04 Yamaha Corporation Method of storing and editing performance data in an automatic performance device
CN105488665A (en) * 2015-11-25 2016-04-13 布比（北京）网络技术有限公司 Decentralized transaction method
CN105404701A (en) * 2015-12-31 2016-03-16 浙江图讯科技股份有限公司 Peer-to-peer network-based heterogeneous database synchronization method
CN105592098A (en) * 2016-01-16 2016-05-18 杭州复杂美科技有限公司 Management method of vote and CA certificate of block chain

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Bitcoin Transaction Malleability and MtGox;Christian Decker等;Network and parallel Computing;全文 *

Also Published As

Publication number Publication date
US20180278596A1 (en) 2018-09-27
CN109417478B (en) 2021-03-02
CN109417479A (en) 2019-03-01
EP3443710A1 (en) 2019-02-20
EP3443710B1 (en) 2020-02-05
EP3443707A1 (en) 2019-02-20
US10623387B2 (en) 2020-04-14
US20190158475A1 (en) 2019-05-23
US20200228512A1 (en) 2020-07-16
US9959065B2 (en) 2018-05-01
CN109417479B (en) 2021-07-02
AU2017269734A1 (en) 2018-11-22
US20170338957A1 (en) 2017-11-23
US20170338947A1 (en) 2017-11-23
WO2017202757A1 (en) 2017-11-30
US10110576B2 (en) 2018-10-23
EP3633916A1 (en) 2020-04-08
EP3633916B1 (en) 2021-01-06
US20180254887A1 (en) 2018-09-06
EP3641220A8 (en) 2020-06-17
SG11201809660PA (en) 2018-12-28
US10356066B2 (en) 2019-07-16
US20170374049A1 (en) 2017-12-28
US10305875B1 (en) 2019-05-28
AU2017269736A1 (en) 2018-11-22
EP3443707B1 (en) 2020-02-12
EP3443708A1 (en) 2019-02-20
US20180048469A1 (en) 2018-02-15
EP3443709A1 (en) 2019-02-20
WO2017202756A1 (en) 2017-11-30
EP3641220A1 (en) 2020-04-22
US9967096B2 (en) 2018-05-08
US11552935B2 (en) 2023-01-10
EP3443708B1 (en) 2020-02-05
US10348707B2 (en) 2019-07-09
CN112968764A (en) 2021-06-15
CN109417478A (en) 2019-03-01
AU2017269736B2 (en) 2019-05-30
US20230132211A1 (en) 2023-04-27
AU2017269734B2 (en) 2019-05-30
US20180032273A1 (en) 2018-02-01
SG11201809661SA (en) 2018-12-28
US9774578B1 (en) 2017-09-26
WO2017202759A1 (en) 2017-11-30
WO2017202758A1 (en) 2017-11-30
US9967088B2 (en) 2018-05-08
EP3443709B1 (en) 2020-02-05
US9785369B1 (en) 2017-10-10
EP3641220B1 (en) 2021-01-20

Similar Documents

Publication Publication Date Title
CN112968764B (en) Multilink cipher logic block chain
CN109583885B (en) Round control of rewritable block chains
CN109428892B (en) Multi-stage rewritable block chain

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant