WO2021154157A1 - Échange de données basé sur une chaine de blocs - Google Patents

Échange de données basé sur une chaine de blocs Download PDF

Info

Publication number
WO2021154157A1
WO2021154157A1 PCT/SG2021/050042 SG2021050042W WO2021154157A1 WO 2021154157 A1 WO2021154157 A1 WO 2021154157A1 SG 2021050042 W SG2021050042 W SG 2021050042W WO 2021154157 A1 WO2021154157 A1 WO 2021154157A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
transaction
blockchain
chain storage
communication
Prior art date
Application number
PCT/SG2021/050042
Other languages
English (en)
Inventor
Xingjie YU
Huaqun Guo
Original Assignee
Agency For Science, Technology And Research
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Agency For Science, Technology And Research filed Critical Agency For Science, Technology And Research
Publication of WO2021154157A1 publication Critical patent/WO2021154157A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281—Proxies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0847—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving identity based encryption [IBE] schemes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/76—Proxy, i.e. using intermediary entity to perform cryptographic operations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/062—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying encryption of the keys

Definitions

  • the present disclosure relates to blockchain-based data exchange. Embodiments have particular, though not exclusive, application in access control and data sharing for supply chains.
  • a solution referred to as a "digital marketplace” is a many-to-many, web-based trading and collaboration solution that enables companies to perform basic exchange transactions, such as price and production specifications, and strategic supply chain collaboration, such as forecasting demand and new product development.
  • this solution is not suitable for sensitive data. This is because the data shared in the digital marketplace is transparent to every party that joins the digital marketplace. This means that sensitive data that should only be shared among selected parties cannot be well protected in a digital marketplace.
  • a clean room allows the sharing of sensitive data in a legal and secure data environment.
  • the clean room is used to represent the physical or virtual repository of the data and is managed by a third party.
  • the effectiveness of this solution for protecting data is highly dependent on an honest and reliable owner of the clean room who possesses all the plaintext of the sharing data.
  • Blockchain technology offers distributed ledgers that create a permanent and shared record of every transaction. All recorded transactions are visible to authorized participants, traceable within the ledger, immutable and irrevocable, which has prompted the increasing usage of blockchains for data sharing in supply chains as well as in other spheres.
  • Conventional examples include, a permissioned blockchain-based data sharing solution for supply chains with a particular focus on logistics, and a cold-chain logistics solution that uses blockchain to track and monitor the logistic information for transparent, regulated, secure and reliable data sharing.
  • the shared data is recorded on the blockchain. This limits the scalability of blockchain-based solutions. A large number of stakeholders may be involved in a supply chain, and the data that needs to be shared among the stakeholders could be massive and not limited to logistic data. As more stakeholders join the supply chain and the shared data grows, on-chain data sharing faces significant scalability issues.
  • the present disclosure provides, in a first aspect, a system for data exchange via a blockchain network comprising a plurality of nodes, at least some of said nodes being broadcast-and-monitor nodes (BMNs), the system comprising: a plurality of clients, each client being in communication with one of said BMNs; and off-chain storage in communication with the plurality of clients and with one of said
  • BPNs broadcast-and-monitor nodes
  • each client is configured to perform data transfer events comprising uploading a data object to and/or downloading a data object from the off-chain storage; and wherein each data transfer event is intermediated by two of said clients, or one of said clients and the off-chain storage, causing one or more data transactions to be published to the blockchain network via the respective BMNs with which they are in communication, said one or more data transactions not including the data object.
  • each data transaction comprises metadata that specifies a user ID of a recipient that is one of the clients or the off-chain storage; and the data transaction is forwarded to the recipient on detection by the BMN with which the recipient is in communication.
  • the metadata further comprises a data identifier of the data object, and a transaction type.
  • the user ID is a user ID of the off-chain storage
  • the transaction type is indicative of a data upload transaction, or a data access authorization transaction
  • the user ID is a user ID of the off-chain storage
  • the transaction type is indicative of a data access request transaction
  • the user ID is a user ID of a client that uploaded the data object to the off-chain storage
  • the transaction type is indicative of a data access confirmation transaction
  • the user ID is a user ID of a client that requested access to the data object.
  • a data owner of said clients comprises an access control component configured to control access to an encrypted data object uploaded by the data owner to the off-chain storage.
  • the access control component may be configured to control access by a proxy-assisted attribute-based encryption scheme.
  • the access control component on receiving a data access request transaction for the encrypted data object from a data requestor of said clients, is configured to: apply an access control policy to approve or reject the request; on approval, generate a proxy key for the data requestor; encrypt the proxy key; and transmit, to the BMN with which the data owner is in communication, a request to publish a data access authorization transaction to the blockchain network, the data access authorization transaction comprising a user ID of the off-chain storage, a data identifier of the encrypted data object, a public key of the data requestor if the public key is used as the user ID (otherwise, the user ID and the public key of the data requestor), and the encrypted proxy key.
  • the off- chain storage on receiving the data access authorization transaction, is configured to: partially decrypt the encrypted data object using the proxy key and the off-chain storage's private key, to generate intermediate data; and transmit, to the BMN with which the off-chain storage is in communication, a request to publish a data access confirmation transaction to the blockchain network, the data access confirmation transaction comprising a user ID of the data requestor, a data identifier of the encrypted data object, and the hash of the intermediate data.
  • the data requestor on receiving the data access confirmation transaction, is configured to: download the intermediate data from the off-chain storage; and decrypt the intermediate data.
  • the off-chain storage comprises at least one cloud storage server and/or at least one local storage server.
  • the off-chain storage is a cloud storage system; and at least one client of said plurality of clients comprises: a local blockchain; a plurality of local devices, each local device being in communication with one of a plurality of master devices, the master devices being nodes of the local blockchain or being connected to dedicated nodes of the local blockchain; and local storage in communication with the local blockchain and the master devices; wherein each master device is configured to perform local data transfer events comprising uploading the data object to and/or downloading the data object from the local storage for its associated local devices; wherein each master device is configured to perform data access control; wherein each local data transfer event is intermediated by two of said local devices, or one of said local devices and the local storage, causing one or more local data transactions to be published to the local blockchain via the respective master devices with which they are in communication, said one or more local data transactions not including the data object; and wherein the local storage acts as temporary storage for data to be uploaded to the cloud storage system, and is configured to upload the data to the cloud storage system periodically.
  • the present disclosure also provides, in a second aspect, a client system for exchanging data with one or more other client systems, the client system being in communication with a broadcast-and-monitor node (BMN) of a blockchain network comprising a plurality of nodes, and each of said one or more other client systems being in communication with a BMN of the blockchain network; wherein the client system, and each of the one or more other client systems, is in communication with off-chain storage; the off-chain storage also being in communication with a BMN of the blockchain network; wherein the client system is configured to perform data transfer events comprising uploading a data object to and/or downloading a data object from the off-chain storage; and wherein each data transfer event is intermediated by the client system, one of said other client systems, and/or the off-chain storage publishing one or more data transactions to the blockchain network via the respective BMNs with which they are in communication, said one or more data transactions not including the data object.
  • BMN broadcast-and-monitor node
  • each data transaction comprises metadata that specifies a user ID of a recipient that is one of the client systems or the off-chain storage; and the data transaction is forwarded to the recipient on detection by the BMN with which the recipient is in communication.
  • the metadata further comprises a data identifier of the data object, and a transaction type.
  • the user ID is a user ID of the off-chain storage
  • the transaction type is indicative of a data upload transaction, or a data access authorization transaction
  • the user ID is a user ID of the off-chain storage
  • the transaction type is indicative of a data access request transaction
  • the user ID is a user ID of a client system that uploaded the data object to the off-chain storage
  • the transaction type is indicative of a data access confirmation transaction
  • the user ID is a user ID of a client system that requested access to the data object.
  • the client system comprises an access control component configured to control access to an encrypted data object uploaded by the client system to the off-chain storage.
  • the access control component of the client system may be configured to control access by a proxy-assisted attribute-based encryption scheme.
  • the access control component on receiving a data access request transaction for the encrypted data object from a data requestor of said one or more other client systems, is configured to: apply an access control policy to approve or reject the request; on approval, generate a proxy key for the data requestor; encrypt the proxy key; and transmit, to the BMN with which the client system is in communication, a request to publish a data access authorization transaction to the blockchain network, the data access authorization transaction comprising a user ID of the off-chain storage, a data identifier of the encrypted data object, a public key of the data requestor, and the encrypted proxy key.
  • the present disclosure also provides, in a third aspect, a method for data exchange via a blockchain network comprising a plurality of nodes, at least some of said nodes being broadcast-and-monitor nodes (BMNs), the method being performed by: a plurality of clients, each client being in communication with one of said BMNs; and off-chain storage in communication with one of said BMNs; the method comprising: performing, by one or more of said clients, a data transfer event comprising uploading a data object to and/or downloading a data object from the off-chain storage; wherein the data transfer event is intermediated by the one or more clients and the off-chain storage causing one or more data transactions to be published to the blockchain network via the respective BMNs with which they are in communication, said one or more data transactions not including the data object.
  • BPNs broadcast-and-monitor nodes
  • each data transaction comprises metadata that specifies a user ID of a recipient that is one of the clients or the off-chain storage; and the data transaction is forwarded to the recipient on detection by the BMN with which the recipient is in communication.
  • the metadata may further comprise a data identifier of the data object, and a transaction type.
  • the user ID is a user ID of the off- chain storage; if the transaction type is indicative of a data access request transaction, the user ID is a user ID of a client that uploaded the data object to the off-chain storage; and if the transaction type is indicative of a data access confirmation transaction, the user ID is a user ID of a client that requested access to the data object.
  • the method may comprise, at a data owner of said clients, controlling access to an encrypted data object uploaded by the data owner to the off-chain storage.
  • the method may comprise, at the data owner, controlling access by a proxy-assisted attribute-based encryption scheme.
  • the method may comprise the data owner: applying an access control policy to approve or reject the request; on approval, generating a proxy key for the requestor; encrypting the proxy key; and transmitting, to the BMN with which the data owner is in communication, a request to publish a data access authorization transaction to the blockchain network, the data access authorization transaction comprising a user ID of the off-chain storage, a data identifier of the encrypted data object, a public key of the requestor, and the encrypted proxy key.
  • the off-chain storage on receiving the data access authorization transaction, the off-chain storage: partially decrypts the encrypted data object using the proxy key and the off-chain storage's private key, to generate intermediate data; and transmits, to the BMN with which the off-chain storage is in communication, a request to publish a data access confirmation transaction to the blockchain network, the data access confirmation transaction comprising a user ID of the requestor, a data identifier of the encrypted data object, and the hash of the intermediate data.
  • the requestor on receiving the data access confirmation transaction, the requestor: downloads the intermediate data from the off-chain storage; and decrypts the intermediate data.
  • the off-chain storage comprises at least one cloud storage server and/or at least one local storage server.
  • the present disclosure also provides, in a fourth aspect, a method, performed at a client device, for exchanging data with one or more other client devices, the client device being in communication with a broadcast-and-monitor node (BMN) of a blockchain network comprising a plurality of nodes, and each of said one or more other client devices being in communication with a BMN of the blockchain network; the client device, and each of the one or more other client devices, being in communication with off-chain data storage; the off-chain data storage also being in communication with a BMN of the blockchain network; the method comprising: performing a data transfer event comprising uploading a data object to or downloading a data object from the off-chain storage; wherein the data transfer event is intermediated by the client device and the off- chain storage publishing one or more data transactions to the blockchain network via the respective BMNs with which they are in communication, said one or more data transactions not including the data object.
  • a broadcast-and-monitor node BBN
  • the client device being in communication with
  • each data transaction comprises metadata that specifies a user ID of a recipient device that is one of the client devices or the at least one off-chain storage device; and wherein the data transaction is forwarded to the recipient device on detection by the BMN with which the recipient device is in communication.
  • the metadata may further comprise a data identifier of the data object, and a transaction type.
  • the user ID is a user ID of the off-chain storage
  • the transaction type is indicative of a data upload transaction, or a data access authorization transaction
  • the user ID is a user ID of the off-chain storage
  • the transaction type is indicative of a data access request transaction
  • the user ID is a user ID of a client that uploaded the data object to the off-chain storage
  • the transaction type is indicative of a data access confirmation transaction
  • the user ID is a user ID of a client device that requested access to the data object.
  • the method of the fourth aspect may comprise controlling access to an encrypted data object uploaded by the client device to the off-chain storage.
  • it may comprise controlling access by an attribute-based encryption scheme, such as a proxy- assisted attribute-based encryption scheme.
  • the method may comprise, on receiving a data access request message for the encrypted data object from a requesting device of said one or more other client devices, the client device: applying an access control policy to approve or reject the request; on approval, generating a proxy key for the requesting device; encrypting the proxy key; and transmitting, to the BMN with which the client device is in communication, a request to publish a data access authorization transaction to the blockchain network, the data access authorization transaction comprising a user ID of the off-chain storage, a data identifier of the encrypted data object, the public key of the requesting device, and the encrypted proxy key.
  • the present disclosure provides a non-transitory computer-readable storage medium having stored thereon instructions for causing at least one processor to perform a method as disclosed herein.
  • Figure 1 shows an overview of a blockchain-based access control and data sharing system according to certain embodiments
  • FIG. 2 is a flowchart of an example transaction flow in the system of Figure 1;
  • Figure 3 shows an example data structure for a transaction message in an example method and system
  • Figure 4 shows an exemplary block structure for a blockchain in certain embodiments; and Figure 5 depicts a hierarchical data sharing and access control system according to certain embodiments.
  • the present disclosure relates to a blockchain-based access control and data sharing framework (for example, for supply chains).
  • the data shared among the stakeholders are encrypted under attribute- based encryption (ABE) and stored on the cloud, while the proof of data upload, access request, access authorization, and access confirmation are stored on a permissioned blockchain.
  • ABE attribute- based encryption
  • the involved parties may use a permissioned blockchain. Since a hash of the shared data is recorded in the blockchain once the data is uploaded to the cloud, any tampering which will result in the change of the data hash will be detected. Hence, embodiments of the present disclosure ensure the integrity and authenticity of the shared data.
  • the usage of blockchain also enables the auditability and traceability of the data sharing operations. This is because all access and update operations for the shared data are recorded in the blockchain.
  • the records of the operations on the data can also be used to evaluate a certain party's behavior for the purpose of building trust. Meanwhile, since only the hash of the data rather than the actual data to be shared is recorded in the blockchain, embodiments of the present disclosure also ensure scalability.
  • Figure 1 shows an example architecture of a system 100 for data exchange via a blockchain network 101.
  • the blockchain network 101 comprises a plurality of nodes 106A, 106B, 106C, 106D, 108, and 110, the functions of which will be described in further detail below. Six nodes are shown in Figure 1, but it will be appreciated that in many practical implementations, many more nodes than this may form the blockchain network 101.
  • the system 100 enables exchange of data between client devices 104A, 104B and 104C (only four of which are shown, but again, in practice many such devices may exchange data in the system 100), via off-chain storage 102, intermediated by the blockchain network 101.
  • the off-chain storage 102 may be or may comprise a cloud storage system, for example.
  • Each of the client devices 104A, 104B, 104C may be a single computing device with the ability to connect to one or more other computing devices via a network, such as a local area network or a wide area network such as the Internet.
  • one or more client devices may form part of a corporate network.
  • client devices 104A are part of a corporate network of Company A
  • client device 104B is part of a corporate network of Company B.
  • Company A and Company B may exchange data with each other by the client devices 104A and 104B submitting data transaction requests via the blockchain.
  • Company A and Company B may be entities in a supply chain.
  • the blockchain is used to record evidence of data storage (i.e., upload to the storage system 102), data access, and data update operations.
  • the blockchain nodes 106A-D, 108, 110 could be deployed and owned by the companies involved in the supply chain or by authorized third parties.
  • the blockchain nodes comprise a plurality of Broadcast and Monitor Nodes (BMNs) 106A- 106D.
  • a BMN is able to generate and broadcast transactions on the blockchain. These nodes can also monitor the broadcast of transactions, which means that these nodes can receive all the transactions broadcast in the blockchain.
  • All parties that wish to share data with others e.g., Company A and Company B in Figure 1), as well as the off-chain storage 102, are connected to one of the BMNs.
  • client devices 104A of Company A are connected to BMN 106A
  • client device 104B of Company B is connected to BMN 106B
  • client device 104C is connected to BMN 106C
  • off-chain storage 102 is connected to BMN 106D.
  • Each BMN 106A-D may store a list of identifiers of users that are permitted to access the blockchain via BMN 106A-D.
  • BMN 106A may store identifiers of client devices 104A, such that any transaction in the blockchain that is associated with an identifier of one of the client devices 104A may be detected and forwarded to the corresponding client device 104A for processing.
  • Each data transfer event between a pair of client devices (e.g. 104A and 104B) in the system 100 is intermediated by the client devices and the off-chain storage 102 causing one or more data transaction messages to be published to the blockchain via the respective BMNs with which they are in communication.
  • data transaction messages do not include the actual data that is to be shared between the client devices. Instead, the actual data is uploaded by one client device, for example 104A, to off-chain storage 102, and a data upload transaction is published to the blockchain.
  • the data upload transaction contains (among other things) only a hash of the actual data such that a downloader of the actual data from the off-chain storage 102 can verify that the data have not been tampered with.
  • a data access request transaction may be published to the blockchain by another client device 104B, via the BMN 106B to which client device 104B is connected. This is detected by the BMN 106A connected to client device 104A (which is the data owner and the entity that uploaded the data to off-chain storage 102) and passed to an access controller 120A in communication with client device 104A. If access is approved, for example based on an access control policy, then a data access authorization transaction is published to the blockchain. This is detected by the BMN 106D connected to off-chain storage 102.
  • Off-chain storage 102 then generates and publishes a data access confirmation transaction to the blockchain, via the BMN 106D. This is detected by the BMN 106B connected to client device 104B. Client device 104B may then access the data stored at off-chain storage 102, and send the completed transaction to its BMN 106B for recordal in the blockchain.
  • the blockchain nodes may also comprise one or more Mining Nodes (MNs).
  • MNs Mining Nodes
  • a MN is able to generate blocks by collecting a certain number of valid transactions broadcast in a given time window.
  • a MN may only perform mining (i.e., it does not generate and broadcast transactions).
  • a MN may also function as a BMN and vice versa.
  • MN 108 shown in Figure 1 may also be capable of acting as a BMN, and one or more of the BMNs 106A-106D may also act as MNs.
  • the blockchain nodes may also comprise one or more Monitor-Only Nodes (MONs), such as MON 110.
  • MONs Monitor-Only Nodes
  • a MON 110 is able to monitor the blocks and transactions broadcast in the blockchain, but it cannot generate and broadcast transactions or blocks on the blockchain. Compared to MNs and BMNs, MONs require fewer computation resources.
  • MONs can be configured to allow access to the blockchain via resource-limited devices, so a company or an individual that is able to access the blockchain (whether it is a public or permissioned blockchain) could access the on-chain data through lightweight devices.
  • a MON 110 may access the blockchain and detect transactions targeted to a device to which the MON 110 is connected, maintaining a list of such devices as for a BMN as described above.
  • each entity wishing to share data in the system 100 should connect to a BMN.
  • a BMN can be responsible for more than one company which means that several companies could connect to the same BMN.
  • the number of companies that are connected to one BMN can be decided based on specific system requirements.
  • one BMN is responsible for each company as an example, e.g., Company A and Company B in Figure 1. Based on simple extensions, one BMN could be easily implemented as broadcasting and monitoring transactions for several companies.
  • the off-chain storage 102 is also connected to a BMN 106D.
  • all the shared data are encrypted and stored in the cloud.
  • client devices 104A-C are deployed to upload encrypted data and download partially decrypted data from the cloud 102.
  • the client devices 104A-C are the devices that upload the encrypted data into the cloud. Then encryption of the data could be performed by the client devices 104A-C, or by other devices (located within a corporate network of Company A or Company B, for example) and then transferred to the client devices 104A-C for uploading.
  • the access control entity 120A, 120B deployed in a company receives inter-company access requests and performs access control for the encrypted data kept in the cloud 102 based on an access control policy.
  • All the operations on the shared data are recorded in the blockchain.
  • four different operations relating to data transfer events may be recorded in the blockchain, as detailed below, and each kind of operation corresponds to a certain kind of blockchain transaction.
  • the operations that could be recorded in the blockchain are not limited to these four types. For different application scenarios, more types of operations could be supported in the system 100.
  • ABE attribute-based encryption
  • Data upload The owner of the shared data (e.g. Company A) first encrypts the data using the attribute-based encryption algorithm. Then, the client devices (e.g. client device 104A) deployed in the data owner's system upload the encrypted data into the cloud 102. Once the data owner uploads the data into the cloud 102, its connected BMN 106A generates and publishes a data upload transaction into the blockchain. The hash of the plaintext data is included in the data upload transaction. Every time the data owner updates the stored data, it may be required to publish a corresponding data upload transaction that contains the updated data hash. This ensures that the data owner cannot tamper with the stored data without being detected.
  • the hash of the plaintext data is included in the data upload transaction. Every time the data owner updates the stored data, it may be required to publish a corresponding data upload transaction that contains the updated data hash. This ensures that the data owner cannot tamper with the stored data without being detected.
  • Data access request The access control entity 120A deployed in the company that owns the data (i.e., data owner) performs access control of the encrypted data kept in the cloud 102.
  • a company e.g. Company B
  • BMN 106B for example, via client device 104B
  • the BMN 106A connected to the data owner company will receive the data access request transaction and send the access request to the access control entity 120A of the data owner.
  • the access control entity 120A decides if the request should be approved or rejected based on an access control policy.
  • Data access authorization If a data access request is approved, the access control entity 120A generates the proxy key for the requesting company. The proxy key is encrypted and sent to the BMN 106A connected with the data owner. Then, the BMN 106A generates a data access authorization transaction that contains the encrypted proxy key and publishes the transaction into the blockchain.
  • the proxy key could be encrypted by a shared key between the cloud service provider 102 and the data owner, or by a public key of the cloud service provider 102.
  • the public key could be the cloud service provider's public key for blockchain transactions, the cloud service provider's public key for the cloud data partial decryption, or a public key of a key pair that is dedicated for the proxy key encryption.
  • the cloud service provider's public key can be used for blockchain transactions to encrypt the proxy key as an example.
  • the method to encrypt the proxy key is typically based on negotiation between the data owner and the cloud service provider, and hence could be different in different implementations.
  • the cloud service provider 102 uses the proxy key and the cloud service provider's private key to partially decrypt the encrypted data.
  • intermediate data will be generated.
  • the authorized data requestor e.g. client device 104B
  • the BMN 106D connected to the cloud service provider After generating the intermediate data, the BMN 106D connected to the cloud service provider generates a data access confirmation transaction that requires the data requestor's signature and publishes this transaction to the blockchain.
  • the data requestor e.g. client device 104B
  • the cloud service provider's public key is not required for encrypting the data.
  • the cloud service provider's public key is only required to encrypt the proxy key.
  • the cloud service provider sends its public key to the data owner for recordal in advance.
  • the data owner uses the recorded public key of the cloud service provider in future proxy key generation and encryption unless the public key is updated/changed based on negotiation between the cloud service provider and the data owner.
  • the involvement of the cloud service provider's private key for partial data decryption is to prevent a dishonest cloud service provider from disclosing a user's (i.e., data requestor's) cloud-side proxy key to other parties, or colluding with the user.
  • the cloud service provider Unless the cloud service provider is willing to disclose its own private key, it will not collude with a malicious party to disclose other parties' proxy keys or collude with the user.
  • the cloud service provider should always use the same key pairs for the partial decryption of the same data.
  • the transfer of the public key can also be recorded in the blockchain, however, for simplicity, in the discussion below, it is assumed that the data owner uses the same public key of the cloud service provider for all data it keeps in the cloud. Hence, in the description below, the transfer of the public key is not recorded in the blockchain, though it is possible for this to be done in certain embodiments.
  • Each operation comprises a blockchain transaction involving a sender that initiates the operation, and a recipient that is the target of the operation.
  • the outcome of the operation depends on the content of the transaction, for example a transaction type that is encoded in metadata of the transaction.
  • An example transaction data structure is shown in Figure 3.
  • the fields of the transaction data may comprise the following:
  • the first field is an identifier for the transaction.
  • the transaction ID could be a transaction hash ID which is generated by hashing transaction information.
  • a standard hash function such as SHA3 could be applied to certain sub-fields, e.g., (Previous transaction ID of the sender 11 sender's public key 11 sender's signature 11 Metadata), and the hash result may be used as the transaction ID.
  • Previous transaction ID of the sender The second field is a pointer to the previous transaction of the sender.
  • the function of this sub-field is to chain all transactions created by a sender together.
  • the chained record could be used to audit and trace the sender's behavior.
  • the "previous transaction of the sender” refers to the action that is immediately preceding the current one (it is assumed that the possibility of simultaneous actions is very unlikely).
  • Sender's public kev contains the public key of the sender which could be used to verify the next sub-field Sender's signature.
  • the sender of a transaction is the party that initiates the transaction.
  • the public-private key pair for generating the sender's signature could always remain the same and its public key could serve as the unique user identifier (which may then be stored by respective BMNs 106A- D and MON 110, for example).
  • the public-private key pair for generating the sender's signature for a transaction could be unique to the transaction.
  • a sub-field may be added to the structure shown in Figure 3 to indicate the public key that the sender will use for the next transaction.
  • Sender's signature this sub-field is the sender's signature on the transaction which is used to ensure the integrity and the authenticity of the transaction.
  • a standard digital signature scheme DS (DS_Sign, DS_Verify) is used for generating and verifying the sender's signature.
  • Each sender generates its own DS public-private key pair (pk, sk), and the pk is recorded in the previous sub-field Sender's public key.
  • the sender generates a signature on the transaction with the private key sk as follows:
  • Any party can verify the sender's signature sig with the sender's public key pk recorded in the previous sub-field using DS_Verify(Sig_s, pk).
  • the specific digital signature algorithm could be different and be decided based on the specific requirements of the system implementer, as will be understood by those skilled in the art.
  • Metadata this sub-field contains operation-specific information corresponding to the transaction. Specifically, it may contain four fields: Data identifier, Transaction type, User ID of the recipient, and Action info. • Data identifier is the reference to the data associated with the transaction (i.e., the target data of the operation associated with this transaction). The data identifier may be generated based on any suitable method known in the art.
  • Transaction type indicates the type of operation associated with the transaction.
  • the transaction type may take one of at least the following values: data upload, data access request , data access authorization, and data access confirmation. In different implementations, further transaction types could be defined and supported.
  • each party for example, participating companies (such as Company A and Company B in Figure 1, or one or more client devices thereof) and the cloud service provider 102, has its own user ID as a unique identity, and the user ID of a party is broadcast and recorded by other parties as soon as that party joins the system 100.
  • This field indicates the User ID of the recipient.
  • Each BMN maintains a list that records the user IDs of its connected companies (and/or of client devices 104A, 104B thereof). Once a transaction is broadcast to the whole blockchain network, each BMN checks the value of User ID of the recipient in the received transaction. If a BMN matches the recipient to a connected company (or a client device thereof), the BMN forwards the transaction to the recipient for further processing.
  • Action info is information related to the operation/action associated with this transaction. The different values of Action info in different types of transactions are detailed later.
  • this sub-field contains the public key of the recipient, this being used to verify the next sub-field Recipient's signature.
  • the recipient of a transaction is the party that the sender of the transaction needs to communicate with.
  • the public-private key pair for generating the recipient's signature could be the same key pair that it uses to generate the sender's signature when it works as the sender of transactions. The usage of the same key pairs reduces the key management burden.
  • this sub-field is the recipient's signature on the transaction which is used to ensure the integrity and the authenticity of the transaction.
  • a standard digital signature scheme DS (DS_Sign, DS_Verify) is used for generating and verifying the signature.
  • the recipient uses the DS public-private key pair (pk, sk) to generate a signature Sig_r on the transaction, and the pk is recorded in the previous subfield Recipient's public key.
  • Any party can verify Sig_r with the recipient's public key pk recorded in the previous sub- field using DS_Verify(Sig_r, pk). Any suitable digital signature algorithm known in the art may be used.
  • Output this sub-field is populated by the recipient of a transaction indicating the result of the data upload/access operation associated with this transaction.
  • the different values of Output in different types of transactions are detailed later.
  • the sender may initiate the transaction, and this may comprise performing one or more off-chain operations.
  • the sender is a client device (e.g. client device 104A) wishing to upload a data object
  • the recipient is the off-chain storage 102 to which the data object is to be uploaded.
  • Step 202 may then comprise the client device 104A, or another device in communication with client device 104A, encrypting the data object (for example, according to an attribute- based encryption algorithm) and uploading the encrypted data object to the off-chain storage 102.
  • the data identifier for the data object is also generated by the sender at this point so that it can be inserted in the transaction sent to the blockchain (and subsequently used by the cloud service 102 to match against what is uploaded by the sender, and against requests made by other parties).
  • the sender may sign the transaction.
  • the sender may transmit the transaction to the BMN to which it is connected.
  • client device 104A may sign and transmit a data upload transaction to BMN 106A.
  • the data upload transaction comprises the fields shown in Figure 3, including a transaction ID, and a previous transaction ID of the data owner (if any).
  • the transaction type is "data upload transaction”
  • the action info comprises a hash of the (unencrypted) data object. Note that the transaction does not include the data object (either in encrypted or plaintext form) itself, but only the hash of the data object.
  • the hash of the plaintext data ensures the integrity and authenticity of the data kept in the cloud.
  • the pointer to the previous data upload transaction with the same data identifier chains all the updates on a particular data object together.
  • the BMN 106A broadcasts the transaction to the network.
  • the BMN of the recipient can detect that there is a transaction intended for the recipient, based on the user ID of the recipient in the metadata of the transaction.
  • BMN 106D connected to the cloud service provider (off-chain storage) 102 detects the user ID of the cloud service provider 102, and forwards the transaction to the cloud service provider 102, at step 212.
  • the recipient in this case the cloud service provider 102, takes action based on the content of the transaction.
  • the cloud service provider 102 populates the output of the transaction.
  • the output may comprise an Upload Tag and a Timestamp ⁇ .
  • ⁇ Upload Tag indicates the result of the data upload operation. It could be assigned with two different values 0 and 1. If the encrypted data has been uploaded to the cloud successfully, the cloud service provider 102 sets the Upload Tag as 1. Otherwise, if the upload is unsuccessful, the Upload Tag is set as 0.
  • Timestamp is used to store the time when the cloud service provider 102 signs on the transaction. This value is involved in the generation of the recipient's signature. Flence, it could prevent replay attacks where a malicious attacker replays a signature which is previously generated by the cloud service provider 102 for another transaction.
  • the cloud service provider 102 signs on the output (together with other data as mentioned above, such as the transaction ID, the sender's public key and signature, and so on).
  • the cloud service provider 102 sends the completed transaction (with the result of the signature inserted in the recipient's signature field of the transaction, and the output in the output field) to its BMN 106D.
  • the cloud service provider's BMN 106D then broadcasts the completed transaction to be recorded in the blockchain.
  • the transaction is verified (by mining nodes of the blockchain network, such as MN 110, or by BMNs 106A-106D acting as mining nodes, for example) and added to the blockchain.
  • participants in the system 100 may participate in a data access request transaction.
  • the sender is the data requestor, i.e., the company (or other entity) that requests to access the shared data kept in the cloud
  • the recipient is the data owner.
  • the data requestor is Company B, and wishes to access data uploaded to the cloud 102 by Company A.
  • the data requestor 104B initiates the transaction by generating a data access request transaction.
  • the data access request transaction is populated with a transaction ID, the previous transaction ID of the requestor, the public key of the requestor, the signature of the requestor on the transaction, and metadata.
  • the metadata comprises a data identifier of the data that is being requested, a transaction type indicator (in this case, "data access request transaction"), the user ID of the data owner 104A, and action info.
  • the action info may comprise an ABE public key of the requestor, which may also be used as the user ID.
  • the ABE public key is to be used for data decryption (i.e., it is a public key of the public-private key pairs associated with an ABE decryption algorithm for decrypting the shared data).
  • the data requestor 104B signs and at step 206 sends the data access request transaction to its BMN 106B.
  • the BMN 106B of the requestor 104B broadcasts the transaction to the network.
  • the BMN 106A of the data owner 104A can detect that there is a transaction intended for the data owner 104A, based on the user ID of the data owner 104A in the metadata of the transaction. BMN 106A then forwards the transaction to the data owner 104A, at step 212.
  • the data owner 104A takes action based on the content of the transaction.
  • an access controller 120A of the data owner 104A decides if the request should be approved or rejected based on the data requestor's 104B attributes.
  • the allocation and verification of the requestor's attributes may be performed in any suitable manner.
  • the data owner 104A populates the output field of the transaction, at step 216.
  • the Output of a data access request transaction contains an Authorization Tag and a Timestamp.
  • ⁇ Authorization Tag indicates the result of the data access authorization. It could be assigned with two different values 0 and 1. If the data owner 104A approves the request, the data owner 104A sets the Authorization Tag as 1. Otherwise, if the request is rejected, the Authorization Tag is set as 0.
  • Timestamp is used to store the time when the data owner 104A signs on the transaction.
  • the timestamp could prevent replay attacks where a malicious attacker replays a signature which is previously generated by the data owner 104A for other transactions.
  • the data owner 104A also signs the output of the transaction, and inserts the signature in the recipient signature field.
  • the completed transaction is sent by the data owner 104A to its BMN 106A.
  • the data owner's BMN 106A then broadcasts the completed transaction at step 220, to be recorded in the blockchain (step 222).
  • the data requestor's BMN 106B keeps monitoring for the data access request transaction until it receives the completed transaction. Then, the BMN 106B forwards the completed transaction to the data requestor 104B to enable it be aware of the result of the request.
  • a data owner 104A After a data owner 104A approves a data access request, it may initiate a data access authorization transaction.
  • the data owner 104A is the sender of the transaction, and the cloud service provider 102 is the recipient.
  • the purpose of the data access authorization transaction is to notify the cloud service provider 102 that the data access requestor 104B is authorized to access the stored data object, and in at least some embodiments, to provide the cloud service provider with a proxy key for a proxy-assisted ABE algorithm.
  • the data owner 104A After the data owner 104A has approved a data access request and signed on the data access request transaction, it generates and encrypts the proxy key for the data requestor 104B and sends the encrypted proxy key to the cloud service provider 102 via a data access authorization transaction.
  • the data access authorization transaction is designed for recording the transfer of the proxy key.
  • the data owner 104A initiates the data access authorization transaction by generating a transaction message.
  • the transaction message is populated with a transaction ID, the previous transaction ID for the data owner, the public key of the data owner, the signature of the data owner on the transaction, and metadata.
  • the metadata comprises the data identifier of the data that is being requested, a transaction type indicator (in this case, "data access authorization transaction"), the user ID of the cloud service provider 102, and action info.
  • the action info comprises the ABE public key of the requestor 104B.
  • the action info also comprises the encrypted proxy key.
  • the proxy key could be encrypted using the cloud service provider's public key, or a shared key that is previously shared between the data owner 104A and the cloud service provider 102.
  • this public key used to encrypt the proxy key could be the cloud service provider's public key for blockchain transactions (i.e., recipient's public key contained in the transaction) or the public key of a dedicated public-private key pair.
  • the data owner 104A signs and at step 206 sends the data access authorization transaction to its BMN 106A.
  • the BMN 106A of the data owner 104A broadcasts the transaction to the network.
  • the BMN 106D of the cloud service provider 102 can detect that there is a transaction intended for the cloud service provider 102, based on the user ID of the cloud service provider 102 in the metadata of the transaction. BMN 106D then forwards the transaction to the cloud service provider 102, at step 212.
  • the cloud service provider 102 takes action based on the content of the transaction.
  • the cloud service provider 102 retrieves the encrypted proxy key of the data requestor 104B from the action info in the data access authorization transaction, decrypts it, and stores the proxy key for subsequent use in partial decryption of the requested data object (the requested data object being associated with the data identifier in the transaction metadata).
  • the cloud service provider 102 populates the output field of the transaction.
  • the Output of a data access authorization transaction contains an Update Tag and a Timestamp.
  • Update Tag indicates the result of the proxy key transfer. It could be assigned with two different values 0 and 1. If the encrypted proxy key has been decrypted and recorded by the cloud service provider 102 successfully, the cloud service provider sets the Update Tag as 1. Otherwise, if the proxy key is not received successfully, the Update Tag is set as 0. Timestamp is used to store the time when the cloud service provider 102 signs on the transaction. The timestamp could prevent replay attacks where a malicious attacker replays a signature which is previously generated by the cloud service provider 102 for other transactions.
  • the cloud service provider 102 signs the output of the transaction, and inserts the signature in the recipient signature field.
  • the completed transaction is sent by the cloud service provider 102 to its BMN 106D.
  • the cloud service provider's BMN 106D then broadcasts the completed transaction at step 220, to be recorded in the blockchain (step 222).
  • the data requestor's BMN 106B keeps monitoring for the data access authorization transaction containing the data requestor's ABE public key in the action info field until it receives the completed transaction. Then, the BMN 106B forwards the completed transaction to the data requestor 104B to update the data requestor 104B on the proxy key transfer procedure.
  • a data access confirmation transaction may be performed.
  • This type of transaction involves the data requestor 104B obtaining intermediate data from the cloud service provider 102 and accessing the plaintext of the shared data by decrypting the intermediate data with its private key. It is assumed that the cloud service provider 102 shares the intermediate data with the data requestor via out-of-band channel. The sender of such a transaction is the cloud service provider 102, and the recipient is the data requestor 104B.
  • the cloud service provider 102 initiates the transaction by generating a data access confirmation transaction message.
  • the transaction message is populated with a transaction ID, the previous transaction ID for the cloud service provider, the public key of the cloud service provider 102, the signature of the cloud service provider 102 on the transaction, and metadata.
  • the metadata comprises the data identifier of the data that is being requested, a transaction type indicator (in this case, "data access confirmation transaction"), the user ID of the data requestor 104B, and action info.
  • the action info comprises the hash of the intermediate data obtained by the cloud service provider 102 by partially decrypting the encrypted data object using the proxy key and the cloud service provider's private key. Note that only the hash of the intermediate data, and not the intermediate data itself, is sent as part of the transaction; as such, only the hash is recorded on the blockchain.
  • the cloud service provider 102 sends the intermediate data to the data requestor 104B. And cloud service provider 102 also initiates the data access confirmation transaction by generating a transaction message.
  • the cloud service provider 102 signs and at step 206 sends the data access confirmation transaction message to its BMN 106D.
  • the BMN 106D of the cloud service provider 102 broadcasts the transaction to the whole network.
  • the BMN 106B of the data requestor 104B detects the user ID of the data requestor 104B in the User ID of the Recipient field of the transaction, and thus forwards (at step 212) this transaction to the data requestor 104B.
  • the data requestor 104B takes action based on the content of the transaction.
  • the data requestor 104B uses its ABE private key to decrypt the intermediate data to obtain the plaintext data.
  • the data requestor 104B may also perform other operations, such as computing a hash of the received intermediate data (received out-of- band from the cloud service provider 102) and comparing it to the hash in the action info field of the transaction for verification purposes.
  • the data requestor 104B populates the output field of the transaction.
  • the Output of a data access confirmation transaction contains a Hash Value and a Timestamp.
  • Hash Value is the hash of the plaintext shared data.
  • the data requestor 104B calculates the hash of the plaintext shared data after decrypting the intermediate data with its private key. The hash recorded in this field could be used as the evidence of the data owner's 104A behaviour. If the hash value is identical with the hash value recorded in the data upload transaction, it proves that the data owner 104A has not tampered with the data kept in the cloud 102.
  • Timestamp is used to store the time when the data requestor 104B signs on the transaction. This value is involved in the generation of the recipient's signature. Hence, it could prevent replay attacks where a malicious attacker replays a signature which is previously generated by the data requestor for another transaction.
  • the data requestor 104B also signs the output of the transaction, and inserts the signature in the recipient signature field.
  • the data requestor 104B sends the completed transaction to its BMN 106B.
  • the data requestor's BMN 106B then broadcasts the completed transaction to be recorded in the blockchain at step 220, and the transaction is verified and added to the blockchain at step 222.
  • Figure 4 shows an example structure of a block in the blockchain.
  • Each block contains the following fields: block ID, previous block ID, timestamp, transaction details, block generator's public key and signature, and miners' public keys and signatures.
  • Block ID this field contains the identifier of the block.
  • the block ID is the block hash ID which is generated by hashing the main fields of a block with a standard hash function.
  • SHA3 may be selected as the hash function and SHA3 ⁇ Previous block ID
  • transaction details may be used as the block ID.
  • Previous Block ID this field contains the previous block ID and thus chains the blocks together.
  • the previous block ID is the hash of the previous block. It ensures immutability to include the hash of the previous block in the current block. If an attacker tries to tamper with a transaction that is previously stored in an existing block, the hash of the corresponding block will not be consistent with the hash stored in the next block. Hence, the attack will be detected.
  • Timestamp this field contains the time that the block is generated. It is included in the generation of signatures on the block to prevent replay attacks.
  • this field records all the transactions that have occurred over a given period of time.
  • the block generator i.e., the mining node, such as one of mining nodes 110 and/or BMNs 106A-D, that generates the block
  • the verification of a transaction will be described below.
  • a block can store at most T transactions. The value of T affects the blockchain throughput.
  • Block generator's public kev and signature this field records the block generator's digital signature on the main fields of the block (i.e., Sig g) and the corresponding public key (i.e., pk_g) that could be used to verify the signature.
  • Miners' public kev and signature this field is included due to the usage of Practical Byzantine Fault Tolerance (PBFT) algorithm as an example consensus algorithm (see details below). In implementations that use other consensus algorithms, this field could be changed to record the consensus evidence corresponding to the consensus algorithm in use. In the case of using a PBFT algorithm, this field contains the signatures generated by a number of miners (i.e., mining nodes such as MNs 110 and/or BMNs 106A-D) that have verified the block as valid and used the corresponding public keys to verify the generated signatures.
  • PBFT Practical Byzantine Fault Tolerance
  • N is the total number of miners that are required for verification of a block. The value of N is defined by the actual consensus algorithm in use.
  • a block generator must verify the transactions before aggregating these transactions to form a block. To verify an individual transaction, the block generator first verifies the sender's signature contained in the transaction using the sender's public key contained in the corresponding field. Then, the block generator verifies the recipient's signature contained in the transaction using the recipient's public key contained in the corresponding field. Only if both the sender's signature and the recipient's signature are verified as valid will the transaction be considered valid.
  • the block generator can only include valid transactions into a block, which means that the block generator needs to verify each transaction before aggregating it into a block. After all the aggregated transactions are verified as valid, the block generator generates the block ID, forms the block, and signs on the block. In the implementations that use a PBFT consensus algorithm, only if the newly created block is verified and confirmed by the designated set of miners can it be regarded as confirmed and valid.
  • a miner (such as MN 110 and/or one of BMNs 106A-D) first verifies all the transactions contained in the block using the aforementioned method (i.e., verifying the sender's signature and the recipient's signature for each individual transaction). Then, it verifies the block generator's signature on the block using the corresponding public key. If all the transactions are verified as valid and the block generator's signature is verified as valid, the miner will sign on the block.
  • the consensus algorithm is the fundamental security principle for a blockchain. It ensures that a common, unambiguous and unique order of transactions and blocks is accepted by all involved parties. It also guarantees the integrity and consistency of the blockchain across geographically distributed nodes. Different blockchains could use different consensus algorithms, and there are a large number of different consensus algorithms available due to the development of blockchain technology. For example, Bitcoin uses a proof-of-work (POW) consensus protocol while Ethereum may use a proof-of-stake (POS) consensus protocol. These two consensus algorithms require high computation resources and result in a relatively longer latency for transaction confirmation.
  • POW proof-of-work
  • POS proof-of-stake
  • the consensus algorithm could be decided case by case.
  • all supporting parties of a permissioned blockchain could negotiate and agree on a certain consensus algorithm.
  • complex consensus algorithms e.g, POW, POS
  • POW, POS complex consensus algorithms
  • other consensus algorithms that are more lightweight and faster could be applied. Latency might be very important to most data sharing systems for time-critical environments such as supply chains.
  • PBFT Practical Byzantine Fault Tolerance Algorithm
  • PBFT Practical Byzantine Fault Tolerance
  • the security principle of a PBFT system is that the number of malicious nodes must not equal or exceed one-third of all nodes in the system in a given vulnerability window. All honest nodes will come to an agreement on the state of the system using a majority rule. Similar to the POW consensus mechanism, the more nodes involved in a PBFT network, the more secure it becomes.
  • a node receives a request of validating a new block, it responds by signing on the validation result. Once enough responses that prove this block as valid are received, a consensus is reached.
  • node When other blockchain node (i.e., neither miner node nor block generator) receives the new approved block, it must validate the new block following the standard validation process required by the blockchain platform in use prior to appending it to the blockchain. For example, to validate a block, the node validates the signature of the block generator and signatures of the miners that confirms the block. If these signatures are verified as valid, the block is considered to be valid and appended to the blockchain.
  • the data sharing system and method described above which has been described in an inter-company context, may be adapted to intra-company data sharing.
  • a local blockchain 501 may be deployed within a Company A to record evidence of intra-company access control and data sharing.
  • reference numerals identical to those in Figure 1 refer to identical components.
  • Master devices 504A, 504B and local data sharing storage 502 connect to the local blockchain 501 and publish transactions on the local blockchain 501, in a manner analogous to the client devices 104A, 104B and cloud service provider 102 in Figure 1.
  • the functions of master devices, local data sharing storage, and the client device will be described below.
  • the local storage 502 that is connected to the local blockchain 501 works as temporary storage for the data that needs to be uploaded to the cloud 102 as well as for the intermediate data downloaded from the cloud 102 (such intermediate data then being sent to a master device). In other embodiments, the local storage 502 may be used only for temporary storage of data for upload, while intermediate data may be downloaded directly from the cloud 102 by a master device.
  • All the data that needs to be uploaded to the cloud 102 are uploaded to the local data sharing storage 502 first, and may be uploaded to the cloud 102 periodically to avoid frequent data upload transactions being published on the inter-company blockchain 101.
  • the period for uploading the data from the local storage 502 to cloud storage 102 could be decided based on actual system requirements. In addition, different types of data could be assigned with different upload periods.
  • the client device 104A is responsible for uploading data to and downloading data from the cloud 102.
  • the local storage 502 works analogously to the cloud storage 502 in the inter-company scenario of Figure 1. It means that the local storage 502 stores the encrypted data received from master devices 504A, 504B (only two of which are shown, though it will be appreciated that many more than two master devices may be present in some embodiments), and generates the intermediate data for a requesting device that is authorized to access the data.
  • a master device 504A, 504B is a device that manages the data upload for a number of devices (e.g. Devices A, B, ...N associated with master device 504A) which generates data and shares data with other devices and access control for devices associated with master device 504A and other master devices.
  • the master device 504A, 504B manages and performs the access control policy, and an access controller 520A, 520B is deployed for the master device 504A, 504B to perform the access control.
  • the master device 504A, 504B encrypts and uploads data generated by these associated devices to the cloud, and also receives and decrypts the intermediate data that are requested by these devices.
  • Access requests for the data generated by a device are sent to the master device 504A, 504B.
  • a master device 504A receives data access requests from the devices (A, B, ..., N) under its management and sends the data access requests to other master devices 504B.
  • the master device 504A generates and monitors blockchain transactions for the devices under its management.
  • a master device 504A, 504B could work as a blockchain node, or may connect to a dedicated blockchain node device.
  • the structure of the transactions is similar to that described above.
  • Each master device is assigned with a blockchain user ID and has its own private-public key pairs to generate blockchain transactions, as well as the local data sharing storage.
  • the senders and recipients of the transactions are the master devices and the local data sharing storage.
  • the transaction flow in the intra-company scenario is as follows:
  • Master device 504A generates a data upload transaction and broadcasts it on the blockchain 501 once a device managed by it needs to upload data to the cloud 102. For a device managed by a master device 504A, once it needs to upload data to the cloud 102, it first sends the data to the master device 504A. The master device 504A encrypts the received data using an ABE encryption algorithm and uploads the encrypted data to the local storage 502. In some embodiments, all the data that needs to be uploaded to the cloud 102 are uploaded to the local storage 502 first. Then, the master device 504A generates and broadcasts a data upload transaction on the local blockchain 501, and the local storage 502 then signs on the transaction to confirm the status of the data upload to publish in the local blockchain 501.
  • the private-public key pairs of the cloud are generated by the cloud service provider 102.
  • the private-public key pairs of the local storage 502 to partially decrypt certain data are generated by the master device 504A that encrypts and uploads these data, and then sent to the local storage 502 via an out-of-band secure channel.
  • the master device 504A could generate a private-public key pair of the local storage 502 for all the data sent by itself, or generate different key pairs for different data. Since the master device 504A could access the plaintext of the data and manage the access control of the data, it would not bring additional security risk of data disclosure to let the master device 504A generate the private-public key pairs of the local storage 502.
  • the intra-company scenario only considers the data sharing among devices that are managed by different master devices 504A and 504B.
  • the data sharing among the devices managed by the same master device is controlled by their master device 504A and should not be recorded in the local blockchain 501. Sharing of data between devices managed by the same master device may be configured in any suitable manner, as will be appreciated by those skilled in the art.
  • a device associated with master device 504B needs to access data from another device associated with master device 504A, it first sends the data request to its master device 504B.
  • the master device 504B then generates the data access request transaction and broadcasts it on the local blockchain 501.
  • the master device 504A that performs access control for the requested data then detects the data access request transaction and performs the data access control, via access controller 520A. After a decision is made on the request, the master device 504A that controls the requesting data signs on the data access request transaction and includes the access control decision in the transaction to publish in the local blockchain 501.
  • a master device 504A approves a data access request, it generates a data access authorization transaction that contains the encrypted proxy key and broadcasts the transaction.
  • the local storage 502 Upon detecting of the data access authorization transaction, the local storage 502 records the proxy key for the requesting master device 504B and signs on the data access authorization transaction to publish in the local blockchain 501.
  • the requesting master device 504B could detect the transaction and obtain the status of its proxy key in the transaction. If the proxy key is successfully recorded by the local storage 502, the local storage 502 provides the intermediate data to the requesting device 504B, and it also generates a data access confirmation transaction and broadcasts this transaction. Upon receiving the intermediate data, the requesting master device 504B decrypts the received data with its private key, sends the decrypted data to the requesting device associated with the master device 504B, and signs on the data access confirmation transaction to publish in the local blockchain 501.
  • the block structure for the local blockchain may be the same as that described above.
  • the same verification and consensus algorithms as for the inter-company scenario could be used, or different verification and consensus algorithms could be applied.
  • the intra-company data sharing and access control framework could be integrated with the inter-company framework described above.
  • the shared data could be kept in the local storage 502 and periodically uploaded to the cloud 102. After uploading the data to the cloud 102, the local storage 502 could wipe out all data kept within a given upload period, for the purpose of decreasing the cost of local storage.
  • a master device 504B generates a data access request transaction on the local blockchain 501 to request intra-company data that has been uploaded into the cloud 102
  • the flow of this transaction and the corresponding data access authorization transaction, and data access confirmation transaction may be substantially the same as described above.
  • the local storage 502 instead of partially decrypting the data to generate the intermediate data, the local storage 502 will request the intermediate data from the cloud service provider 102.
  • the request of intermediate data from the cloud 102 for intra-company access will not be recorded in the inter-company blockchain 101.
  • the transactions related to this request are already recorded in the local blockchain 501 deployed for the intra-company scenario.
  • the local blockchain 501 can also be uploaded to the cloud 102 periodically, and the hash of the periodic local blockchain 501 should be recorded in the corresponding data upload transaction that is published on the inter-company blockchain 101.
  • the master devices 504A, 504B could verify the hash of the periodic blockchain 501 recorded in the intercompany blockchain 101. If the hash is identical with its own record, the master device 504A, 504B can delete the periodic blockchain 501 and only store the final hash of this periodic blockchain 501 locally for future verification.
  • an inter-company data access request may be received by the company (e.g. Company A) that owns the data and be routed to the master device (e.g. master device 504A) that controls the access to the data for authorization and proxy key generation.
  • the company e.g. Company A
  • the master device e.g. master device 504A
  • Such intra-company routing is not required to be recorded in the local blockchain 501.
  • there is a dedicated client device 104A that is responsible for receiving the data access request from the inter-company blockchain node 106A, identifying the master device 504A that manages the requested data, and routing the access request to the master device 504A. Then, after the master device 504A makes decisions on the data access request, the decision and the proxy key (if appropriate) are sent to this dedicated client device 104A to generate corresponding inter-company blockchain transactions.
  • a proxy-assisted attribute-based encryption (ABE) scheme as described in Yang et a I . , "Extended Proxy-Assisted Approach: Achieving Revocable Fine- Grained Encryption of Cloud Data", ESORICS 2015: Computer Security -- ESORICS 2015 pp 146-166, may be used to encrypt data uploaded to cloud service provider 102 and/or local storage 502.
  • ABE proxy-assisted attribute-based encryption
  • a proxy-assisted user revocation approach is applied. With the usage of this approach, it is possible to provide fine-grained access control for the shared data and flexible user encryption, and mitigate the risk due to a dishonest cloud server.
  • This approach is an extension of the proxy-assisted ABE approach, so it has the advantages of the proxy-assisted approaches, including immediate user revocation, low overhead for revocation, light computation cost at the user side, and being key escrow-free.
  • An encryption system based on this approach involves three types of entities, namely: data owner (denoted as DO), a set of users, and a cloud server (denoted as CS).
  • DO data owner
  • CS cloud server
  • a security parameter 1 K is the input of this algorithm, and the output is public parameters, params, and a master secret key, msk. DO executes this algorithm to generate the outputs. Below, it is assumed that params is implicit in the input of the rest algorithms unless stated otherwise.
  • UKGen(u) ⁇ ( pku , sku) This is the user key generation algorithm.
  • the input is a user identity, u
  • the output is a pair of public/private keys, ⁇ pku, sku), for u.
  • ⁇ pku, sku is a pair for a standard public key cryptosystem.
  • Each system entity i.e., users and CS
  • PxKGen(msk , pkcs, pku, Au) ⁇ PxKu This is the proxy key generation algorithm.
  • the inputs are msk, the server's public key, pkcs, a user u's public key, pku, and the user's attributes, Au c A, where A denotes the dictionary of descriptive attributes used in the system.
  • the output is a proxy key, PxKu, for u. DO runs this algorithm to generate a proxy key for a user based on the user's attributes.
  • the generated PxKu will be sent to CS and CS will add it as a new entry in its Proxy Key list LPxK, i.e.
  • u may be the public key of a user, which is used as the user ID.
  • Encrypt(m, T ) ⁇ c This algorithm is to encrypt a message, m, and an access tree, T , specifying an access policy. The output is a ciphertext, c, under T. DO runs this algorithm to encrypt data that will be uploaded to CS.
  • PxDec (skcs, PxKu, c) ⁇ v :
  • This is the proxy decryption algorithm taking as input CS's private key, skcs, a user's proxy key, PxKu, and a ciphertext, c.
  • the output is an intermediate value, v.
  • the CS runs this algorithm to partially decrypt an encrypted data requested by a user, u, with the user's proxy key PxKu.
  • UDec(sku , v) ⁇ m This is the user decryption algorithm.
  • the inputs are a user private key, sku, and an intermediate value, v, and the output is a message, m.
  • a user runs this algorithm to finally decrypt the data with the intermediate value returned by CS and his/her private key.
  • Revoke(u, LPxK) ⁇ L'PxK This is the user revocation algorithm that revokes u's decryption capability.
  • the inputs are a user identity, u, and the Proxy Key list, LPxK.
  • the output is an updated Proxy Key list, L'PxK, in which u's proxy key PxKu has been removed.
  • s be an element randomly chosen from a set S.
  • PxDec (sk cs ,PxK u , c): On input sk cs - x cs , and PxK u - (k, k', ⁇ i ⁇ A u : ⁇ k i1 ,k i2 ⁇ ) associating with a set of attributes, A u , and a ciphertext, c - (T, C, C', C", ⁇ l ⁇ L ⁇ . ⁇ C l1 , C l2 ⁇ ) , the algorithm outputs an intermediate value, v if T(A u ) - 1, and otherwise. Specifically, the algorithm is recursive.
  • DecNd n PxK u , c
  • the proxy decryption algorithm computes Finally, it sets
  • UDec(sk u ,v) On input a user private key, sk u - x u , and an intermediate value, the user decryption algorithm computes
  • an interface should be provided to DO for DO to perform the updating in real-time.
  • Embodiments of the present disclosure may have one or more of the following features and/or advantages:
  • the blockchain is used to record the evidence of data upload, data access request, data access authorization, data access confirmation, and data updates operations, which ensures the integrity and authenticity of the shared data as well as the traceability and auditability of the operations on the data.
  • the records of the operations on the data can also be used to evaluate a certain party's behavior for the purpose of building trust.
  • Fine-grained access control is provided on the shared data based on a proxy- assisted ABE scheme which supports flexible user revocation policy.
  • the encrypted data kept in the cloud do not need to be re-encrypted, which decreases the computation cost of a data owner.
  • embodiments are lightweight to the blockchain nodes.
  • An extended framework is provided for intra-company data sharing and access control.
  • the intra-company and inter-company data sharing and access control framework could be integrated to provide hierarchy protection.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention concerne un système d'échange de données par l'intermédiaire d'un réseau à chaîne de blocs comprenant une pluralité de nœuds, au moins certains desdits nœuds étant des nœuds de diffusion et de surveillance (BMN), comprenant une pluralité de clients. Chaque client est en communication avec l'un desdits BMN. Le système comprend un stockage hors chaîne en communication avec la pluralité de clients et avec l'un desdits BMN. Chaque client est configuré pour effectuer des événements de transfert de données comprenant le téléchargement d'un objet de données vers et/ou le téléchargement d'un objet de données à partir du ou des dispositifs de stockage hors chaîne. Chaque événement de transfert de données est intermédié par deux desdits clients, ou l'un desdits clients et le stockage hors chaîne, provoquant la publication d'une ou plusieurs transactions de données sur le réseau blockchain via les BMN respectifs avec lesquels ils sont en communication, lesdites une ou plusieurs transactions de données ne comprenant pas l'objet de données.
PCT/SG2021/050042 2020-01-31 2021-01-29 Échange de données basé sur une chaine de blocs WO2021154157A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
SG10202000875X 2020-01-31
SG10202000875X 2020-01-31

Publications (1)

Publication Number Publication Date
WO2021154157A1 true WO2021154157A1 (fr) 2021-08-05

Family

ID=77080005

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SG2021/050042 WO2021154157A1 (fr) 2020-01-31 2021-01-29 Échange de données basé sur une chaine de blocs

Country Status (1)

Country Link
WO (1) WO2021154157A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113609225A (zh) * 2021-08-09 2021-11-05 北京神州数码方圆科技有限公司 基于did的区块链数据交换方法及系统
CN113992336A (zh) * 2021-12-30 2022-01-28 常州唯实智能物联创新中心有限公司 基于区块链的加密网络离线数据可信交换方法及装置
CN114938278A (zh) * 2022-04-11 2022-08-23 北京邮电大学 一种零信任访问控制方法及装置
CN115604030A (zh) * 2022-11-30 2023-01-13 北京邮电大学（Cn） 数据共享方法、装置、电子设备和存储介质
CN116029370A (zh) * 2023-03-17 2023-04-28 杭州海康威视数字技术股份有限公司 基于区块链的联邦学习的数据共享激励方法、装置及设备

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108923932A (zh) * 2018-07-10 2018-11-30 东北大学 一种去中心化协同验证模型及验证算法
CN109190410A (zh) * 2018-09-26 2019-01-11 华中科技大学 一种云存储环境下的基于区块链的日志行为审计方法
CN110033243A (zh) * 2019-03-06 2019-07-19 华南师范大学 基于区块链智能合约的主链存证方法、系统及存储介质
CN110365766A (zh) * 2019-07-12 2019-10-22 全链通有限公司 基于区块链的云存储方法、设备及计算机可读存储介质
US20200028688A1 (en) * 2018-07-23 2020-01-23 Hitachi, Ltd. Off-chain blockchain storage with validation

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108923932A (zh) * 2018-07-10 2018-11-30 东北大学 一种去中心化协同验证模型及验证算法
US20200028688A1 (en) * 2018-07-23 2020-01-23 Hitachi, Ltd. Off-chain blockchain storage with validation
CN109190410A (zh) * 2018-09-26 2019-01-11 华中科技大学 一种云存储环境下的基于区块链的日志行为审计方法
CN110033243A (zh) * 2019-03-06 2019-07-19 华南师范大学 基于区块链智能合约的主链存证方法、系统及存储介质
CN110365766A (zh) * 2019-07-12 2019-10-22 全链通有限公司 基于区块链的云存储方法、设备及计算机可读存储介质

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113609225A (zh) * 2021-08-09 2021-11-05 北京神州数码方圆科技有限公司 基于did的区块链数据交换方法及系统
CN113609225B (zh) * 2021-08-09 2023-06-02 北京神州数码方圆科技有限公司 基于did的区块链数据交换方法及系统
CN113992336A (zh) * 2021-12-30 2022-01-28 常州唯实智能物联创新中心有限公司 基于区块链的加密网络离线数据可信交换方法及装置
CN113992336B (zh) * 2021-12-30 2022-03-29 常州唯实智能物联创新中心有限公司 基于区块链的加密网络离线数据可信交换方法及装置
CN114938278A (zh) * 2022-04-11 2022-08-23 北京邮电大学 一种零信任访问控制方法及装置
CN114938278B (zh) * 2022-04-11 2023-10-31 北京邮电大学 一种零信任访问控制方法及装置
CN115604030A (zh) * 2022-11-30 2023-01-13 北京邮电大学（Cn） 数据共享方法、装置、电子设备和存储介质
CN116029370A (zh) * 2023-03-17 2023-04-28 杭州海康威视数字技术股份有限公司 基于区块链的联邦学习的数据共享激励方法、装置及设备
CN116029370B (zh) * 2023-03-17 2023-07-25 杭州海康威视数字技术股份有限公司 基于区块链的联邦学习的数据共享激励方法、装置及设备

Similar Documents

Publication Publication Date Title
EP4120114A1 (fr) Procédé et appareil de traitement de données, dispositif intelligent, et support d'enregistrement
CN107911216B (zh) 一种区块链交易隐私保护方法及系统
US11410145B2 (en) Blockchain-implemented method for control and distribution of digital content
US11483298B2 (en) Information masking using certificate authority
RU2300845C2 (ru) Способ и системы для обеспечения безопасного распределения данных через сети общего пользования
US20200084027A1 (en) Systems and methods for encryption of data on a blockchain
WO2021154157A1 (fr) Échange de données basé sur une chaine de blocs
TW201933255A (zh) 區塊鏈系統及用於區塊鏈系統的資料處理方法
CN114730420A (zh) 用于生成签名的系统和方法
JP2019531630A (ja) 量子通信及びトラステッドコンピューティングに基づくデータセキュリティのための方法及びシステム
CN113761582B (zh) 基于群签名的可监管区块链交易隐私保护方法及系统
CN115176441A (zh) 基于身份的公钥生成协议
Win et al. Privacy enabled digital rights management without trusted third party assumption
CN116167017A (zh) 一种基于区块链技术的鞋类原创设计ai数字版权管理系统
WO2024123889A1 (fr) Systèmes et procédés de réalisation et d'application d'actions sécurisées de manière cryptographique dans des chaînes de blocs publiques non autorisées à l'aide de programmes d'auto-exécution bifurqués comprenant des exigences de signature numérique partagées
CN117200966A (zh) 一种基于分布式身份和联盟链的可信授权数据共享方法
Noh et al. A Novel User Collusion‐Resistant Decentralized Multi‐Authority Attribute‐Based Encryption Scheme Using the Deposit on a Blockchain
Yang et al. Scalable and auditable self-agent pseudonym management scheme for intelligent transportation systems
CN114844700A (zh) 一种分布式环境中基于可信存储的身份认证方法、系统、设备及存储介质
EP1185024A2 (fr) Système, procédé et logiciel pour administrer une clé d'utilisateur servant à signer un message pour un système de traitement de données
Gupta et al. A Secure Data Transfer Approach With an Efficient Key Management Over Cloud
Alniamy et al. Blockchain-based secure collaboration platform for sharing and accessing scientific research data
CN113449032B (zh) 一种数据上链可验证的区块链离链数据交互系统及方法
Osei-Bryson A Blockchain-based Security-Oriented Framework for Cloud Federation
Alharbi et al. A Blockchain Review: A Comparative Study Between Public Key Infrastructure and Identity Based Encryption

Legal Events

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

Ref document number: 21748253

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21748253

Country of ref document: EP

Kind code of ref document: A1