US20190207748A1 - Blockchain storage device - Google Patents
Blockchain storage device Download PDFInfo
- Publication number
- US20190207748A1 US20190207748A1 US15/858,214 US201715858214A US2019207748A1 US 20190207748 A1 US20190207748 A1 US 20190207748A1 US 201715858214 A US201715858214 A US 201715858214A US 2019207748 A1 US2019207748 A1 US 2019207748A1
- Authority
- US
- United States
- Prior art keywords
- blockchain
- storage
- storage device
- signed
- data structures
- 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.)
- Abandoned
Links
Images
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/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/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
- H04L9/0897—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage involving additional devices, e.g. trusted platform module [TPM], smartcard or USB
-
- 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/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/3239—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 non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
-
- 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/3247—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 involving digital signatures
-
- 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
Definitions
- a blockchain is a set of transaction blocks that are linked together using hashing methods.
- a block if a blockchain may include one or more transactions, a hash of a previous block, a time stamp, etc.
- a blockchain may be public or private, distributed or non-distributed.
- a method includes receiving an object at a storage device from a host device.
- the object is cryptographically signed by the host device.
- the storage device stores one or more blockchain data structures generated and managed by the storage device.
- the method further includes determining whether the object satisfies a blockchain storage condition.
- the blockchain storage condition is based at least on a type of the object.
- the method further includes cryptographically signing the object using a cryptographic key associated with the storage device and storing the signed object in the one or more blockchain data structures responsive to determining that the object satisfies a blockchain storage condition.
- FIG. 1 illustrates an example block diagram of a blockchain storage device.
- FIG. 2 illustrates an example data flow diagram for a blockchain storage device system.
- FIG. 3 illustrates another example data flow diagram for a blockchain storage device system.
- FIG. 4 illustrates another example data flow diagram for a blockchain storage device system.
- FIG. 6 illustrates alternative example operations for storing an object to a blockchain stored in a blockchain storage device.
- Distributed ledgers utilize cryptographic techniques to provide a secure, verifiable record of transactions or data streams.
- Blockchain is one example of such distributed ledgers.
- the transactions may indicate storage of data or objects or anything of value.
- the blockchains may be managed by one or more computing devices and may be public or private, distributed or non-distributed.
- a blockchain storage device includes a storage media storing one or more blockchain data structures. The storage device determines whether objects received from a host device satisfy a blockchain storage condition and stores the objects to one or more blockchain data structures responsive to determining that the objects satisfy the blockchain storage condition.
- the storage device includes a cryptography manager storage a private key used to sign objects/transactions stored to a blockchain data structure. Because objects or transactions are signed by a cryptographic key, the blockchain data structures are externally verifiable while being internally managed.
- the storage device is configured to generate, based on instructions from a host device, a blockchain data structure and store objects/transactions to the blockchain data structure. Furthermore, the storage device may transmit signed objects/transactions to other devices that are authorized to support the blockchain data structure.
- Each of the storage devices may be considered “nodes” that support the distributed blockchain data structure. Each of the nodes work together to verify the blockchain and append transactions/objects to the blockchain.
- a blockchain may be considered an object and may be referenced by a name, for example.
- different transactions stored to a blockchain data structure may be an object and referenced by a name.
- the blockchain storage devices described herein may be a self-encrypting drive (SED), a kinetic drive, object storage drives, etc.
- FIG. 1 illustrates an example block diagram 100 of a blockchain storage device 110 .
- the block diagram includes a host device 102 .
- the storage device 110 is illustrated as being separate from the host device 102 , but it should be understood that storage device 110 may be implemented in the host device 102 .
- the host device 102 may be a computing device such as a laptop, desktop, server system, etc.
- the storage device 110 is configured to receive and store objects to a storage media 116 .
- the storage media 116 may comprise various volatile or non-volatile memory storage types including magnetic or optical recording discs, NAND flash memory, rewriteable semiconductor memory (e.g., STRAM, MRAM, RRAM, PCREAM, XRAM, etc.), hybrid memory structures, (e.g., disc and NAND flash), etc.
- NAND flash memory e.g., NAND flash memory
- rewriteable semiconductor memory e.g., STRAM, MRAM, RRAM, PCREAM, XRAM, etc.
- hybrid memory structures e.g., disc and NAND flash
- the host device 102 transmits objects to the storage device 110 for storage in the storage media 116 , and the host device 102 may retrieve various objects stored on the storage device 110 .
- the host accesses and saves objects to the storage device 110 using object names, for example.
- Various objects transmitted to the storage device 110 may be included in payloads (e.g., payloads 122 ) that are transmitted to the storage device 110 .
- a payload may include the object along with metadata associated with the object.
- a payload 104 including an object 108 and metadata 106 is transmitted to the storage device 110 .
- a storage controller 114 of the storage device manages storage of various objects to the storage media 116 .
- Objects may be stored in (e.g., written to) one or more blockchains created and managed by the storage device 110 .
- Different blockchains may be utilized to store different object types.
- a first blockchain may be utilized to store access logs of the storage device
- second blockchain may be utilized to store documents, document hashes, customer objects including customer data, etc.
- other blockchains may be utilized to store various other types of objects including image files, transactions, media files, transactions, etc.
- the blockchains are utilized to store objects so that the storage of objects is externally verifiable (e.g., based on cryptographic proofs).
- the blockchain generated and maintained within the storage device 110 .
- the blockchains are used to guarantee the integrity and maintain a complete history of objects (e.g., transactions) written to the storage device 110 .
- objects e.g., transactions
- the term blockchain includes data structures that may be referred to as ledgers, distributed ledgers, distributed ledger technology, directed acyclic graphs where nodes are cryptographically linked, etc. These data structures include a set (e.g., one or more) of transaction blocks that are linked together with hashing methods.
- a user may open a blockchain session to the storage device.
- the user can create a new blockchain, add a new transaction to an existing blockchain, verify a blockchain, read a blockchain, lock a blockchain etc.
- Such functions may be controlled by access rights.
- a user has utilized the host device 102 to open a blockchain session and has transmitted a payload 104 to the storage device 110 .
- the payload 104 includes the object 108 and metadata 106 associated with the object 108 .
- the object 108 may be cryptographically signed by a signing key (e.g., a signing key) of the host device 102 or the user of the host device 102 .
- a blockchain decision manager 112 of the storage device 110 analyzes the object 108 and/or the metadata 106 to determine whether the object satisfies a blockchain storage condition. Such analysis may include determining the type of object (e.g., document or image), determining a level of importance, determining access rights, validating a signature, etc. Based on the determination, the blockchain decision manager 112 may determine that the object 108 should be stored in one or more blockchain data structures stored in the storage media 116 . The object and the determination is transmitted to the storage controller 114 which stores the object to the requisite blockchain.
- the storage controller 114 may store the object 108 to a blockchain A 124 or a blockchain B 126 , or both, for example.
- the blockchain storage condition may also be determined based on the object type. For example, if the object is a document, a first blockchain storage condition may be selected, and if the object is one or more access logs, then a second blockchain storage condition may be selected.
- the blockchain storage condition may further depend on the metadata included in the payload. Such metadata may indicate a level of importance of the object, a level of redundancy, a pin, etc.
- a cryptography manager 118 of the storage device may sign the object to generate an object transaction.
- the cryptography manager 118 may be implemented as a cryptographic/trusted chip or secure platform firmware.
- the cryptography manager 118 may include a root of trust used to generate and manage cryptographic keys such as cryptographic key pairs (e.g., public and private keys). These keys may be generated using RSA methods, elliptic-curve cryptography methods, or another key generation method.
- a generated private key may be securely stored in the cryptography manager 118 .
- the public key associated with a private key may be transmitted to the host device 102 and other network devices using certificates, for example.
- the cryptography manager 118 may utilize or include a certificate authority based on the root of trust for key generation and distribution.
- the object (or a representation of the object, such as a hash output) may be signed by the private key.
- One or more objects/transactions may be stored in a block (e.g., a block N 128 of the blockchain A 124 ) in a blockchain.
- a block may include a nonce, a hash of a previous block, a timestamp, one or more objects, etc.
- the hash of the previous block is used to link blocks of objects/transactions together in a “chained” data structure.
- the timestamp indicates the data and time of the block creation.
- the storage of the object may be verified using the public key used associated to the private key. Furthermore, because an object may be originally signed by a key associated with the host device 102 or the user of the host device 102 and the storage device 110 that generates the blockchain transaction, a complete forensic history of objects may be produced.
- the blockchain data structures 124 and 126 managed by the storage device 110 may be distributed or non-distributed.
- a distributed blockchain data structure is stored/copied across various other storage devices 110 .
- the storage device 110 may be networked to other storage devices that store copies of the blockchain.
- the storage device 110 may transmit the signed object to other storage devices.
- the other storage devices verify the object/transaction using the public key and store the object/transaction to their copy of the blockchain after verification.
- the storage device 110 may receive signed transactions/objects from other storage devices.
- the storage device 110 verifies the received transactions using a public key associated with a private key securely stored on the other storage device.
- the storage device 110 stores the signed object to the requisite blockchain stored in the storage media 116 .
- An object stored to a blockchain of the storage device 110 may not be completely verified until a requisite number of verifications are performed by other networked storage devices.
- the verification techniques and threshold may be dependent on the blockchain.
- the blockchain A 124 may require a first threshold number of verifications
- the blockchain B 126 may require a second threshold number of verifications.
- the structure of the blockchains may vary between different blockchains.
- the blockchain decision manager 112 and the storage controller 114 are configured to manage the different blockchain types. In effect, each of the blockchain types are managed by blockchain nodes, which may comprise a combination of the blockchain decision manager 112 , the storage controller 114 , and blockchain parameters, which are enforced by the blockchain decision manager 112 and the storage controller 114 .
- a user using the host device 102 may transmit an blockchain instruction to the storage device 110 .
- the instruction may include parameters indicating a type of blockchain (e.g., types of objects and or blockchain structure), access rights, and indication of whether the blockchain will be distributed, etc.
- the user may have a pin and indicate that the only users that have access to that pin can edit the created blockchain.
- the user can indicate a set of pins that have access rights. Varying levels of access may be indicated that permit reading from and/or writing to the blockchain, locking the blockchain, etc.
- the instructions may include an identification of other parties/devices that will support the blockchain.
- the host device 102 may transmit an object to the storage device 110 for storage in one or more blockchains.
- the object may be transmitted in a payload which may include metadata.
- the metadata may include one or more pins.
- the blockchain decision manager 112 analyzes the received payload and determines whether the received pins have write access to the generated blockchain (e.g., using the stored parameters). If the pin has access rights, the blockchain decision manager 112 selects the blockchain and transmits the information to the storage controller 114 .
- the storage controller 114 stores the object to the generated blockchain using the methods described herein.
- the host device 102 may also transmit a read request that identifies a blockchain or an object in the blockchain.
- the request may be included in a payload which includes metadata such as a pin associated with a user.
- the blockchain decision manager 112 determines whether the request has access rights based on the pin. If the blockchain decision manager 112 determines that the request has access rights, then the blockchain decision manager 112 instructs the storage controller 114 to retrieve the identified object or blockchain. The requested information is then transmitted to the host device 102 .
- a read request from a non-contributor is recorded as a transaction to a blockchain data structure.
- a non-contributor e.g., a host/user that does not have write access
- the blockchain decision manager 112 determines that the read request has read access (e.g., based on pin or cryptographically signed request) and records a transaction to one or more blockchain data structures.
- the transaction includes the user/host device that requested access. Accordingly, a complete forensic history is recorded for blockchain transactions.
- a blockchain data structure may be dedicated to recording read/write request transactions or such transactions may be recorded to the blockchain data structure being accessed.
- the cryptography manager 118 may store an index of pins associated with cryptographic keys or key pairs. Accordingly, when a user transmits an object to the storage device 110 with an identification of a pin, the cryptography manager 118 may retrieve the key associated with the pin to sign the object before storage of the object to the storage device. Accordingly, the object is verifiable as being transmitted by a pin and signed by a key generated by the storage device 110 .
- Blockchains may be used to store different objects/transactions including, for example, images, documents, document changes, access logs, transactions involving different type of objects, etc.
- Each blockchain may be identified by using a blockchain ID, which may be used to open a blockchain session, edit a blockchain data structure, and close a blockchain session.
- a blockchain is utilized to store document records.
- the document blockchain can be used to determine integrity of a document during the document history. For example, a first draft of a document is stored to the storage device 110 , and a document blockchain is utilized to store the history of the document.
- the cryptography manager 118 performs a cryptographic hash (e.g., SHA-1, SHA-2, SHA-3) of the documents and stores the hash output in the document blockchain as a transaction.
- the document itself may be stored to another location in the storage media 116 .
- the blockchain decision manager 112 determines the amount of change to the document relative to the previously stored document.
- the blockchain decision manager 112 may retrieve the previously stored copy of the document of the storage media 116 and compare it to the new version of the documents. If the new document has changed (e.g., delta) above a threshold, then a new cryptographic hash is performed by the cryptography manager 118 , and the new hash output is stored to the document blockchain.
- the new hash may be linked to the previous hash using various techniques.
- One blockchain may be utilized to store the history of a single document, or one blockchain may be utilized to store hash functions of several documents.
- the blockchain of hash outputs of documents may be utilized to verify integrity of a document at a certain time. It should be understood that the term “document” is not limited to text documents and may include contracts, programs, code, or other types of media.
- an object/transaction is cryptographically signed by the host device 102 before it is transmitted to the storage device 110 .
- the blockchain decision manager 112 may determine whether the object is validly signed using a public key associated with the host device 102 .
- the cryptography manager 118 may store an index of public keys that have read and/or write access to one or more of the blockchain data structures 124 and 126 . Accordingly, the blockchain decision manager determines, using the index, whether the object is validly signed by a private key.
- the blockchain decision manager 112 may select one of the blockchain data structures 124 and 126 based on the cryptographic signature in addition to any metadata included in the payload.
- the decision manager 112 may determine whether the signature is associated with read access. If so, then an access transaction may be generated and stored to one or more blockchain data structures. If the read request does not have access rights, then a repudiation transaction may be recorded to one or more blockchain data structures. Accordingly, the complete forensic history of blockchain access is stored.
- users or parties are incentivized to run a blockchain node (e.g., the storage device 110 ) for access to verified data objects.
- a blockchain node e.g., the storage device 110
- the more parties running blockchain nodes means that the data is more secure and completely verified.
- some parties, such as customers may pay to access the secure and verified data.
- customers may be “read-only” users because they can only read data but not add data (e.g., append) to the blockchains.
- Other incentive structures are contemplated.
- a miner 224 is another example of a blockchain storage device.
- the miner 224 does not include a blockchain decision manager. Rather, the miner 224 receives transactions from other devices/users where the other devices/users have already validated the transaction.
- the miner 224 receives transactions and stores them to respective blockchains.
- a blockchain storage device system may include more devices than illustrated in FIG. 2 .
- different devices may include different blockchains.
- an object C blockchain 222 is a non-distributed blockchain and is managed by the object miner A 212 .
- an object D blockchain 244 is a non-distributed blockchain which is managed by the object miner B 234 . Only user C 206 may have access to the object D blockchain 244 , for example.
- different blockchains on a device may be public or private.
- the user A 202 signs an object (e.g., an object type A 208 ) using the private key associated with the user A 202 .
- the signed object type A 208 is transmitted to the object miner A 212 .
- the signed object type A 208 may be transmitted to the object miner A 212 because the object miner A 212 is the local storage device to the user A 202 .
- the signed object type A 208 may be transmitted as a part of a payload.
- the signed object type A 208 is stored in the object storage 216 , and he decision manager 214 analyzes the signed object type A 208 to determine whether the signed object type A 208 satisfies a blockchain storage condition.
- the object A transaction 210 is stored in an object A blockchain 218 , which is distributed blockchain. Accordingly, the object A blockchain 218 is synced across the object miner A 212 , the miner 224 , and the object miner B 234 . To synchronize the blockchains, the object miner A 212 broadcasts the object A transaction 210 to the miner 224 and the object miner B 234 . The miner 224 and the object miner B 234 check for valid signatures by the transaction originator (e.g., the user A 202 ) and the original miner (e.g., the object miner A 212 ) and stores the object A transaction 210 to the respective blockchains responsive to the validation of the signatures.
- the transaction originator e.g., the user A 202
- the original miner e.g., the object miner A 212
- an object miner may be considered the authenticator of a valid blockchain transactions, and a miner may be considered a device that receives an authorized transaction.
- the signed object type A 208 is also transmitted to the miner 223 and the object miner B 234 for storage in the object storage 226 and the object storage 238 , respectively. Accordingly, the object type A 208 may be retrieved from any of the devices and validated by any of the devices using the object A blockchain 218 .
- the object type A 208 does not satisfy a blockchain storage condition.
- the signed object type A 208 may be stored in the object storage 216 .
- the object type A 208 may not satisfy the blockchain storage condition based on an invalid signature and/or invalid access rights to a blockchain.
- the object type A 208 does not satisfy the blockchain storage condition because the object miner A 212 does not include a blockchain for storing objects of type A.
- an object is not signed before being transmitted to an object miner (e.g., a storage device).
- the object may not be authorized to be stored in a blockchain.
- an unsigned object does not satisfy a blockchain storage condition in some example implementations.
- the unsigned object may be stored in the object storage 216 , for example.
- FIG. 3 illustrates another example data flow diagram 300 for a blockchain storage device system.
- the data flow diagram 300 includes user A 302 , user B 304 , and user C 306 .
- Such users may utilize one or more different host computing devices to store objects to one or more storage devices that may/may not store objects to different blockchains based one or more blockchain storage conditions.
- Each of the user A 302 , the user B 304 , and or the user C 306 may be associated with a key pair (e.g., RSA or elliptic curve) that includes a public and a private key.
- the private keys may be used to cryptographically sign objects sent to the one or more blockchain storage devices. These cryptographic signatures may be utilized to verify the origin of the signed objects.
- the user A 402 generates, signs, and transmits an object B transaction 410 .
- the object B transaction 410 may be referred to as a user generated blockchain transaction because it is generated by the user A 402 rather than one of the object miners.
- the object B transaction 410 forces the devices supporting object be to store an object to the object B blockchain. Accordingly, each of the devices respond as simple miners (rather than object miners) and as if the transaction was generated by an object miner.
- the object miner A 412 receives the object B transaction 410 and stores the signed object B transaction to the object B blockchain 420 .
- the decision manager 414 does not make any decision with regard to any blockchain storage condition.
- a selecting operation 506 selects one or more blockchain data structures based at least on the type of the object. For example, if it is determined that the type of the object is an access log, the selecting operation 506 selects the access log data structure. The selection may be further based on a level of access (e.g., based on a pin) or level of redundancy indication. For example, if the high level of redundancy is indicated, then a distributed blockchain (of the object type) may be selected. Similarly, if a medium level of redundancy is indicated, then a non-distributed blockchain data structure may be selected. If a low level of redundancy is indicated, then the storage condition may not be satisfied.
- a level of access e.g., based on a pin
- a signing operation 508 cryptographically signs the object using a private key associated with the storage device (e.g., associated with a public key of the storage device).
- a transmitting operation 510 transmits the signed object to connected/networked devices. The transmitting operation 510 may occur when the blockchain is distributed.
- a storing operation 512 stores at least a representation of the object to the selected one or more blockchain data structures. The storing operation 512 may coincide with the transaction being “mined” (e.g., verified) by other connected/networked storage devices.
- a storing operation 514 stores the object tin the storage media of the storage device. If the object does not satisfy the blockchain storage condition, then a storing operation 514 stores the object in a storage media of the storage device without storing the object in a blockchain data structure.
- FIG. 6 illustrates alternative example operations 600 for storing an object to a blockchain stored in a blockchain storage device. Specifically, FIG. 6 illustrates the operations 600 when the object is a document.
- a receiving operation 602 receives a payload from a host device at a storage device. The received payload includes a document object, which may be signed by a signing key of the user of the host device.
- a comparing operation 604 compares the received document to a previous version of the document.
- a determining operation 606 determines whether the difference between the documents satisfies a blockchain storage condition. For example, the blockchain condition may correspond to a threshold percentage of the document being changed. If, for example, 15% of the document has been changed, then the blockchain storage condition is satisfied. If the blockchain storage condition is satisfied, then a selection operation 608 selects one or more blockchain data structures based on the type of the object (e.g., document). Accordingly, a blockchain data structure for storing documents or representations of documents may be selected.
- the type of the object e
- a hashing operation 610 hashes the document to produce a hash output.
- a signing operation 612 cryptographically signs the hash output using a private key associated with the storage device to generate an object transaction.
- a transmitting operation 614 transmits the object transaction to connected devices.
- a storing operation 616 stores the object transaction to one or more blockchain data structures.
- Another storing operation 618 stores the documents as a document object in the storage media of the storage device. If it is determined that the differences between the documents do not satisfy the blockchain storage condition, then the storing operation 618 stores the document in the storage media of the storage device. Accordingly, if another version of the documents is transmitted to the storage device, then the previously stored version may be used for comparison.
- each document transmitted to the storage device is hashed and stored to a document blockchain such that hash outputs may be used to establish document histories.
- the blockchain storage condition may be based on an indication of importance included with the payload including the document. If the document is deemed important, then the blockchain storage condition is satisfied and the document is hashed to produce the hash output, which is stored to one or more blockchain data structures.
- a selecting operation 708 selects one or more blockchain data structures. The selection may be based on the level of access, for example.
- a signing operation 710 cryptographically signs the access logs using a private key associated with the storage device to generate an object transaction.
- a transmitting operation 712 transmits the object transaction to connected devices.
- a storing operation 714 stores the object transaction to the selected one or more blockchain data structures.
- a storing operation 716 stores the access log objects in a storage media of the storage device. If the blockchain storage condition is not satisfied, a storing operation 716 stores the access logs in the storage media of the storage device.
- the I/O section 804 may be connected to one or more user-interface devices (e.g., a keyboard, a touch-screen display unit 818 , etc.) or a storage unit 812 .
- user-interface devices e.g., a keyboard, a touch-screen display unit 818 , etc.
- Storage unit 812 e.g., a hard disk drive, a solid state drive, etc.
- Computer program products containing mechanisms to effectuate the systems and methods in accordance with the described technology may reside in the memory section 808 or on the storage unit 812 of such a system 800 .
- a communication interface 824 is capable of connecting the processing system 800 to an enterprise network via the network link 814 , through which the computer system can receive instructions and data embodied in a carrier wave.
- the processing system 800 When used in a local area networking (LAN) environment, the processing system 800 is connected (by wired connection or wirelessly) to a local network through the communication interface 824 , which is one type of communications device.
- the processing system 800 When used in a wide-area-networking (WAN) environment, the processing system 800 typically includes a modem, a network adapter, or any other type of communications device for establishing communications over the wide area network.
- program modules depicted relative to the processing system 800 or portions thereof may be stored in a remote memory storage device. It is appreciated that the network connections shown are examples of communications devices for and other means of establishing a communications link between the computers may be used.
- a storage controller, a blockchain decision manager, a cryptography manager, and other modules may be embodied by instructions stored in memory 808 and/or the storage unit 812 and executed by the processor 802 .
- local computing systems, remote data sources and/or services, and other associated logic represent firmware, hardware, and/or software, which may be configured to assist in supporting the blockchain storage device.
- a blockchain storage may be implemented using a general-purpose computer and specialized software (such as a server executing service software), a special purpose computing system and specialized software (such as a mobile device or network appliance executing service software), or other computing configurations.
- keys, device information, identification, configurations, etc. may be stored in the memory 808 and/or the storage unit 812 and executed by the processor 802 .
- the processing system 800 may be implemented in a device, such as a user device, storage device, IoT device, a desktop, laptop, computing device.
- the processing system 800 may be a storage device that executes in a user device or external to a user device.
- the embodiments of the technology described herein can be implemented as logical steps in one or more computer systems.
- the logical operations of the present technology can be implemented (1) as a sequence of processor-implemented steps executing in one or more computer systems and/or (2) as interconnected machine or circuit modules within one or more computer systems. Implementation is a matter of choice, dependent on the performance requirements of the computer system implementing the technology. Accordingly, the logical operations of the technology described herein are referred to variously as operations, steps, objects, or modules. Furthermore, it should be understood that logical operations may be performed in any order, unless explicitly claimed otherwise or unless a specific order is inherently necessitated by the claim language.
- Data storage and/or memory may be embodied by various types of processor-readable storage media, such as hard disc media, a storage array containing multiple storage devices, optical media, solid-state drive technology, ROM, RAM, and other technology.
- the operations may be implemented processor-executable instructions in firmware, software, hard-wired circuitry, gate array technology and other technologies, whether executed or assisted by a microprocessor, a microprocessor core, a microcontroller, special purpose circuitry, or other processing technologies.
- a write controller, a storage controller, data write circuitry, data read and recovery circuitry, a sorting module, and other functional modules of a data storage system may include or work in concert with a processor for processing processor-readable instructions for performing a system-implemented process.
- the term “memory” means a tangible data storage device, including non-volatile memories (such as flash memory and the like) and volatile memories (such as dynamic random-access memory and the like).
- the computer instructions either permanently or temporarily reside in the memory, along with other information such as data, virtual mappings, operating systems, applications, and the like that are accessed by a computer processor to perform the desired functionality.
- the term “memory” expressly does not include a transitory medium such as a carrier signal, but the computer instructions can be transferred to the memory wirelessly.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computing Systems (AREA)
- Theoretical Computer Science (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
Description
- A blockchain is a set of transaction blocks that are linked together using hashing methods. A block if a blockchain may include one or more transactions, a hash of a previous block, a time stamp, etc. A blockchain may be public or private, distributed or non-distributed.
- This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Other features, details, utilities, and advantages of the claimed subject matter will be apparent from the following, more particular written Detailed Description of various implementations as further illustrated in the accompanying drawings and defined in the appended claims.
- In at least one implementation, a method includes receiving an object at a storage device from a host device. The object is cryptographically signed by the host device. The storage device stores one or more blockchain data structures generated and managed by the storage device. The method further includes determining whether the object satisfies a blockchain storage condition. The blockchain storage condition is based at least on a type of the object. The method further includes cryptographically signing the object using a cryptographic key associated with the storage device and storing the signed object in the one or more blockchain data structures responsive to determining that the object satisfies a blockchain storage condition.
- These and various other features and advantages will be apparent from a reading of the following Detailed Description.
-
FIG. 1 illustrates an example block diagram of a blockchain storage device. -
FIG. 2 illustrates an example data flow diagram for a blockchain storage device system. -
FIG. 3 illustrates another example data flow diagram for a blockchain storage device system. -
FIG. 4 illustrates another example data flow diagram for a blockchain storage device system. -
FIG. 5 illustrates example operations for storing an object to a blockchain stored in a blockchain storage device. -
FIG. 6 illustrates alternative example operations for storing an object to a blockchain stored in a blockchain storage device. -
FIG. 7 illustrates alternative example operations for storing an object to a blockchain stored in a blockchain storage device. -
FIG. 8 illustrates an example processing system that may be useful in implementing the described technology. - Distributed ledgers utilize cryptographic techniques to provide a secure, verifiable record of transactions or data streams. Blockchain is one example of such distributed ledgers. The transactions may indicate storage of data or objects or anything of value. The blockchains may be managed by one or more computing devices and may be public or private, distributed or non-distributed. A blockchain storage device includes a storage media storing one or more blockchain data structures. The storage device determines whether objects received from a host device satisfy a blockchain storage condition and stores the objects to one or more blockchain data structures responsive to determining that the objects satisfy the blockchain storage condition. The storage device includes a cryptography manager storage a private key used to sign objects/transactions stored to a blockchain data structure. Because objects or transactions are signed by a cryptographic key, the blockchain data structures are externally verifiable while being internally managed.
- The storage device is configured to generate, based on instructions from a host device, a blockchain data structure and store objects/transactions to the blockchain data structure. Furthermore, the storage device may transmit signed objects/transactions to other devices that are authorized to support the blockchain data structure. Each of the storage devices may be considered “nodes” that support the distributed blockchain data structure. Each of the nodes work together to verify the blockchain and append transactions/objects to the blockchain. A blockchain may be considered an object and may be referenced by a name, for example. Furthermore, different transactions stored to a blockchain data structure may be an object and referenced by a name. The blockchain storage devices described herein may be a self-encrypting drive (SED), a kinetic drive, object storage drives, etc.
-
FIG. 1 illustrates an example block diagram 100 of ablockchain storage device 110. The block diagram includes ahost device 102. Thestorage device 110 is illustrated as being separate from thehost device 102, but it should be understood thatstorage device 110 may be implemented in thehost device 102. Thehost device 102 may be a computing device such as a laptop, desktop, server system, etc. Thestorage device 110 is configured to receive and store objects to astorage media 116. Thestorage media 116 may comprise various volatile or non-volatile memory storage types including magnetic or optical recording discs, NAND flash memory, rewriteable semiconductor memory (e.g., STRAM, MRAM, RRAM, PCREAM, XRAM, etc.), hybrid memory structures, (e.g., disc and NAND flash), etc. - The
host device 102 transmits objects to thestorage device 110 for storage in thestorage media 116, and thehost device 102 may retrieve various objects stored on thestorage device 110. The host accesses and saves objects to thestorage device 110 using object names, for example. Various objects transmitted to thestorage device 110 may be included in payloads (e.g., payloads 122) that are transmitted to thestorage device 110. A payload may include the object along with metadata associated with the object. For example, apayload 104 including anobject 108 andmetadata 106 is transmitted to thestorage device 110. - A
storage controller 114 of the storage device manages storage of various objects to thestorage media 116. Objects may be stored in (e.g., written to) one or more blockchains created and managed by thestorage device 110. Different blockchains may be utilized to store different object types. For example, a first blockchain may be utilized to store access logs of the storage device, and second blockchain may be utilized to store documents, document hashes, customer objects including customer data, etc. It is contemplated that other blockchains may be utilized to store various other types of objects including image files, transactions, media files, transactions, etc. The blockchains are utilized to store objects so that the storage of objects is externally verifiable (e.g., based on cryptographic proofs). The blockchain generated and maintained within thestorage device 110. The blockchains are used to guarantee the integrity and maintain a complete history of objects (e.g., transactions) written to thestorage device 110. It should be understood that the term blockchain includes data structures that may be referred to as ledgers, distributed ledgers, distributed ledger technology, directed acyclic graphs where nodes are cryptographically linked, etc. These data structures include a set (e.g., one or more) of transaction blocks that are linked together with hashing methods. - To utilize the
storage device 110, a user (e.g., using the host device 102) may open a blockchain session to the storage device. In this session, the user can create a new blockchain, add a new transaction to an existing blockchain, verify a blockchain, read a blockchain, lock a blockchain etc. Such functions may be controlled by access rights. InFIG. 1 , a user has utilized thehost device 102 to open a blockchain session and has transmitted apayload 104 to thestorage device 110. Thepayload 104 includes theobject 108 andmetadata 106 associated with theobject 108. Theobject 108 may be cryptographically signed by a signing key (e.g., a signing key) of thehost device 102 or the user of thehost device 102. Theobject 108 may include data such as a document, an image (e.g., image data), access logs, financial transactions, a customer object including customer data, etc. Themetadata 106 may include flag or field that indicates a level of importance of the object, an indication of a blockchain managed by thestorage device 110, a level of access by a user of the host device 102 (e.g., a pin number indicating a level of access), a level of redundancy, etc. After the user opens a blockchain session and performs some blockchain operations (e.g., create new blockchain, write to blockchain, read from blockchain), the user closes the session. - When the
object 108 is received by thestorage device 110, the object is stored in anobject storage 130 of thestorage media 116. Furthermore, ablockchain decision manager 112 of thestorage device 110 analyzes theobject 108 and/or themetadata 106 to determine whether the object satisfies a blockchain storage condition. Such analysis may include determining the type of object (e.g., document or image), determining a level of importance, determining access rights, validating a signature, etc. Based on the determination, theblockchain decision manager 112 may determine that theobject 108 should be stored in one or more blockchain data structures stored in thestorage media 116. The object and the determination is transmitted to thestorage controller 114 which stores the object to the requisite blockchain. For example, depending on the determination, thestorage controller 114 may store theobject 108 to ablockchain A 124 or ablockchain B 126, or both, for example. The blockchain storage condition may also be determined based on the object type. For example, if the object is a document, a first blockchain storage condition may be selected, and if the object is one or more access logs, then a second blockchain storage condition may be selected. The blockchain storage condition may further depend on the metadata included in the payload. Such metadata may indicate a level of importance of the object, a level of redundancy, a pin, etc. - Before an object is stored to a blockchain, a
cryptography manager 118 of the storage device may sign the object to generate an object transaction. Thecryptography manager 118 may be implemented as a cryptographic/trusted chip or secure platform firmware. Thecryptography manager 118 may include a root of trust used to generate and manage cryptographic keys such as cryptographic key pairs (e.g., public and private keys). These keys may be generated using RSA methods, elliptic-curve cryptography methods, or another key generation method. A generated private key may be securely stored in thecryptography manager 118. The public key associated with a private key may be transmitted to thehost device 102 and other network devices using certificates, for example. Accordingly, thecryptography manager 118 may utilize or include a certificate authority based on the root of trust for key generation and distribution. Before an object is stored to a blockchain, the object (or a representation of the object, such as a hash output) may be signed by the private key. One or more objects/transactions may be stored in a block (e.g., ablock N 128 of the blockchain A 124) in a blockchain. A block may include a nonce, a hash of a previous block, a timestamp, one or more objects, etc. The hash of the previous block is used to link blocks of objects/transactions together in a “chained” data structure. The timestamp indicates the data and time of the block creation. Once the object is stored to a blockchain data structure of thestorage device 110, the storage of the object may be verified using the public key used associated to the private key. Furthermore, because an object may be originally signed by a key associated with thehost device 102 or the user of thehost device 102 and thestorage device 110 that generates the blockchain transaction, a complete forensic history of objects may be produced. - The
blockchain data structures storage device 110 may be distributed or non-distributed. A distributed blockchain data structure is stored/copied across variousother storage devices 110. Accordingly, thestorage device 110 may be networked to other storage devices that store copies of the blockchain. As such, when thestorage device 110 signs a transaction/object and stores it to a blockchain stored in thestorage media 116, thestorage device 110 may transmit the signed object to other storage devices. The other storage devices verify the object/transaction using the public key and store the object/transaction to their copy of the blockchain after verification. Similarly, thestorage device 110 may receive signed transactions/objects from other storage devices. Thestorage device 110 verifies the received transactions using a public key associated with a private key securely stored on the other storage device. If the object/transaction is verified, thestorage device 110 stores the signed object to the requisite blockchain stored in thestorage media 116. An object stored to a blockchain of thestorage device 110 may not be completely verified until a requisite number of verifications are performed by other networked storage devices. The verification techniques and threshold may be dependent on the blockchain. For example, theblockchain A 124 may require a first threshold number of verifications, and theblockchain B 126 may require a second threshold number of verifications. Furthermore, the structure of the blockchains may vary between different blockchains. Accordingly, theblockchain decision manager 112 and thestorage controller 114 are configured to manage the different blockchain types. In effect, each of the blockchain types are managed by blockchain nodes, which may comprise a combination of theblockchain decision manager 112, thestorage controller 114, and blockchain parameters, which are enforced by theblockchain decision manager 112 and thestorage controller 114. - To create a blockchain, a user using the
host device 102 may transmit an blockchain instruction to thestorage device 110. The instruction may include parameters indicating a type of blockchain (e.g., types of objects and or blockchain structure), access rights, and indication of whether the blockchain will be distributed, etc. To control access rights, the user may have a pin and indicate that the only users that have access to that pin can edit the created blockchain. Furthermore, the user can indicate a set of pins that have access rights. Varying levels of access may be indicated that permit reading from and/or writing to the blockchain, locking the blockchain, etc. If the created blockchain is to be distributed, the instructions may include an identification of other parties/devices that will support the blockchain. In response to the instruction, thestorage device 110 may generate the blockchain and store it on thestorage media 116. Theblockchain decision manager 112 stores the parameters for use in subsequent read/write requests for the generated blockchain. If the blockchain is distributed, an identification (and parameters) of the blockchain are transmitted to the other devices supporting the blockchain. In some implementations, login credentials (e.g., username/password) may be utilized by a user to manage thestorage device 110 and/or variousblockchain data structures - After the blockchain is generated, the
host device 102 may transmit an object to thestorage device 110 for storage in one or more blockchains. The object may be transmitted in a payload which may include metadata. The metadata may include one or more pins. Theblockchain decision manager 112 analyzes the received payload and determines whether the received pins have write access to the generated blockchain (e.g., using the stored parameters). If the pin has access rights, theblockchain decision manager 112 selects the blockchain and transmits the information to thestorage controller 114. Thestorage controller 114 stores the object to the generated blockchain using the methods described herein. - The
host device 102 may also transmit a read request that identifies a blockchain or an object in the blockchain. The request may be included in a payload which includes metadata such as a pin associated with a user. Theblockchain decision manager 112 determines whether the request has access rights based on the pin. If theblockchain decision manager 112 determines that the request has access rights, then theblockchain decision manager 112 instructs thestorage controller 114 to retrieve the identified object or blockchain. The requested information is then transmitted to thehost device 102. - In some example implementations, a read request from a non-contributor (e.g., a host/user that does not have write access) is recorded as a transaction to a blockchain data structure. For example, if the
host device 102 transmits a read request, theblockchain decision manager 112 determines that the read request has read access (e.g., based on pin or cryptographically signed request) and records a transaction to one or more blockchain data structures. The transaction includes the user/host device that requested access. Accordingly, a complete forensic history is recorded for blockchain transactions. A blockchain data structure may be dedicated to recording read/write request transactions or such transactions may be recorded to the blockchain data structure being accessed. Similarly, if a read/write request is rejected (e.g., based on invalid signing, invalid pin, invalid object), then a repudiation transaction may be generated and stored in one or more blockchain data structures. The repudiation transaction may include an indication of the party (e.g., host device) that requested access to the blockchain data structure. The indication may include a public key associated with the party requesting access. - The
cryptography manager 118 may store an index of pins associated with cryptographic keys or key pairs. Accordingly, when a user transmits an object to thestorage device 110 with an identification of a pin, thecryptography manager 118 may retrieve the key associated with the pin to sign the object before storage of the object to the storage device. Accordingly, the object is verifiable as being transmitted by a pin and signed by a key generated by thestorage device 110. - Blockchains may be used to store different objects/transactions including, for example, images, documents, document changes, access logs, transactions involving different type of objects, etc. Each blockchain may be identified by using a blockchain ID, which may be used to open a blockchain session, edit a blockchain data structure, and close a blockchain session. In one example, a blockchain is utilized to store document records. The document blockchain can be used to determine integrity of a document during the document history. For example, a first draft of a document is stored to the
storage device 110, and a document blockchain is utilized to store the history of the document. Thecryptography manager 118 performs a cryptographic hash (e.g., SHA-1, SHA-2, SHA-3) of the documents and stores the hash output in the document blockchain as a transaction. The document itself may be stored to another location in thestorage media 116. When a subsequent version of a document is stored to thestorage device 110, theblockchain decision manager 112 determines the amount of change to the document relative to the previously stored document. Theblockchain decision manager 112 may retrieve the previously stored copy of the document of thestorage media 116 and compare it to the new version of the documents. If the new document has changed (e.g., delta) above a threshold, then a new cryptographic hash is performed by thecryptography manager 118, and the new hash output is stored to the document blockchain. The new hash may be linked to the previous hash using various techniques. One blockchain may be utilized to store the history of a single document, or one blockchain may be utilized to store hash functions of several documents. The blockchain of hash outputs of documents may be utilized to verify integrity of a document at a certain time. It should be understood that the term “document” is not limited to text documents and may include contracts, programs, code, or other types of media. - Another example blockchain is a blockchain that is configured to store access logs to the storage device. For example, each time an object is transmitted to the device for storage to the
storage media 116, such activity is monitored and tracked by thestorage device 110. Accordingly, a verifiable history of access (e.g., read/write access) may be logged to access log blockchain. A single access log blockchain may be utilized to document access logs to the storage device itself or to document access to one or more blockchains managed by the storage device 110 (or networked device). Similarly, access logs stored to a blockchain may be based on a level or change in a level of access to the storage device. For example, an administrator of thestorage device 110 may edit the level of access to thestorage device 110. Such changes be logged and stored to the access log blockchain. - In some example implementations, an object/transaction is cryptographically signed by the
host device 102 before it is transmitted to thestorage device 110. Accordingly, theblockchain decision manager 112 may determine whether the object is validly signed using a public key associated with thehost device 102. Thecryptography manager 118 may store an index of public keys that have read and/or write access to one or more of theblockchain data structures blockchain decision manager 112 may select one of theblockchain data structures decision manager 112 may determine whether the signature is associated with read access. If so, then an access transaction may be generated and stored to one or more blockchain data structures. If the read request does not have access rights, then a repudiation transaction may be recorded to one or more blockchain data structures. Accordingly, the complete forensic history of blockchain access is stored. - The
host device 102 may include a cryptography manager that manages cryptographic keys. Thehost device 102 may include a set of keys that are used based on different objects and/or blockchains. For example, a first key pair may be utilized for a document blockchain data structure, and a second key pair may be utilized for an image blockchain data structure. Similarly, different keys may be associated with different users of thehost device 102. When a blockchain data structure is created by the host device, thehost device 102 may indicate which keys have what level of access (e.g., read and/or write access, administrative access). Accordingly, thecryptography manager 118 stores a record/index of levels of access for the generated blockchain. Subsequently, access records associated with a blockchain data structure may be changed using a key with administrative access. A change in access records may include, for example, a change in a level of access associated with a key, an addition of a key to the access records, or a removal of a key from the access records. - A change in access rights, blockchain type, blockchain parameters, etc. may be instituted using a rule change transaction. For example, the user of the
host device 102 may select a blockchain and a change in blockchain storage conditions and generate a rule change transaction that is signed by a signing key associated with the user or thehost device 102. The signed rule change transaction is transmitted to thestorage device 110, and theblockchain decision manger 112 determines whether the rule change transaction the user has the requisite rights to change the rules. The determination may be based on validation of the cryptographic signature, for example. - In some example implementations, users or parties are incentivized to run a blockchain node (e.g., the storage device 110) for access to verified data objects. Accordingly, the more parties running blockchain nodes means that the data is more secure and completely verified. Furthermore, some parties, such as customers, may pay to access the secure and verified data. Such example customers may be “read-only” users because they can only read data but not add data (e.g., append) to the blockchains. Other incentive structures are contemplated.
-
FIG. 2 illustrates an example data flow diagram 200 for a blockchain storage device system. The data flow diagram 200 includes user A 202, user B 204, and user C 206. Such users may utilize one or more different host computing devices to store objects to one or more storage devices that may/may not store objects to different blockchains based one or more blockchain storage conditions. Each of the user A 202, the user B 204, and or the user C 206 may be associated with a key pair (e.g., RSA or elliptic curve) that includes a public and a private key. The private keys may be used to cryptographically sign objects sent to the one or more blockchain storage devices. These cryptographic signatures may be utilized to verify the origin of the signed objects. - Example blockchain storage devices include an
object miner A 212 or anobject miner B 234, which may be implemented as a storage device configured to store objects generated by a host computing device corresponding to the user A 202, the user B 204, and/or the user C 206. Theobject miner A 212 and theobject miner B 234 includeblockchain decision managers blockchain decision managers object miner A 212 includesobject storage 216, and theobject miner B 234 includes theobject storage 238. Theobject miners miner 224 may be geographically co-located in the same room of a building or may be geographically separated in different rooms, buildings, countries, continents, etc. Theobject miners object miners - A
miner 224 is another example of a blockchain storage device. Theminer 224 does not include a blockchain decision manager. Rather, theminer 224 receives transactions from other devices/users where the other devices/users have already validated the transaction. Theminer 224 receives transactions and stores them to respective blockchains. It should be understood that a blockchain storage device system may include more devices than illustrated inFIG. 2 . Furthermore, as illustrated, different devices may include different blockchains. For example, anobject C blockchain 222 is a non-distributed blockchain and is managed by theobject miner A 212. Similarly, anobject D blockchain 244 is a non-distributed blockchain which is managed by theobject miner B 234. Only user C 206 may have access to theobject D blockchain 244, for example. Furthermore, different blockchains on a device may be public or private. - In
FIG. 2 , the user A 202 signs an object (e.g., an object type A 208) using the private key associated with the user A 202. The signed object type A 208 is transmitted to theobject miner A 212. The signed object type A 208 may be transmitted to theobject miner A 212 because theobject miner A 212 is the local storage device to the user A 202. The signed object type A 208 may be transmitted as a part of a payload. The signed object type A 208 is stored in theobject storage 216, and hedecision manager 214 analyzes the signed object type A 208 to determine whether the signed object type A 208 satisfies a blockchain storage condition. Based at least on the object type (e.g., type A) and validation of the signature, the object type A 208 satisfies one or more blockchain storage conditions. Theobject miner A 212 cryptographically signs the object type A 208 using the private key (e.g., signing key) to yield anobject A transaction 210. In implementations, theobject A transaction 210 is a doubly signed object (e.g., signed by the user A 202 and the object miner A 212). - The
object A transaction 210 is stored in anobject A blockchain 218, which is distributed blockchain. Accordingly, theobject A blockchain 218 is synced across theobject miner A 212, theminer 224, and theobject miner B 234. To synchronize the blockchains, theobject miner A 212 broadcasts theobject A transaction 210 to theminer 224 and theobject miner B 234. Theminer 224 and theobject miner B 234 check for valid signatures by the transaction originator (e.g., the user A 202) and the original miner (e.g., the object miner A 212) and stores theobject A transaction 210 to the respective blockchains responsive to the validation of the signatures. Accordingly, an object miner may be considered the authenticator of a valid blockchain transactions, and a miner may be considered a device that receives an authorized transaction. In some example implementations, the signed object type A 208 is also transmitted to the miner 223 and theobject miner B 234 for storage in theobject storage 226 and theobject storage 238, respectively. Accordingly, the object type A 208 may be retrieved from any of the devices and validated by any of the devices using theobject A blockchain 218. - Because the
object A 210 is signed by both the user A 202 and theobject miner A 212, the lineage of the object A 208 may be traced and verified (e.g., integrity and no-repudiation). Accordingly, when the object A 208 is later retrieved from one or more of the devices, the integrity of the object A 208 may be confirmed utilizing theobject A blockchain 218. - In one example implementation, the object type A 208 does not satisfy a blockchain storage condition. As such, the signed object type A 208 may be stored in the
object storage 216. The object type A 208 may not satisfy the blockchain storage condition based on an invalid signature and/or invalid access rights to a blockchain. In another example, the object type A 208 does not satisfy the blockchain storage condition because theobject miner A 212 does not include a blockchain for storing objects of type A. In some example implementations, an object is not signed before being transmitted to an object miner (e.g., a storage device). In such an example, the object may not be authorized to be stored in a blockchain. In other words, an unsigned object does not satisfy a blockchain storage condition in some example implementations. The unsigned object may be stored in theobject storage 216, for example. -
FIG. 3 illustrates another example data flow diagram 300 for a blockchain storage device system. The data flow diagram 300 includes user A 302, user B 304, and user C 306. Such users may utilize one or more different host computing devices to store objects to one or more storage devices that may/may not store objects to different blockchains based one or more blockchain storage conditions. Each of the user A 302, the user B 304, and or the user C 306 may be associated with a key pair (e.g., RSA or elliptic curve) that includes a public and a private key. The private keys may be used to cryptographically sign objects sent to the one or more blockchain storage devices. These cryptographic signatures may be utilized to verify the origin of the signed objects. - Example blockchain storage devices include an
object miner A 312 or anobject miner B 334, which may be implemented as a storage device configured to store objects generated by a host computing device corresponding to the user A 302, the user B 304, and/or the user C 306. Theobject miner A 312 and theobject miner B 334 includeblockchain decision managers blockchain decision managers object miner A 312 includesobject storage 316, and theobject miner B 334 includes theobject storage 338. Theobject miners miner 324 may be geographically co-located in the same room of a building or may be geographically separated in different rooms, buildings, countries, continents, etc. Theobject miners object miners miner 324 may include cryptography managers (not shown) that manage one or more cryptographic key pairs associated with the object miners, respectively. The cryptography managers may be further utilized to perform other cryptographic functions such as hashing (e.g., linking transaction blocks for blockchains) and encryption. - The
miner 324 is another example of a blockchain storage device. Theminer 324 does not include a blockchain decision manager. Rather, theminer 324 receives transactions from other devices/users where the other devices/users have already validated the transaction. Theminer 324 receives transactions and stores them to respective blockchains. It should be understood that a blockchain storage device system may include more devices than illustrated inFIG. 3 . Furthermore, as illustrated, different devices may include different blockchains. For example, anobject C blockchain 322 is a non-distributed blockchain and is managed by theobject miner A 312. Similarly, anobject D blockchain 344 is a non-distributed blockchain which is managed by theobject miner B 334. Only user C 306 may have access to theobject D blockchain 344, for example. Furthermore, different blockchains on a device may be public or private. - In
FIG. 3 , the user B 304 broadcasts aread request 308 to the object miner A. The readrequest 308 may be signed by a signing key of the user B 304, and the readrequest 308 is a request for an object of type B. Thedecision manager 314 determines that the readrequest 308 is valid. Such a determination may depend on the cryptographic signature or may be based on access rights managed by theobject miner A 312. After validating the readrequest 308, the requested object is retrieved from theobject storage 316 and returned to the user B 304. Furthermore, anobject B transaction 310 is generated based on the read request. Theobject B transaction 310 indicates that a valid read request was received by theobject miner A 312 from the user A 302. Theobject B transaction 310 is stored to anobject B blockchain 320 stored on theobject miner A 312 and is broadcast to other devices supporting theobject B blockchain 220. Such devices include the miner 223 and theobject miner 234. Accordingly, a record of the read request is securely stored in the devices. In some example implementations, the object B transaction is signed by theobject miner A 312. -
FIG. 4 illustrates another example data flow diagram 400 for a blockchain storage device system. The data flow diagram 400 includesuser A 402, user B 404, and user C 406. Such users may utilize one or more different host computing devices to store objects to one or more storage devices that may/may not store objects to different blockchains based one or more blockchain storage conditions. Each of theuser A 402, the user B 404, and or the user C 406 may be associated with a key pair (e.g., RSA or elliptic curve) that includes a public and a private key. The private keys may be used to cryptographically sign objects sent to the one or more blockchain storage devices. These cryptographic signatures may be utilized to verify the origin of the signed objects. - Example blockchain storage devices include an
object miner A 412 or anobject miner B 434, which may be implemented as a storage device configured to store objects generated by a host computing device corresponding to theuser A 402, the user B 404, and/or the user C 406. Theobject miner A 412 and theobject miner B 434 includeblockchain decision managers blockchain decision managers object miner A 412 includesobject storage 416, and theobject miner B 434 includes theobject storage 438. Theobject miners miner 224 may be geographically co-located in the same room of a building or may be geographically separated in different rooms, buildings, countries, continents, etc. Theobject miners object miners - A
miner 424 is another example of a blockchain storage device. Theminer 424 does not include a blockchain decision manager. Rather, theminer 424 receives transactions from other devices/users where the other devices/users have already validated the transaction. Theminer 424 receives transactions and stores them to respective blockchains. It should be understood that a blockchain storage device system may include more devices than illustrated inFIG. 4 . Furthermore, as illustrated, different devices may include different blockchains. For example, anobject C blockchain 422 is a non-distributed blockchain and is managed by theobject miner A 412. Similarly, anobject D blockchain 444 is a non-distributed blockchain which is managed by theobject miner B 434. Only user C 406 may have access to theobject D blockchain 444, for example. Furthermore, different blockchains on a device may be public or private. - In
FIG. 4 , theuser A 402 generates, signs, and transmits anobject B transaction 410. Theobject B transaction 410 may be referred to as a user generated blockchain transaction because it is generated by theuser A 402 rather than one of the object miners. Theobject B transaction 410 forces the devices supporting object be to store an object to the object B blockchain. Accordingly, each of the devices respond as simple miners (rather than object miners) and as if the transaction was generated by an object miner. Theobject miner A 412 receives theobject B transaction 410 and stores the signed object B transaction to theobject B blockchain 420. Thedecision manager 414 does not make any decision with regard to any blockchain storage condition. Thedecision manager 414 may determine that theuser A 402 is authorized to create such a transaction based on the signature. Theobject B transaction 410 is transmitted to the other devices. It should be understood that theuser A 402 may transmit theobject B transaction 410 to the devices or that theobject miner A 412 relays theobject B transaction 410 to the other devices. -
FIG. 5 illustratesexample operations 500 for storing an object to a blockchain stored in a blockchain storage device. A receivingoperation 502 receives an object from a host device at a storage device. The object may be signed by a signing key of the user of the host device and may be included in a payload. An determiningoperation 504 determines whether the object satisfies a blockchain storage condition. The determiningoperation 504 may read metadata included in the payload, confirm a valid singing of the object, etc. The metadata may include a pin, a level of access, object type, etc. The determiningoperation 504 may further determine the object type by analyzing the object. The blockchain storage condition may be based on an indication of importance, an indication of redundancy, the type of object, etc. For example, if the payload includes metadata with a field indicating a high level of redundancy, then the object satisfies the blockchain storage condition. If the object satisfies the blockchain storage condition, a selectingoperation 506 selects one or more blockchain data structures based at least on the type of the object. For example, if it is determined that the type of the object is an access log, the selectingoperation 506 selects the access log data structure. The selection may be further based on a level of access (e.g., based on a pin) or level of redundancy indication. For example, if the high level of redundancy is indicated, then a distributed blockchain (of the object type) may be selected. Similarly, if a medium level of redundancy is indicated, then a non-distributed blockchain data structure may be selected. If a low level of redundancy is indicated, then the storage condition may not be satisfied. - A
signing operation 508 cryptographically signs the object using a private key associated with the storage device (e.g., associated with a public key of the storage device). A transmittingoperation 510 transmits the signed object to connected/networked devices. The transmittingoperation 510 may occur when the blockchain is distributed. A storingoperation 512 stores at least a representation of the object to the selected one or more blockchain data structures. The storingoperation 512 may coincide with the transaction being “mined” (e.g., verified) by other connected/networked storage devices. A storingoperation 514 stores the object tin the storage media of the storage device. If the object does not satisfy the blockchain storage condition, then astoring operation 514 stores the object in a storage media of the storage device without storing the object in a blockchain data structure. -
FIG. 6 illustratesalternative example operations 600 for storing an object to a blockchain stored in a blockchain storage device. Specifically,FIG. 6 illustrates theoperations 600 when the object is a document. A receivingoperation 602 receives a payload from a host device at a storage device. The received payload includes a document object, which may be signed by a signing key of the user of the host device. A comparingoperation 604 compares the received document to a previous version of the document. A determiningoperation 606 determines whether the difference between the documents satisfies a blockchain storage condition. For example, the blockchain condition may correspond to a threshold percentage of the document being changed. If, for example, 15% of the document has been changed, then the blockchain storage condition is satisfied. If the blockchain storage condition is satisfied, then aselection operation 608 selects one or more blockchain data structures based on the type of the object (e.g., document). Accordingly, a blockchain data structure for storing documents or representations of documents may be selected. - A hashing
operation 610 hashes the document to produce a hash output. Asigning operation 612 cryptographically signs the hash output using a private key associated with the storage device to generate an object transaction. A transmittingoperation 614 transmits the object transaction to connected devices. A storingoperation 616 stores the object transaction to one or more blockchain data structures. Another storingoperation 618 stores the documents as a document object in the storage media of the storage device. If it is determined that the differences between the documents do not satisfy the blockchain storage condition, then the storingoperation 618 stores the document in the storage media of the storage device. Accordingly, if another version of the documents is transmitted to the storage device, then the previously stored version may be used for comparison. - In some implementations, each document transmitted to the storage device is hashed and stored to a document blockchain such that hash outputs may be used to establish document histories. In such implementations, the blockchain storage condition may be based on an indication of importance included with the payload including the document. If the document is deemed important, then the blockchain storage condition is satisfied and the document is hashed to produce the hash output, which is stored to one or more blockchain data structures.
-
FIG. 7 illustratesalternative example operations 700 for storing an object to a blockchain stored in a blockchain storage device. A receivingoperation 702 receives a payload from a host device at a storage device. The pay includes one or more access record objects (e.g., logs). The access record objects may be cryptographically signed by a singing key of the user of the host device. An analyzingoperation 704 analyzes the access records (or metadata included in the payload) to determine the level of access. A determiningoperation 706 determines whether the level of access satisfies a blockchain storage condition. For example, if the level of access changes (e.g., from a previous level of access), then the condition is satisfied. In another example, if the level of access is above a threshold, then the condition is satisfied. If the condition is satisfied, a selectingoperation 708 selects one or more blockchain data structures. The selection may be based on the level of access, for example. Asigning operation 710 cryptographically signs the access logs using a private key associated with the storage device to generate an object transaction. A transmittingoperation 712 transmits the object transaction to connected devices. A storingoperation 714 stores the object transaction to the selected one or more blockchain data structures. A storingoperation 716 stores the access log objects in a storage media of the storage device. If the blockchain storage condition is not satisfied, a storingoperation 716 stores the access logs in the storage media of the storage device. -
FIG. 8 illustrates anexample processing system 800 that may be useful in implementing the described technology. Theprocessing system 800 is capable of executing a computer program product embodied in a tangible computer-readable storage medium to execute a computer process. Data and program files may be input to theprocessing system 800, which reads the files and executes the programs therein using one or more processors (e.g., CPUs, GPUs, ASICs). Some of the elements of aprocessing system 800 are shown inFIG. 8 wherein aprocessor 802 is shown having an input/output (I/O) section 804, a Central Processing Unit (CPU) 806, and amemory section 808. There may be one ormore processors 802, such that theprocessor 802 of theprocessing system 800 comprises a single central-processing unit 806, or a plurality of processing units. The processors may be single core or multi-core processors. Theprocessing system 800 may be a conventional computer, a distributed computer, or any other type of computer. The described technology is optionally implemented in software loaded inmemory 808, astorage unit 812, and/or communicated via a wired orwireless network link 814 on a carrier signal (e.g., Ethernet, 3G wireless, 5G wireless, LTE (Long Term Evolution)) thereby transforming theprocessing system 800 inFIG. 8 to a special purpose machine for implementing the described operations. Theprocessing system 800 may be an application specific processing system configured for supporting a blockchain storage device. - The I/O section 804 may be connected to one or more user-interface devices (e.g., a keyboard, a touch-
screen display unit 818, etc.) or astorage unit 812. Computer program products containing mechanisms to effectuate the systems and methods in accordance with the described technology may reside in thememory section 808 or on thestorage unit 812 of such asystem 800. - A
communication interface 824 is capable of connecting theprocessing system 800 to an enterprise network via thenetwork link 814, through which the computer system can receive instructions and data embodied in a carrier wave. When used in a local area networking (LAN) environment, theprocessing system 800 is connected (by wired connection or wirelessly) to a local network through thecommunication interface 824, which is one type of communications device. When used in a wide-area-networking (WAN) environment, theprocessing system 800 typically includes a modem, a network adapter, or any other type of communications device for establishing communications over the wide area network. In a networked environment, program modules depicted relative to theprocessing system 800 or portions thereof, may be stored in a remote memory storage device. It is appreciated that the network connections shown are examples of communications devices for and other means of establishing a communications link between the computers may be used. - In an example implementation, a storage controller, a blockchain decision manager, a cryptography manager, and other modules may be embodied by instructions stored in
memory 808 and/or thestorage unit 812 and executed by theprocessor 802. Further, local computing systems, remote data sources and/or services, and other associated logic represent firmware, hardware, and/or software, which may be configured to assist in supporting the blockchain storage device. A blockchain storage may be implemented using a general-purpose computer and specialized software (such as a server executing service software), a special purpose computing system and specialized software (such as a mobile device or network appliance executing service software), or other computing configurations. In addition, keys, device information, identification, configurations, etc. may be stored in thememory 808 and/or thestorage unit 812 and executed by theprocessor 802. - The
processing system 800 may be implemented in a device, such as a user device, storage device, IoT device, a desktop, laptop, computing device. Theprocessing system 800 may be a storage device that executes in a user device or external to a user device. - In addition to methods, the embodiments of the technology described herein can be implemented as logical steps in one or more computer systems. The logical operations of the present technology can be implemented (1) as a sequence of processor-implemented steps executing in one or more computer systems and/or (2) as interconnected machine or circuit modules within one or more computer systems. Implementation is a matter of choice, dependent on the performance requirements of the computer system implementing the technology. Accordingly, the logical operations of the technology described herein are referred to variously as operations, steps, objects, or modules. Furthermore, it should be understood that logical operations may be performed in any order, unless explicitly claimed otherwise or unless a specific order is inherently necessitated by the claim language.
- Data storage and/or memory may be embodied by various types of processor-readable storage media, such as hard disc media, a storage array containing multiple storage devices, optical media, solid-state drive technology, ROM, RAM, and other technology. The operations may be implemented processor-executable instructions in firmware, software, hard-wired circuitry, gate array technology and other technologies, whether executed or assisted by a microprocessor, a microprocessor core, a microcontroller, special purpose circuitry, or other processing technologies. It should be understood that a write controller, a storage controller, data write circuitry, data read and recovery circuitry, a sorting module, and other functional modules of a data storage system may include or work in concert with a processor for processing processor-readable instructions for performing a system-implemented process.
- For purposes of this description and meaning of the claims, the term “memory” means a tangible data storage device, including non-volatile memories (such as flash memory and the like) and volatile memories (such as dynamic random-access memory and the like). The computer instructions either permanently or temporarily reside in the memory, along with other information such as data, virtual mappings, operating systems, applications, and the like that are accessed by a computer processor to perform the desired functionality. The term “memory” expressly does not include a transitory medium such as a carrier signal, but the computer instructions can be transferred to the memory wirelessly.
- The above specification, examples, and data provide a complete description of the structure and use of example embodiments of the disclosed technology. Since many embodiments of the disclosed technology can be made without departing from the spirit and scope of the disclosed technology, the disclosed technology resides in the claims hereinafter appended. Furthermore, structural features of the different embodiments may be combined in yet another embodiment without departing from the recited claims.
Claims (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/858,214 US20190207748A1 (en) | 2017-12-29 | 2017-12-29 | Blockchain storage device |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/858,214 US20190207748A1 (en) | 2017-12-29 | 2017-12-29 | Blockchain storage device |
Publications (1)
Publication Number | Publication Date |
---|---|
US20190207748A1 true US20190207748A1 (en) | 2019-07-04 |
Family
ID=67058565
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/858,214 Abandoned US20190207748A1 (en) | 2017-12-29 | 2017-12-29 | Blockchain storage device |
Country Status (1)
Country | Link |
---|---|
US (1) | US20190207748A1 (en) |
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20200084041A1 (en) * | 2018-09-07 | 2020-03-12 | Nebulas IO Limited | Automated Blockchain Protocol Update |
US20200226114A1 (en) * | 2019-06-28 | 2020-07-16 | Alibaba Group Holding Limited | Blockchain based hierarchical data storage |
US10936721B1 (en) * | 2018-03-01 | 2021-03-02 | Amdocs Development Limited | System, method, and computer program for splitting and distributing a privileged software component into dependent components in order to deliver better security |
US11086621B2 (en) | 2019-11-08 | 2021-08-10 | Alipay (Hangzhou) Information Technology Co., Ltd. | System and method for blockchain-based decentralized application development |
US11108545B2 (en) * | 2019-05-31 | 2021-08-31 | Advanced New Technologies Co., Ltd. | Creating a blockchain account and verifying blockchain transactions |
US20210294920A1 (en) * | 2018-07-10 | 2021-09-23 | Netmaster Solutions Ltd | A method and system for managing digital evidence using a blockchain |
US11163775B2 (en) | 2019-11-08 | 2021-11-02 | Alipay (Hangzhou) Information Technology Co., Ltd. | System and method for implementing a blockchain-based decentralized application |
WO2022164671A1 (en) * | 2021-01-28 | 2022-08-04 | Emtruth, Inc. | Blockchain-based data management of distributed binary objects |
US11429541B2 (en) * | 2019-01-07 | 2022-08-30 | Dell Products L.P. | Unlocking of computer storage devices |
US11539510B2 (en) * | 2019-08-02 | 2022-12-27 | Zengo Ltd | System and method of cryptographic key management in a plurality of blockchain based computer networks |
US20230034197A1 (en) * | 2021-08-02 | 2023-02-02 | Capital One Services, Llc | Forensic isolation of a production cloud computing and storage environment |
US11615007B2 (en) * | 2017-10-23 | 2023-03-28 | Siemens Aktiengesellschaft | Method and control system for controlling and/or monitoring devices |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7765217B2 (en) * | 2004-12-16 | 2010-07-27 | Nec Corporation | System and method for managing and arranging data based on an analysis of types of file access operations |
US20170005804A1 (en) * | 2015-07-02 | 2017-01-05 | Nasdaq, Inc. | Systems and methods of secure provenance for distributed transaction databases |
US20170031676A1 (en) * | 2015-07-27 | 2017-02-02 | Deja Vu Security, Llc | Blockchain computer data distribution |
US20180157825A1 (en) * | 2013-03-15 | 2018-06-07 | Brick Eksten | Systems and methods for determining trust levels for computing components using blockchain |
US20180260212A1 (en) * | 2017-03-10 | 2018-09-13 | Salesforce.Com, Inc. | Blockchain version control systems |
US20180285839A1 (en) * | 2017-04-04 | 2018-10-04 | Datient, Inc. | Providing data provenance, permissioning, compliance, and access control for data storage systems using an immutable ledger overlay network |
US20190066068A1 (en) * | 2017-08-22 | 2019-02-28 | Sap Se | Transaction Platform Providing Unified Interaction with Multiple Heterogeneous Blockchains |
-
2017
- 2017-12-29 US US15/858,214 patent/US20190207748A1/en not_active Abandoned
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7765217B2 (en) * | 2004-12-16 | 2010-07-27 | Nec Corporation | System and method for managing and arranging data based on an analysis of types of file access operations |
US20180157825A1 (en) * | 2013-03-15 | 2018-06-07 | Brick Eksten | Systems and methods for determining trust levels for computing components using blockchain |
US20170005804A1 (en) * | 2015-07-02 | 2017-01-05 | Nasdaq, Inc. | Systems and methods of secure provenance for distributed transaction databases |
US20170031676A1 (en) * | 2015-07-27 | 2017-02-02 | Deja Vu Security, Llc | Blockchain computer data distribution |
US20180260212A1 (en) * | 2017-03-10 | 2018-09-13 | Salesforce.Com, Inc. | Blockchain version control systems |
US20180285839A1 (en) * | 2017-04-04 | 2018-10-04 | Datient, Inc. | Providing data provenance, permissioning, compliance, and access control for data storage systems using an immutable ledger overlay network |
US20190066068A1 (en) * | 2017-08-22 | 2019-02-28 | Sap Se | Transaction Platform Providing Unified Interaction with Multiple Heterogeneous Blockchains |
Cited By (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11615007B2 (en) * | 2017-10-23 | 2023-03-28 | Siemens Aktiengesellschaft | Method and control system for controlling and/or monitoring devices |
US10936721B1 (en) * | 2018-03-01 | 2021-03-02 | Amdocs Development Limited | System, method, and computer program for splitting and distributing a privileged software component into dependent components in order to deliver better security |
US20210294920A1 (en) * | 2018-07-10 | 2021-09-23 | Netmaster Solutions Ltd | A method and system for managing digital evidence using a blockchain |
US20200084041A1 (en) * | 2018-09-07 | 2020-03-12 | Nebulas IO Limited | Automated Blockchain Protocol Update |
US11429541B2 (en) * | 2019-01-07 | 2022-08-30 | Dell Products L.P. | Unlocking of computer storage devices |
US11108545B2 (en) * | 2019-05-31 | 2021-08-31 | Advanced New Technologies Co., Ltd. | Creating a blockchain account and verifying blockchain transactions |
US20200226114A1 (en) * | 2019-06-28 | 2020-07-16 | Alibaba Group Holding Limited | Blockchain based hierarchical data storage |
US10853341B2 (en) * | 2019-06-28 | 2020-12-01 | Advanced New Technologies Co., Ltd. | Blockchain based hierarchical data storage |
US11030175B2 (en) * | 2019-06-28 | 2021-06-08 | Advanced New Technologies Co., Ltd. | Blockchain based hierarchical data storage |
US11288247B2 (en) * | 2019-06-28 | 2022-03-29 | Advanced New Technologies Co., Ltd. | Blockchain based hierarchical data storage |
US11539510B2 (en) * | 2019-08-02 | 2022-12-27 | Zengo Ltd | System and method of cryptographic key management in a plurality of blockchain based computer networks |
US20230028854A1 (en) * | 2019-08-02 | 2023-01-26 | Zengo Ltd | System and method of cryptographic key management in a plurality of blockchain based computer networks |
US11163775B2 (en) | 2019-11-08 | 2021-11-02 | Alipay (Hangzhou) Information Technology Co., Ltd. | System and method for implementing a blockchain-based decentralized application |
US11429617B2 (en) | 2019-11-08 | 2022-08-30 | Alipay (Hangzhou) Information Technology Co., Ltd. | System and method for blockchain-based data synchronization |
US11086621B2 (en) | 2019-11-08 | 2021-08-10 | Alipay (Hangzhou) Information Technology Co., Ltd. | System and method for blockchain-based decentralized application development |
WO2022164671A1 (en) * | 2021-01-28 | 2022-08-04 | Emtruth, Inc. | Blockchain-based data management of distributed binary objects |
US11870883B2 (en) | 2021-01-28 | 2024-01-09 | Emtruth, Inc. | Blockchain-based data management of distributed binary objects |
US20230034197A1 (en) * | 2021-08-02 | 2023-02-02 | Capital One Services, Llc | Forensic isolation of a production cloud computing and storage environment |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20190207748A1 (en) | Blockchain storage device | |
US11445022B2 (en) | System and method for service level agreement based data verification | |
US11429738B2 (en) | Blockchain endorsement with approximate hash verification | |
US10846416B2 (en) | Method for managing document on basis of blockchain by using UTXO-based protocol, and document management server using same | |
US11539527B2 (en) | Peer node recovery via approximate hash verification | |
US12003647B2 (en) | Reduced-step blockchain verification of media file | |
US20210209373A1 (en) | Media authentication using distributed ledger | |
US20220214995A1 (en) | Blockchain data archiving method, apparatus, and computer-readable storage medium | |
US10432411B2 (en) | System and method for file time-stamping using a blockchain network | |
US11711202B2 (en) | Committing data to blockchain based on approximate hash verification | |
US11689356B2 (en) | Approximate hash verification of unused blockchain output | |
US11387979B2 (en) | Partially-ordered blockchain | |
JP2021525931A (en) | Efficient verification for blockchain | |
US20200382309A1 (en) | Approximate hash verification for blockchain | |
US11917088B2 (en) | Integrating device identity into a permissioning framework of a blockchain | |
US11693948B2 (en) | Verifiable labels for mandatory access control | |
US11816069B2 (en) | Data deduplication in blockchain platforms | |
US11804950B2 (en) | Parallel processing of blockchain procedures | |
WO2023051308A1 (en) | Data verification method and apparatus, device and storage medium | |
WO2022116761A1 (en) | Self auditing blockchain | |
US20240161078A1 (en) | Computing system for configurable off-chain storage for blockchains | |
CN117043772A (en) | Block chain data separation | |
JP7319461B2 (en) | METHOD AND APPARATUS FOR HOLDING PRIVATE DATA USING CONSORTIUM BLOCKCHAIN | |
US11435907B2 (en) | Ensuring data authenticity using notary as a service | |
Arpitha et al. | Data Storage, Security And Techniques In Cloud Computing |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: SEAGATE TECHNOLOGY LLC, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:COURTNEY, TIMOTHY JOHN;REEL/FRAME:044982/0283 Effective date: 20180102 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |