HK40017862B - Managing sensitive data elements in blockchain network - Google Patents

Description

Managing sensitive data elements in a blockchain network

Technical Field

This document relates to managing sensitive data elements stored in a blockchain network.

Background

Distributed Ledgers (DLS), which may also be referred to as consensus networks and/or blockchain networks, enable participating entities to securely and non-tamperably store data. Without referencing any particular use case, DLS is commonly referred to as a blockchain network. Examples of blockchain network types may include public blockchain networks, private blockchain networks, and federated blockchain networks. The federated blockchain network is provided for selected entity groups that control the consensus process and include an access control layer.

The data transmitted in a computer network including a blockchain network may include sensitive data such as personal information (e.g., biometric data, medical information, and social security numbers) that may be traced back to an individual and that may cause injury or loss to the individual if the information is disclosed. The sensitive data may also include sensitive business information (e.g., trade secrets, acquisition plans, and financial data) that, if discovered by competitors or the public, pose a risk to the business entity. The sensitive data may include classification information that is relevant to government agencies and is limited according to the degree of sensitivity (e.g., limited, confidential, secret, and absolute) to secure the information.

It is desirable to provide a solution to the data security problem of sensitive data in a computer network.

Disclosure of Invention

Techniques for managing sensitive data elements stored in a blockchain network are described herein. These techniques generally involve implementing a watch list (also referred to as a blockchain-based watch list) in a blockchain network. The monitoring list includes one or more sensitive data elements that are monitored and/or filtered by one or more authorized entities (e.g., organizations, regulatory authorities, specialized authorities, or governments). Sensitive data elements may contain or relate to sensitive, private and/or confidential information. In some embodiments, the sensitive data elements are stored in a blockchain network in a distributed manner based on a blockchain-based watch list. In some embodiments, the blockchain-based surveillance list may facilitate management of sensitive data elements stored in the surveillance list. In some embodiments, blockchain-based surveillance lists may improve data security by providing tamper-resistant protection of sensitive data elements and preventing malicious behavior and network attacks against the surveillance list.

Also provided herein are one or more non-transitory computer-readable storage media coupled to one or more processors and having instructions stored thereon that, when executed by the one or more processors, will cause the one or more processors to perform operations in accordance with embodiments of the methods provided herein.

Also provided herein are systems for implementing the methods provided herein. The system includes one or more processors and a computer-readable storage medium coupled to the one or more processors and having instructions stored thereon that, when executed by the one or more processors, will cause the one or more processors to perform operations in accordance with embodiments of the methods provided herein.

It will be appreciated that any combination of aspects and features described herein may be included in accordance with the methods herein. That is, the methods according to the present disclosure are not limited to the combinations of aspects and features specifically described herein, but include any combination of the aspects and features provided.

The details of one or more embodiments herein are set forth in the accompanying drawings and the description below. Other features and advantages will be apparent from the description and drawings, and from the claims.

Drawings

Fig. 1 is a diagram illustrating an example of an environment that may be used to perform embodiments herein.

Fig. 2 is a diagram illustrating an example of an architecture according to embodiments herein.

Fig. 3 is a diagram illustrating an example of a system according to embodiments herein.

Fig. 4 depicts an example of a process that may be performed in accordance with an embodiment herein.

Fig. 5 depicts an example of a process that may be performed in accordance with an embodiment herein.

Fig. 6 depicts an example of modules of an apparatus according to embodiments herein.

Like reference numbers and designations in the various drawings indicate like elements.

Detailed Description

Techniques for managing sensitive data elements stored in a blockchain network are described herein. These techniques generally involve implementing a watch list (also referred to as a blockchain-based watch list) in a blockchain network. The monitoring list includes one or more sensitive data elements that are monitored and/or filtered by one or more authorized entities (e.g., organizations, regulatory authorities, specialized authorities, or governments). Sensitive data elements may contain or relate to sensitive, private and/or confidential information. In some embodiments, the sensitive data elements are stored in a blockchain network in a distributed manner based on a blockchain-based watch list. In some embodiments, the blockchain-based surveillance list may facilitate management of sensitive data elements stored in the surveillance list. In some embodiments, blockchain-based surveillance lists may improve data security by providing tamper-resistant protection of sensitive data elements and preventing malicious behavior and network attacks against the surveillance list.

The techniques described herein produce one or more technical effects. In some embodiments, the watch list may be implemented in a blockchain network. The monitoring list may include one or more sensitive data elements that are monitored and/or filtered by one or more authorized entities. Sensitive data elements in the watch list are stored in a distributed manner in the blockchain network. Malicious behavior and network attacks against the watch list can be mitigated due to the tamper-resistant nature of the distributed blockchain network. In some embodiments, the blockchain-based surveillance list may facilitate management of sensitive data elements stored in the surveillance list. For example, when a client device submits a request to perform a modification to a watch list stored in the blockchain network, a network node of the blockchain network that receives the request may authenticate the client device based on a digital signature of the client device in the request. In some embodiments, the authenticated client device may be allowed to perform the modification, while the client device that failed authentication will be denied to perform the modification. This can prevent sensitive data stored in the blockchain network from being corrupted by malicious actors, thereby improving the data security of the surveillance list. In some embodiments, sensitive data elements in the watch list are encrypted, for example using an encryption algorithm. In some embodiments, only authorized parties may decrypt the encrypted data elements and obtain sensitive data elements. This may prevent malicious actors from diving into the blockchain network and obtaining sensitive data elements, thereby improving the data security of the surveillance list.

Further context is provided for embodiments herein, and as described above, a Distributed Ledger System (DLS), which may also be referred to as a consensus network (e.g., consisting of point-to-point nodes) and blockchain network, enables participating entities to securely, non-tamper-ably transact and store data. Although the term "blockchain" is generally associated with a particular network and/or use case, the term "blockchain" is used herein to refer generally to DLS without reference to any particular use case.

Blockchains are data structures that store transactions in a manner that the transaction is not tamperable with. Thus, transactions recorded on the blockchain are reliable and trusted. A blockchain includes one or more blocks. Each block in the chain is linked to the immediately preceding block in the chain by a cryptographic hash value (cryptographic hash) contained in the preceding block. Each chunk also includes a timestamp, its own cryptographic hash value, and one or more transactions. Transactions that have been validated by nodes in the blockchain network are hashed and encoded into a Merkle (Merkle) tree. Merkle trees are a data structure in which data at leaf nodes of the tree is hashed, and all hash values in each branch of the tree are concatenated at the root of the branch. This process continues along the tree until the root of the entire tree, where hash values representing all the data in the tree are stored. It is possible to quickly verify whether the hash value is a hash value of a transaction stored in a tree by determining whether the hash value is consistent with the structure of the tree.

A blockchain is a data structure for storing decentralization or at least partial decentralization of transactions, while a blockchain network is a network of computing nodes that manage, update, and maintain one or more blockchains by broadcasting, validating, and validating transactions, etc. As described above, the blockchain network may be provided as a public blockchain network, a private blockchain network, or a federated blockchain network. Embodiments herein are described in further detail herein with reference to federated blockchain networks. However, it is contemplated that embodiments herein may be implemented in any suitable type of blockchain network.

Typically, federated blockchain networks are proprietary between the participating entities. In a federated blockchain network, the consensus process is controlled by a set of authorized nodes, which may be referred to as consensus nodes, one or more of which are operated by respective entities (e.g., financial institutions, insurance companies). For example, a federation consisting of ten (10) entities (e.g., financial institutions, insurance companies) may operate a federated blockchain network, with each entity operating at least one node in the federated blockchain network.

In some examples, within a federated blockchain network, a global blockchain is provided as a blockchain that replicates across all nodes. That is, all consensus nodes are in a fully consensus state with respect to the global blockchain. To achieve consensus (e.g., agree to add blocks to the blockchain), a consensus protocol is implemented within the federated blockchain network. For example, the federated blockchain network may implement a practical bayer fault tolerance (Practical Byzantine Fault Tolerance, PBFT) consensus, as described in further detail below.

Fig. 1 is a diagram illustrating an example of an environment 100 that may be used to perform embodiments herein. In some examples, environment 100 enables entities to participate in federated blockchain network 102. The environment 100 includes computing systems 106, 108 and a network 110. In some examples, network 110 includes a Local Area Network (LAN), a Wide Area Network (WAN), the internet, or a combination thereof, and connects websites, user devices (e.g., computing devices), and backend systems. In some examples, network 110 may be accessed through wired and/or wireless communication links. In some examples, the network 110 enables communication with the federated blockchain network 102 or communication within the federated blockchain network 102. In general, network 110 represents one or more communication networks. In some cases, the computing systems 106, 108 may be nodes of a cloud computing system (not shown), or each computing system 106, 108 may be a separate cloud computing system comprising multiple computers interconnected by a network and functioning as a distributed processing system.

In the depicted example, computing systems 106, 108 may each include any suitable computing device capable of participating as a node into federated blockchain network 102. Examples of computing devices include, but are not limited to, servers, desktop computers, notebook computers, tablet computers, and smartphones. In some examples, the computing systems 106, 108 carry one or more computer-implemented services for interacting with the federated blockchain network 102. For example, the computing system 106 may carry computer-implemented services of a first entity (e.g., user a), such as a transaction management system, that the first entity uses to manage its transactions with one or more other entities (e.g., other users). Computing system 108 may carry computer-implemented services of a second entity (e.g., user B), such as a transaction management system, that the second entity uses to manage its transactions with one or more other entities (e.g., other users). In the example of fig. 1, the federated blockchain network 102 is represented as a point-to-point network (Peer-to-Peer network) of nodes, and the computing systems 106, 108 provide nodes that participate in the first and second entities of the federated blockchain network 102, respectively.

Fig. 2 depicts an example of an architecture 200 according to embodiments herein. The exemplary conceptual architecture 200 includes participant systems 202, 204, 206 corresponding to participant a, participant B, and participant C, respectively. Each participant (e.g., user, enterprise) participates in a blockchain network 212 provided as a point-to-point network that includes a plurality of nodes 214, at least some of which record information in the blockchain 216 non-tamperably. As further detailed in the figures, although a single blockchain 216 is schematically depicted in the blockchain network 212, multiple copies of the blockchain 216 are provided and maintained on the blockchain network 212.

In the depicted example, each participant system 202, 204, 206 is provided by or represents participant a, participant B, and participant C, respectively, and functions as a respective node 214 in the blockchain network. As used herein, a node generally refers to an individual system (e.g., computer, server) that is connected to the blockchain network 212 and enables corresponding participants to participate in the blockchain network. In the example of fig. 2, a participant corresponds to each node 214. However, it is contemplated that one participant may operate multiple nodes 214 within the blockchain network 212 and/or that multiple participants may share one node 214. In some examples, the participant systems 202, 204, 206 communicate with the blockchain network 212 using a protocol (e.g., hypertext transfer protocol secure (HTTPS)) and/or using Remote Procedure Calls (RPCs) or through the blockchain network 212.

Nodes 214 may have different degrees of participation within blockchain network 212. For example, some nodes 214 may participate in the consensus process (e.g., as monitoring nodes that add blocks to the blockchain 216), while other nodes 214 do not participate in the consensus process. As another example, some nodes 214 store a complete copy of the blockchain 216, while other nodes 214 store only a copy of a portion of the blockchain 216. For example, data access privileges may restrict blockchain data stored by respective participants within their respective systems. In the example of fig. 2, the participant systems 202, 204 store respective full copies 216', 216 "of the blockchain 216.

A blockchain (e.g., blockchain 216 of fig. 2) is made up of a series of blocks, each block storing data. Examples of data include transaction data representing transactions between two or more participants. Although "transactions" are used herein by way of non-limiting example, it is contemplated that any suitable data may be stored in a blockchain (e.g., documents, images, video, audio). Examples of transactions may include, but are not limited to, exchanges of valuables (e.g., assets, products, services, money). Transaction data is stored non-tamperably in the blockchain. That is, the transaction data cannot be changed.

The transaction data is hashed before being stored in the block. The hash processing is processing of converting transaction data (provided as character string data) into a fixed-length hash value (also provided as character string data). No unhasher (un-hash) can be performed on the hash value to obtain transaction data. The hash process may ensure that even slight changes in transaction data may result in disparate hash values. Further, as described above, the hash value has a fixed length. That is, the length of the hash value is fixed regardless of the size of the transaction data. The hash processing includes processing the transaction data by a hash function to generate a hash value. Examples of hash functions include, but are not limited to, secure Hash Algorithm (SHA) -256 that outputs a 256-bit hash value.

Transaction data for a plurality of transactions is hashed and stored in a chunk. For example, hash values for two transactions are provided and hash themselves to provide another hash value. This process is repeated until a single hash value is provided for all transactions to be stored in the block. This hash value is called Merkle root hash value and is stored in the header of the block. Any transaction change will result in a change in its hash value and ultimately in a change in the Merkle root hash value.

The blocks are added to the blockchain by a consensus protocol. Multiple nodes in the blockchain network participate in a consensus protocol and compete for adding blocks to the blockchain. Such nodes are referred to as consensus nodes. The PBFT described above is used as a non-limiting example of a consensus protocol. The consensus node performs a consensus protocol to add transactions to the blockchain and update the overall state of the blockchain network.

In more detail, the consensus node generates a block header, hashes all transactions in the block, and combines the resulting hash values in pairs to generate further hash values until a single hash value (Merkle root hash value) is provided for all transactions in the block. This hash value is added to the block header. The consensus node also determines the hash value of the most recent chunk in the blockchain (i.e., the last chunk added to the blockchain). The consensus node also adds a random number (nonce) and a timestamp to the block header.

Typically, PBFT provides a practical bayer state machine replication that is tolerant of bayer faults (e.g., faulty nodes, malicious nodes). This is achieved by assuming in the PBFT that a failure will occur (e.g., assuming that there is an independent node failure and/or a manipulation message sent by the consensus node). In the PBFT, the consensus nodes are provided in an order including a main consensus node and a standby consensus node. The master consensus node is periodically changed to add transactions to the blockchain by agreement on the global state of the blockchain network by all consensus nodes within the blockchain network. In this process, messages are transmitted between the consensus nodes, and each consensus node proves that the message was received from a designated peer node (peer node) and verifies that the message was not tampered with during transmission.

In PBFT, the consensus protocol is provided in multiple phases with all consensus nodes starting in the same state. First, the client sends a request to the master consensus node to invoke a service operation (e.g., perform a transaction within a blockchain network). In response to receiving the request, the primary consensus node multicasts the request to the backup consensus node. The backup consensus nodes execute the requests and each send replies to the clients. The client waits until a threshold number of replies are received. In some examples, the client waits until f+1 replies are received, where f is the maximum number of error consensus nodes that can be tolerated within the blockchain network. The end result is that a sufficient number of consensus nodes agree on the order in which records are added to the blockchain and that the records are either accepted or rejected.

In some blockchain networks, encryption processing is used to maintain the privacy of transactions. For example, if two nodes want to maintain transaction privacy so that other nodes in the blockchain network cannot see the details of the transaction, the two nodes may encrypt the transaction data. Examples of encryption processes include, but are not limited to, symmetric encryption and asymmetric encryption. Symmetric encryption refers to an encryption process that uses a single key to both encrypt (to generate ciphertext from plaintext) and decrypt (to generate plaintext from ciphertext). In symmetric encryption, the same key may be used for multiple nodes, so each node may encrypt/decrypt transaction data.

Asymmetric encryption uses key pairs, each key pair comprising a private key that is known only to the corresponding node and a public key that is known to any or all other nodes in the blockchain network. A node may encrypt data using the public key of another node and the encrypted data may be decrypted using the private key of the other node. For example, referring again to fig. 2, participant a may encrypt data using participant B's public key and send the encrypted data to participant B. Participant B may decrypt the encrypted data (ciphertext) and extract the original data (plaintext) using its private key. Messages encrypted using the public key of a node can only be decrypted using the private key of that node.

Asymmetric encryption is used to provide a digital signature that enables a participant in a transaction to confirm the validity of other participants in the transaction as well as the transaction. For example, a node may digitally sign a message, and another node may confirm from the digital signature of participant a that the message was sent by the node. Digital signatures can also be used to ensure that messages are not tampered with during transmission. For example, referring again to fig. 2, participant a will send a message to participant B. Participant a generates a hash value of the message and then encrypts the hash value using its private key to provide a digital signature as an encrypted hash value. Participant a appends the digital signature to the message and sends the message with the digital signature to participant B. Participant B decrypts the digital signature using participant a's public key and extracts the hash value. Participant B hashes the message and compares the hash values. If the hash values are the same, participant B may confirm that the message did come from participant a and was not tampered with.

FIG. 3 is a diagram illustrating an example of a system 300 that manages sensitive data elements stored in a blockchain network. As shown, the system 300 includes a blockchain network 310 that includes a plurality of blockchain network nodes 302a-302f and one or more client devices 304. Note that the illustrated blockchain network 310 includes six blockchain network nodes 302 is for illustration only. The blockchain network 310 may include any suitable number of blockchain network nodes 302. The client device 304 may be any suitable computer, module, server, or computing element that is encoded to perform the methods described herein.

In some embodiments, blockchain network 310 is configured to store a monitoring list that includes sensitive data elements that are monitored and/or filtered by an authorized entity (e.g., an organization, regulatory agency, special agency, or government). In some embodiments, sensitive data elements may be monitored or filtered for privacy protection, data security, and/or auditing or monitoring purposes. In some examples, the sensitive data may include personal information (e.g., biometric data, medical information, and social security numbers) such as personally identifiable information that may be traced back to an individual and may cause injury or loss to the individual if the information is disclosed. In some embodiments, the sensitive data may include sensitive business information (e.g., business secrets, acquisition plans, and financial data) that pose a risk to business entities if the information is discovered by competitors or the public. In some embodiments, the sensitive data may include classification information that is related to government agencies and is limited according to the degree of sensitivity (e.g., limited, confidential, secret, and absolute) to secure the information. In some embodiments, the sensitive data may have a text, audio, video, or image format. In some embodiments, the sensitive data may include malicious programs that constitute a potential security threat.

In some embodiments, a network node 302 (e.g., node 302 a) in the blockchain network 310 receives a request from a client device 304. The request may include a request to modify the watch list (e.g., a request to add a data element to the list, a request to delete a data element from the list, or a request to edit a data element in the list). The network node 302a may initiate a consensus process within the blockchain network 310 such that if a subset of the blockchain network nodes 302 (e.g., the consensus nodes 302a-302 d) may agree on the proposed modification, the requested modification may be performed on the watch list.

In some embodiments, the blockchain network 310 includes a subset of the blockchain network nodes 302 that do not participate in the consensus process (e.g., non-consensus nodes 302e-302 f). In some embodiments, the consensus nodes 302a-302d in the blockchain network 310 may be allowed to process requests from the client device 304 to perform modifications to the watch list, while the non-consensus nodes 302e-302f in the blockchain network 310 are not allowed to process requests from the client device 304 to perform modifications to the watch list. For example, the consensus nodes 302a-302d may be implemented on a server of an authorized entity (e.g., government) that controls access to and periodically updates the monitoring list, while the non-consensus nodes 302e-302f may be implemented on a server of an affiliated entity of the authorized entity (e.g., a publication platform) that may obtain the monitoring list from the consensus nodes 302a-302d without being allowed or authorized to modify the monitoring list.

Fig. 4 depicts an example of a signal flow 400 according to embodiments herein. Signal flow 400 represents a process for managing sensitive data elements stored in a blockchain network. For convenience, this process will be described as being performed by a system of one or more computers located at one or more locations and appropriately programmed according to the disclosure. For example, a suitably programmed distributed system (e.g., system 300 of FIG. 3) may perform the process.

Process 400 begins at 402, where a client device (e.g., client 304 a) sends a request to blockchain network 310 to perform a modification to a watch list stored in the blockchain network. For example, client 304a sends the request to consensus node 302a in blockchain network 310. A monitoring list comprising a plurality of sensitive data elements (e.g., keywords) is monitored and/or filtered by one or more authorized entities. In some embodiments, the modification to the monitoring list includes one or more of: adding data elements to the list, deleting data elements from the list, or editing data elements in the list. In some embodiments, some or all of the sensitive data elements in the watch list may be encrypted such that they are invisible or agnostic to the general public.

In some embodiments, the request includes identity information (e.g., an identifier) of the client device 304a and a digital signature generated using a private key of the client device 304 a. The digital signature may be used to verify or authenticate the identity of the client device 304 a.

At 404, the blockchain network node 302a determines whether the client device 304a is authorized to modify the watch list stored in the blockchain network 310. In some embodiments, blockchain network node 302a stores a whitelist including identifiers of client devices authorized to modify the watch list.

In some embodiments, the blockchain network node 302a may determine whether the identifier of the client device 304a in the request matches the identifier of the client device in the whitelist. Additionally or alternatively, blockchain network node 302a may determine whether the digital signature in the request may be decrypted using the public key of the client device in the whitelist (e.g., the public key of the client whose identifier matches the identifier of client device 304a in the request). In some embodiments, the public key of the client device in the whitelist is stored in a blockchain network. The blockchain network node 302a may retrieve the public key of the client device in the whitelist from the blockchain network or from other resources.

If the public key of the client device in the whitelist is used to decrypt the digital signature in the request, the blockchain network node 302a may extract the hash value generated by the client device 304a in the request. The blockchain network node 302a may hash the received request and compare the generated hash value with the hash value extracted from the digital signature. If the hash values match, blockchain network node 302a determines that client device 304a is authorized to modify the watch list and the process proceeds to the next step. If the hash values do not match or the digital signature in the request cannot be decrypted using the public key of any client device in the whitelist, the blockchain network node 302a determines that the client device 304a is not authorized to modify the watch list and may terminate the process. For example, the blockchain network node 302a may send an error message to the client device 304a indicating that the client device 304a is not authorized to modify the watch list and reject the request.

At 406, the blockchain network node 302a initiates a consensus process within the blockchain network 310 with the proposed modification from the client device 304 a. The blockchain network node 302a may identify other consensus nodes 302b-302d in the blockchain network 310. In some embodiments, the consensus process is performed between consensus nodes 302a-302d in the blockchain network 310. Examples of consensus processes as described herein include workload certification, equity certification, or practical bayer fault tolerance, among others. For example, the consensus process may involve the steps of: the consensus node 302a multicasts (multicast) an initial message to the other consensus nodes (e.g., nodes 302b-302 d) for validating the request; the consensus nodes 302b-302d verify the request using the smart contract and then send a reply message to node 302 a; and consensus node 302a waits for multiple reply messages from different nodes with the same result. If the number of reply messages from other nodes with the same result exceeds a predetermined threshold, the consensus node 302a may determine that consensus has been reached and perform the modification proposed in the request. For example, if the modification includes adding a new sensitive data element to the watch list, the consensus node 302a may store the new sensitive data element in the watch list.

At 408, the blockchain network node 302a sends notifications to other network nodes in the blockchain network 310. In some embodiments, the notification includes a modification in the request from the client device 304a and a request to instruct other network nodes to perform the consensus process. In some embodiments, the blockchain network node 302a sends notifications to the consensus nodes 302b-302d such that only the consensus nodes 302a-302d are notified to participate in the consensus process.

At 410, the blockchain network nodes 302b-302d perform a consensus process. In some embodiments, nodes 302b-302d each multicast an initial message to other consensus nodes for the authentication request and wait for multiple reply messages from different nodes with the same result. If the number of reply messages from other nodes with the same result exceeds a predetermined threshold, the blockchain network nodes 302b-302d may determine that a consensus has been reached and perform the modification proposed in the request. For example, if the modification includes adding a new sensitive data element to the watch list, the blockchain network nodes 302b-302d may store the new sensitive data element in the watch list such that the consensus nodes 302a-302d may each have an updated watch list containing the new sensitive data element.

At 412, the blockchain network nodes 302b-302d send a notification to the network node 302a indicating that a consensus process has been performed for each network node and that a consensus has been reached.

At 414, blockchain network node 302a determines that a consensus node in blockchain network 310 has performed a consensus process based on notifications from other consensus nodes. In some embodiments, the blockchain network node 302a generates a blockchain transaction based on a request from the client device 304a and calculates a Merkle root hash value based on the blockchain transaction. The consensus nodes 302a-302d may use Merkle tree root hash values to identify malicious network nodes in future consensus processes.

At 416, the client device (e.g., client device 304 b) sends a query request to blockchain network node 302a for sensitive data elements stored in the watch list in blockchain network 310. In some embodiments, the query request includes a digital signature generated using the private key of the client device 304 b.

At 418, the blockchain network node 302a determines whether the client device 304b is authorized to obtain the sensitive data elements in the watch list. In some embodiments, the blockchain network node 302a may determine whether the client device 304b is authorized to obtain the sensitive data elements in the watch list, e.g., according to the techniques described for 404 or in another manner, based on the digital signature in the request and the public key of the authorized entity listed in the whitelist stored in the blockchain network node 302 a. If the blockchain network node 302a determines that the client device 304b is not authorized to obtain the sensitive data elements in the watch list, the blockchain network node 302a may reject the request.

At 420, in response to determining that client device 304b is authorized to obtain the sensitive data element, blockchain network node 302a sends the sensitive data element to client device 304 b. In some embodiments, the sensitive data element is encrypted and the client device 304b may receive the encrypted sensitive data element. In some embodiments, the sensitive data elements may be encrypted using a key. If client device 304b holds the key, client device 304b may obtain the sensitive data element by decrypting the encrypted sensitive data element.

FIG. 5 is a flow diagram of an example of a process 500 for managing sensitive data elements stored in a blockchain network. For convenience, process 500 will be described as being performed by a system of one or more computers located at one or more locations and appropriately programmed according to the disclosure. For example, a properly programmed distributed system, such as distributed system 300 of fig. 3, may perform process 500.

At 502, a blockchain network node (e.g., blockchain network node 302) receives a request from a client device (e.g., client device 304) to perform a modification to a watch list stored in a blockchain network (e.g., blockchain network 310). In some embodiments, the blockchain network node may be a consensus node of the blockchain network. In some embodiments, the monitoring list includes a plurality of sensitive data elements (e.g., in the form of keywords) that are monitored and/or filtered by, for example, a network node (e.g., a blockchain network or another network such as the internet). In some embodiments, the request includes a digital signature generated using a private key of the client device. In some embodiments, the modification in the request includes one or more of the following: request to add a data element to a list, request to delete a data element from a list, or request to edit a data element in a list. In some embodiments, sensitive data elements in the watch list may be encrypted.

At 504, the blockchain network node determines whether the client device is authorized to modify the watch list. In some embodiments, the blockchain network node determines whether the client device is authorized to modify the watch list based on the digital signature in the request from the client device. In some embodiments, the blockchain network node stores a whitelist including identifiers and/or public keys of one or more client devices authorized to modify the monitoring list. In some embodiments, determining, by the network node, whether the client device is authorized to modify the monitoring list based on the digital signature includes: for example, in accordance with the techniques described with respect to 404 or otherwise, a determination is made that the client device is authorized to modify the monitoring list based on the digital signature in the request and the public key of the authorized entity authorized to modify the monitoring list.

If it is determined that the client device is authorized to modify the watch list, processing proceeds to step 506. If it is determined that the client device is not authorized to modify the watch list, processing proceeds to step 516 where the request is denied.

At 506, after determining that the client device is determined to be authorized to modify the watch list, the blockchain network node performs a consensus process on the request within the blockchain network. Examples of consensus processes described herein include workload certification, equity certification, or practical bayer fault tolerance, among others. In some embodiments, the blockchain network node may identify other consensus nodes in the blockchain network. In some embodiments, a consensus process is performed between consensus nodes of a blockchain network. For example, the consensus process may involve the steps of: the blockchain network node multicasts an initial message for verifying the request to other consensus nodes; other consensus nodes verify the request by using the intelligent contract, and then send a reply message to the blockchain network node; the blockchain network node waits for multiple reply messages from different nodes with the same result. The blockchain network node may determine that a consensus has been reached if the number of reply messages from other consensus nodes with the same result exceeds a predetermined threshold.

At 508, the blockchain network node performs the modification in the request after determining that the consensus process is complete and that the consensus has been reached. In some examples, if the modification includes adding a new sensitive data element to the watch list, the blockchain network node may store the new sensitive data element in the watch list. In some embodiments, the blockchain network node may encrypt the new sensitive data element before storing the new sensitive data element in the watch list.

At 510, the blockchain network node receives, for example, from a second client device, a query request for sensitive data elements stored in a watch list in the blockchain network. In some embodiments, the query request includes a second digital signature generated using a private key of the second client device.

At 512, the blockchain network node determines whether the second client device is authorized to view, access, or otherwise obtain the sensitive data element based on the second digital signature. In some embodiments, the blockchain network node stores a whitelist that includes identifiers and/or public keys of one or more client devices authorized to view, access, or otherwise obtain sensitive data elements in the monitoring list (collectively referred to as a query monitoring list). In some embodiments, the whitelist may be the same as or different from the whitelist including identifiers and/or public keys of one or more client devices authorized to modify the monitoring list. In some embodiments, additional or different levels of rights may be assigned to the client device for permitted operations of the watch list, and the client device may be indicated in a single or multiple whitelists.

In some embodiments, determining, by the network node, whether the client device is authorized to query the monitoring list based on the digital signature includes: for example, in accordance with the techniques described with respect to 404 or otherwise, a determination is made that the client device is authorized to query the monitoring list based on the digital signature and a public key of an authorized entity of the monitoring list.

If it is determined that the client device is authorized to query the watch list, processing proceeds to step 514. If it is determined that the client device is not authorized to query the watch list, processing proceeds to step 518 where the query request is denied.

At 514, responsive to determining that the second client device is authorized to obtain the sensitive data element, the blockchain network node sends a response to the second client device. The response includes the requested sensitive data element. In some embodiments, the sensitive data elements in the monitoring list are encrypted and the response includes the encrypted sensitive data elements.

Fig. 6 is a diagram of an example of modules of an apparatus 600 according to embodiments herein. Apparatus 600 may be an example of an embodiment of a node of a blockchain network configured to manage sensitive data elements stored in the blockchain network. The apparatus 600 may correspond to the above-described embodiments, and the apparatus 600 includes the following: a receiving module 602 for receiving a request from a client device to perform a modification to a monitoring list stored in a blockchain network, the monitoring list comprising a plurality of sensitive data elements, and the request comprising a digital signature generated using a private key of the client device; a determining module 604 for determining whether the client device is authorized to modify the watch list based on the digital signature; an execution module 606 for performing a consensus process on the request within the blockchain network in response to determining that the client device is authorized to modify the watch list; an execution module 608 for performing a modification to the monitored list in response to determining that consensus is reached after completion of the consensus process; a rejection module 610 for rejecting a request from the client device to perform a modification to the watch list.

In an alternative embodiment, the plurality of sensitive data elements are monitored and/or filtered by one or more authorized entities.

In an alternative embodiment, the request to perform the modification to the watch list includes one or more of the following: a request to add a new sensitive data element to the watch list, a request to remove a sensitive data element from the watch list, or a request to edit a sensitive data element in the watch list.

In an alternative embodiment, the plurality of sensitive data elements are encrypted.

In an alternative embodiment, the apparatus 600 further comprises the following: a determination submodule for determining that the client device is authorized to modify the watch list based on the digital signature and a public key of an authorized entity authorized to modify the watch list.

In an alternative embodiment, the authorized entity is indicated in a white list stored in the network node, and the white list comprises one or more authorized entities authorized to modify the monitoring list.

In an alternative embodiment, the apparatus 600 further comprises the following: a receiving module for receiving a query request from a second client device for sensitive data elements stored in a watch list in a blockchain network, the query request comprising: a second digital signature generated using a private key of a second client device; a determining module for determining whether the second client device is authorized to obtain the sensitive data element based on the second digital signature; and a transmitting module for transmitting a response to the second client device, the response comprising the encrypted sensitive data element.

The system, apparatus, module or unit shown in the previous embodiments may be implemented by using a computer chip or entity, or may be implemented by using a product having a specific function. Typical implementation devices are computers, which may be personal computers, laptop computers, cellular telephones, camera phones, smart phones, personal digital assistants, media players, navigation devices, email devices, game consoles, tablet computers, wearable devices, or any combination of these devices.

For an embodiment of the function and role of each module in the apparatus, reference may be made to an embodiment of the corresponding step in the previous method. Details are omitted here for simplicity.

Since the apparatus embodiments substantially correspond to the method embodiments, for relevant parts reference may be made to the relevant description in the method embodiments. The previously described apparatus embodiments are merely examples. Modules described as separate parts may or may not be physically separated, and parts shown as modules may or may not be physical modules, may be located in one location, or may be distributed over a plurality of network modules. Some or all of the modules may be selected based on actual needs to achieve the goals of the aspects herein. Those of ordinary skill in the art will understand and implement the embodiments of the present application without undue burden.

Referring again to fig. 6, it can be interpreted to illustrate the internal functional modules and structure of the blockchain data element management device. The blockchain data element management device may be an example of a blockchain network node configured to manage sensitive data elements stored in the blockchain network. The execution body may be an electronic device in nature, and the electronic device includes the following: one or more processors, and a memory configured to store executable instructions of the one or more processors.

The techniques described herein produce one or more technical effects. In some embodiments, when a client device submits a request to perform a modification to a watch list stored in the blockchain network, a network node of the blockchain network that receives the request needs to authenticate the client device based on the digital signature of the client device in the request. In some embodiments, the authenticated client device may be allowed to perform the modification, while the client device that failed authentication will be denied to perform the modification. This may prevent sensitive data stored in the blockchain network from being corrupted by malicious actors, thereby improving the data security of the blockchain network. Further, in some embodiments, sensitive data elements in the watch list are encrypted (e.g., encrypted using a key). Only the client device holding the key can decrypt the encrypted data element and obtain the sensitive data element. This prevents malicious actors from diving into the blockchain network and obtaining sensitive data elements, thereby improving the data security of the blockchain network. Further, the sensitive data elements in the watch list are stored in a distributed manner in the blockchain network. Malicious behavior and network attacks against the watch list can be mitigated due to the tamper-resistant nature of the distributed blockchain network.

Embodiments of the described subject matter may include one or more features, alone or in combination. For example, in a first embodiment, a method for managing sensitive data elements stored in a blockchain network includes: a request from a client device to perform a modification to a watch list stored in a blockchain network is received by a network node of the blockchain network. The monitoring list includes a plurality of sensitive data elements, the request including a digital signature generated using a private key of the client device; determining, by the network node, whether the client device is authorized to modify the watch list based on the digital signature; performing, by the network node, a consensus process on the request within the blockchain network in response to determining that the client device is authorized to modify the monitoring list, and performing, by the network node, modification of the monitoring list in response to determining that the consensus is reached after completion of the consensus process; and responsive to determining that the client device is not authorized to modify the watch list, the network node denies a request from the client device to perform a modification to the watch list. The foregoing and other described embodiments may each optionally include one or more of the following features:

the first feature, which may be combined with any of the following features, specifies that the plurality of sensitive data elements are monitored and/or filtered by one or more authorized entities.

The second feature, which may be combined with the previous or following features, specifies that the request to perform the modification to the monitoring list includes one or more of the following: a request to add a new sensitive data element to the watch list, a request to remove a sensitive data element from the watch list, or a request to edit a sensitive data element in the watch list.

The third feature, which may be combined with any of the previous or following features, specifies that the plurality of sensitive data elements are encrypted.

The fourth feature, which may be combined with any of the previous or following features, specifies that the determination by the network node of whether the client device is authorized to modify the watch list based on the digital signature, includes the following: the client device is determined to be authorized to modify the watch list based on the digital signature and a public key of an authorized entity authorized to modify the watch list.

The fifth feature, which may be combined with any of the previous or following features, specifies that the authorized entity is indicated in a whitelist stored in the network node, and the whitelist comprises one or more authorized entities authorized to modify the monitoring list.

A sixth feature, which may be combined with any of the preceding or following features, specifies that the method further comprises: receiving, by the network node, a query request from a second client device for sensitive data elements stored in a watch list in the blockchain network, wherein the query request includes a second digital signature generated using a private key of the second client device; determining, by the network node, whether the second client device is authorized to obtain the sensitive data element based on the second digital signature; and in response to determining that the second client device is authorized to obtain the sensitive data element, sending, by the network node, a response to the second client device, the response including the encrypted sensitive data element.

Embodiments of the subject matter, acts, and operations described herein may be implemented in digital electronic circuitry, in tangibly embodied computer software or firmware, in computer hardware, including the structures disclosed herein and their structural equivalents, or in combinations of one or more of them. Embodiments of the subject matter described herein may be implemented as one or more computer programs, e.g., one or more modules of computer program instructions, encoded on a computer program carrier, for execution by, or to control the operation of, data processing apparatus. For example, a computer program carrier may include a computer readable storage medium having instructions encoded or stored thereon. The carrier may be a tangible, non-transitory computer-readable medium such as a magnetic, magneto-optical, or optical disk, a solid state drive, a Random Access Memory (RAM), a Read Only Memory (ROM), or other type of medium. Alternatively or additionally, the carrier may be a manually generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus for execution by data processing apparatus. The computer storage medium may be, or be part of, a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more of them. The computer storage medium is not a propagated signal.

A computer program can also be called or described as a program, software application, app, module, software module, engine, script, or code, which can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages; it may be configured in any form, including as a stand-alone program, or as a module, component, engine, subroutine, or other unit suitable for execution in a computing environment that may include one or more computers at one or more locations interconnected by a communications data network.

The computer program may, but need not, correspond to a file in a file system. The computer program may be stored in: one or more scripts stored in a markup language document, for example, in a portion of a file that holds other programs or data; a single file dedicated to the program in question; or a plurality of reconciliation files, e.g., a plurality of files storing one or more modules, subroutines, or portions of code.

Processors for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Typically, the processor will receive the Chilean of the computer program for execution and data from a computer readable medium coupled to the processor.

The term "data processing apparatus" includes all types of apparatus, devices, and machines for processing data, including for example, a programmable processor, a computer, or multiple processors or computers. The data processing means may comprise dedicated logic circuits, such as an FPGA (field programmable gate array), an ASIC (application specific integrated circuit) or a GPU (graphics processing unit). In addition to hardware, the apparatus may include code that creates an execution environment for a computer program, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.

The processes and logic flows described herein can be performed by one or more computers or processors executing one or more computer programs to perform operations by computing input data and generating output. The processes and logic flows can also be performed by, or in combination with, one or more programmed computers, dedicated logic circuits, e.g., FPGA, ASIC, GPU.

A computer suitable for executing a computer program may be based on a general-purpose and/or special-purpose microprocessor, or any other kind of central processing unit. Typically, the central processing unit will receive instructions and data from a read only memory and/or a random access memory. Elements of a computer may include a central processing unit for executing instructions and one or more memory devices for storing instructions and data. The central processing unit and the memory may be supplemented by, or integrated in, special purpose logic circuitry.

Typically, a computer will also include, or be operatively coupled to, one or more storage devices to receive data from, or transfer data to, the one or more storage devices. The storage device may be, for example, a magnetic disk, a magneto-optical disk or optical disk, a solid state drive, or any other type of non-transitory computer readable medium. However, the computer need not have such a device. Thus, the computer may be coupled to one or more storage devices, such as one or more memories, local and/or remote. For example, a computer may include one or more local memories as an integrated component of the computer, or the computer may be coupled to one or more remote memories in a cloud network. Furthermore, the computer may be embedded in another device, such as a mobile phone, a Personal Digital Assistant (PDA), a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device such as a Universal Serial Bus (USB) flash drive, to name a few.

The components may be "coupled" to each other by, for example, electrical or optical connection with each other directly or through one or more intervening components. Components may also be "coupled" to each other if one component is integrated into another component. For example, a storage component integrated into a processor (e.g., an L2 cache component) is "coupled to" the processor.

To provide for interaction with a user, embodiments of the subject matter described herein can be implemented on or configured to communicate with a computer having: a display device, for example, an LCD (liquid crystal display) monitor, for displaying information to a user; and an input device through which a user may provide input to the computer, such as a keyboard and a pointing device, such as a mouse, trackball or touch pad. Other types of devices may also be used to provide interaction with a user; for example, feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and may receive any form of input from the user, including acoustic, speech, or tactile input. Further, the computer may interact with the user by sending and receiving documents to and from the device used by the user; for example, by sending web pages to a web browser on a user device in response to requests received from the web browser, or by interacting with an application (app) running on a user device such as a smart phone or electronic tablet. In addition, the computer may interact with the user by sending text messages or other forms of messages to the personal device (e.g., a smart phone running a messaging application) in turn and receiving response messages from the user.

The term "configured to" in relation to systems, devices and computer program components is used herein. For a system of one or more computers configured to perform a particular operation or action, it is meant that the system has installed thereon software, firmware, hardware, or a combination thereof that, in operation, causes the system to perform the operation or action. For one or more computer programs configured to perform a particular operation or action, it is meant that the one or more programs include instructions that, when executed by a data processing apparatus, cause the apparatus to perform the operation or action. For a dedicated logic circuit configured to perform a particular operation or action, it is meant that the circuit has electronic logic that performs the operation or action.

Although many specific embodiment details are included herein, these should not be construed as limitations on the scope of what may be claimed, but rather as descriptions of specific features of particular embodiments, as defined by the claims themselves. The various specific features described herein in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Furthermore, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the combination may be directed to a subcombination or variation of a subcombination.

Similarly, although operations are depicted in the drawings and described in the claims in a particular order, this should not be construed as: to achieve the desired results, it may be desirable to perform these operations in the particular order shown, or in sequence, or to perform all of the operations shown. In some cases, multitasking parallel processing may be advantageous. Moreover, the division of the various system modules and components in the embodiments described above should not be construed as requiring such division in all embodiments, but rather it should be understood that the described program components and systems may be generally integrated together in a single software product or packaged into multiple software products.

Specific embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. For example, the actions recited in the claims can be performed in a different order and still achieve desirable results. As one example, the processes depicted in the accompanying figures do not require the particular order shown, or sequence, to achieve desirable results. In some cases, multitasking and parallel processing may be advantageous.

Claims (8)

1. A computer-implemented method for managing sensitive data elements stored in a blockchain network, the method comprising:

A network node in a blockchain network receives a request from a client device to perform a modification to a monitoring list stored in the blockchain network, wherein the monitoring list includes a plurality of sensitive data elements and the request includes a digital signature generated using a private key of the client device;

the network node determining, based on the digital signature, whether the client device is authorized to modify the monitoring list;

in response to determining that the client device is authorized to modify the watch list:

the network node performing a consensus process on the request within the blockchain network; and

in response to determining that consensus is reached after completion of the consensus process, the network node performs the modification to the monitoring list; or (b)

Responsive to determining that the client device is not authorized to modify the watch list, the network node denies the request from the client device to perform the modification on the watch list;

the network node determining whether the client device is authorized to modify the watch list based on the digital signature, comprising:

determining that the client device is authorized to modify the watch list based on the digital signature and a public key of an authorized entity authorized to modify the watch list.

2. The method of claim 1, wherein the plurality of sensitive data elements are monitored and/or filtered by one or more authorized entities.

3. A method as claimed in any preceding claim, wherein the request to perform the modification to the monitoring list comprises one or more of:

a request to add a new sensitive data element to the watch list,

Request to remove sensitive data elements from the watch list, and

a request to edit sensitive data elements in the watch list.

4. A method as claimed in any preceding claim, wherein the plurality of sensitive data elements are encrypted.

5. The method of claim 1, wherein,

the authorised entity is indicated in a white list stored in the network node, and

the whitelist includes one or more authorized entities authorized to modify the watch list.

6. The method of any preceding claim, further comprising:

the network node receiving a query request from a second client device for sensitive data elements stored in the monitoring list in the blockchain network, wherein the query request includes a second digital signature generated using a private key of the second client device;

The network node determining, based on the second digital signature, whether the second client device is authorized to obtain the sensitive data element; and

in response to determining that the second client device is authorized to obtain the sensitive data element, the network node sends a response to the second client device, the response including the encrypted sensitive data element.

7. An apparatus for managing sensitive data elements stored in a blockchain network, the apparatus comprising a plurality of modules for performing the method of any of claims 1-6.

8. A system for managing sensitive data elements stored in a blockchain network, comprising:

one or more processors; and

one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon, the instructions being executable by the one or more processors to perform the method of any of claims 1-6.