Detailed Description
The technical scheme provided in the present specification is further described in detail below with reference to the accompanying drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the invention and are not limiting of the invention. It should be noted that, for convenience of description, only the portions related to the present invention are shown in the drawings. It should be noted that, without conflict, the embodiments of the present specification and features in the embodiments may be combined with each other.
As described above, each service party maintains and manages its own service data, which may form a data island, which is not beneficial to maintenance and effective utilization of data, for example, service data of multiple service parties cannot participate in the same calculation together. In order to protect data privacy and avoid forming data islands among service data of multiple service parties, in one scheme, the multiple service parties may encrypt all respective service data and apply the data based on ciphertext, for example, ciphertext calculation, ciphertext retrieval, and the like. This approach, while implementing data privacy protection, is not conducive to interaction with the user, who can only obtain unintelligible ciphertext.
For this reason, the embodiments of the present specification provide a method for querying graph data to protect privacy. Fig. 1 shows a schematic diagram of one application scenario in which embodiments of the present description may be applied. In the application scenario shown in fig. 1, the application scenario includes a management platform 101 and a storage platform 102, where the storage platform 102 stores ciphertext data of a knowledge graph formed by aggregating graph data of a plurality of service parties, where the ciphertext data may be generated based on a target encryption system 103. Specifically, each service party may encrypt the respective service data based on the target encryption system 103 and upload the ciphertext data to the storage platform 102. The storage platform 102 may aggregate ciphertext data of a plurality of business parties into a knowledge-graph. The management platform 101 may receive a query request Q sent by the user U, where the query request Q is used to request the plain text data of the first map data of the query service B from the storage platform 102. The management platform 101 may determine whether the user U has authority to view the service data of the service B according to the user identifier of the user U and the pre-stored authorized user information of each service party. If so, a first ciphertext corresponding to the first graph data is obtained from the storage platform 102, and a first private key corresponding to the service B is obtained from the target encryption system 103. Based on the first ciphertext and the first private key, the target encryption system 103 is invoked, the first ciphertext is decrypted by the target encryption system 103 based on the first private key, and the decryption result is fed back to the management platform 101. After that, the management platform 101 may return the decryption result to the user U, and thus, the user U may view the plaintext data corresponding to the first graph data.
With continued reference to fig. 2, fig. 2 shows a flow diagram of a privacy preserving graph data querying method according to one embodiment. The method relates to a management platform and a storage platform, wherein the storage platform stores ciphertext data of a knowledge graph formed by aggregation of graph data of a plurality of service parties, and the ciphertext data can be generated based on a target encryption system. For example, assume that a group company includes four services, namely, service a, service B, service C, and service D, each of which generates service data during operation. As an example, the service data may include various data related to the service, such as user registration data, user login data, service processing data, and the like. Because these service data may relate to the privacy of the user and the service party, the service party of each service may encrypt its own service data using a preset target encryption system, and submit the encrypted service data to the storage platform. For example, each business party may generate a corresponding secret state knowledge graph according to its own business data, where the attribute values in the secret state knowledge graph are encrypted. Each business party can upload the own secret state knowledge graph to the storage platform. The storage platform can aggregate the dense state knowledge patterns of a plurality of business parties into a large knowledge pattern. For example, ciphertext matching may be performed on the secret state knowledge maps uploaded by the multiple service parties, and entity alignment may be performed on the premise of ciphertext. For example, the secret state knowledge graph G1 corresponding to the service a includes an entity E1 corresponding to the user "Zhang san", and the secret state knowledge graph G2 corresponding to the service B also includes an entity E2 corresponding to the user "Zhang san". That is, the entity E1 in the dense state knowledge graph G1 and the entity E2 in the dense state knowledge graph G2 correspond to the same user, and thus, the entity E1 and the entity E2 can be aligned. Through entity alignment, the dense state knowledge patterns of a plurality of business parties can be aggregated into a large knowledge pattern.
In addition, the management platform may store authorized user information for each business party, which may include, for example, a user identification of the authorized user. It will be appreciated that the back end of the management platform corresponds to a server, and the method may be performed by the server to which the management platform corresponds. As shown in fig. 2, the method for querying graph data for protecting privacy may include the following steps:
step 201, a first query request sent by a first user is received.
In this embodiment, the server of the management platform may receive the first query request sent by the first user. The first query request may be for requesting to query the storage platform for plaintext data for the first graph data in the first business party. As an example, the first query request may include a user identification of the first user, a service identification of the first service party, a query keyword, and so on. In this example, ciphertext data of the knowledge graph stored in the storage platform may be subjected to ciphertext retrieval, and ciphertext data of the first graph data may be obtained by querying from the knowledge graph stored in the storage platform using the query keyword.
In some implementations, the management platform may provide a query interface, which may include operation interfaces corresponding to a plurality of business parties. Here, the operation interface corresponding to the service party may refer to an operation interface of a service provided by the service party, through which a user may perform various operations, such as service transaction, data query, and the like. Thus, the user can operate on the operation interfaces corresponding to the business parties to interact with the management platform. It can be understood that when a user sends information to the management platform through an operation interface corresponding to a certain service party, the information can automatically carry the service identifier of the service party corresponding to the operation interface. Here, the first query request may be sent by the first user via an operation interface corresponding to the first service party, where the first query request carries a service identifier of the first service party.
Step 202, determining whether the first user has authority to view the service data of the first service party according to the user identification of the first user and the authorized user information of the first service party.
In this embodiment, the management platform may determine, according to the pre-stored authorized user information of the first service party and the user identifier of the first user, whether the first user has authority to view service data of the first service party. For example, assuming that the authorized user information of the first service party includes user identities of a plurality of authorized users, the management platform may match the user identities of the first user with the user identities of the plurality of authorized users, and if the user identities of the plurality of authorized users include the user identities of the first user, it indicates that the first user has the authority to view the service data of the first service party. Otherwise, the authority is not available.
In some implementations, unauthorized information is sent to the first user in response to determining that the first user does not have permission to view the business data of the first business party. The unauthorized information may be used to prompt the first user that he or she is not authorized by the first service party and cannot view plaintext data of the service data of the first service party. For example, the unauthorized information may be various forms of information such as text, voice, pictures, animation, and the like.
In step 203, in response to determining that the first user has the authority, a first ciphertext corresponding to the first graph data is obtained from the storage platform, and a first private key corresponding to the first service party is obtained from the target encryption system.
In this embodiment, the target encryption system may be used to encrypt and decrypt service data of a service party. For example, each service party may encrypt the respective service data through the target encryption system to obtain ciphertext data corresponding to the service data. Meanwhile, the private key corresponding to each service party can be stored in the target encryption system. Thus, the management platform can acquire the first private key corresponding to the first service party from the target encryption system. The first private key corresponding to the first service party may be a complete private key for decrypting ciphertext data in the knowledge-graph, or may not be a complete private key.
In some implementations, the target encryption system may also be configured to split a full private key corresponding to ciphertext data in a knowledge-graph into a plurality of sub-private keys. The first private key corresponding to the first service party may be one of a plurality of sub-private keys obtained by dividing the complete private key.
In practical use, the target encryption system may encrypt data using various encryption algorithms, such as RSA algorithm, elliptic curve ECC-based encryption algorithm, SM2 encryption algorithm, etc., and perform key segmentation. Taking an encryption algorithm as an example of an RSA algorithm, in the RSA algorithm, assuming that e is a public key index, n is a public key modulus, and service data to be encrypted is m and c is ciphertext, the encryption process can be as follows:
c=m e mod n;
in the RSA data decryption algorithm, modular exponentiation may be calculated in a collaborative manner, in particular:
P=c d mod n。
where d is the private key and P is the plaintext resulting from the decryption. It is assumed that the number of the sub-blocks,
d=d 1 +d 2 ,
the decryption formula can be deduced as:
thus, division of the private key d into d is achieved 1 And d 2 These two subprivate keys. It will be appreciated that the division of the private key into two sub-private keys is merely illustrative and not limiting of the number of sub-private keys. In practice, the subprivate key may be divided into any number of subprivate keys according to actual needs.
In some implementations, the first private key may be different from a second private key, where the second private key is a historically obtained private key for the first business party. For example, each time the management platform obtains the private key corresponding to the first service party from the target encryption system, the target encryption system may return different sub-private keys for the first service party, so that the private key corresponding to the first service party may be dynamically changed. Therefore, even if an illegal molecule acquires the private key corresponding to the first service party through an illegal means, no significant loss is caused, and the data security is protected.
Step 204, based on the first ciphertext and the first private key, invoking the target encryption system to cause the target encryption system to decrypt the first ciphertext based on the first private key.
In this embodiment, the management platform may invoke the target encryption system based on the first ciphertext and the first private key. The first ciphertext is decrypted by the target encryption system based on the first private key. As an example, where the first private key is a full private key, the target encryption system may decrypt the first ciphertext using the first private key. The target encryption system may feed back the decryption result to the management platform after decrypting the first ciphertext based on the first private key.
In some implementations, in a case where the first private key is not a full private key, the invoking the target encryption system includes: and submitting the first private key and the first ciphertext to a target encryption system through a target interface, so that the target encryption system recovers the complete private key based on the first private key, and decrypts the first ciphertext by using the complete private key.
In this implementation manner, the target interface may be a call interface provided by the target encryption system externally, through which the management platform may submit the first ciphertext and the first private key to the target encryption system for decryption. For example, the target encryption system may determine, from the split plurality of sub-private keys, a sub-private key required to recover the complete private key according to the first private key, and recover the complete private key, and decrypt the first ciphertext using the complete private key.
Step 205, returning the decryption result to the first user.
In this embodiment, the management platform may return the decryption result fed back by the target encryption system to the first user, so that the first user may obtain plaintext data of the first graph data.
In some implementations, the first graph data can include a first node in a knowledge-graph. And, returning the decryption result to the first user may specifically include: and displaying attribute information of the first node and/or a one-hop subgraph of the first node to the first user.
In some implementations, the first graph data can include a first edge in a knowledge-graph. And, returning the decryption result to the first user may specifically include: and displaying the first edge and node information connected with the first edge to the first user.
In some implementations, the method for querying graph data to protect privacy may further include the following:
1) And receiving a second query request sent by a second user.
In this implementation, the second query request may be used to request ciphertext data of the second graph data from the storage platform to query the second service party. As an example, the second query request may include a user identification of the second user, a service identification of the second service party, a query keyword, and so on. Here, the second user may be the same as or different from the first user. The second business party may be the same as or different from the first business party described above.
2) And acquiring a second ciphertext corresponding to the second graph data from the storage platform, and sending the second ciphertext to a second user.
In this implementation, if the user requests ciphertext data, the management platform does not need to determine whether the second user has permission to view the service data of the second service party. And directly inquiring from the storage platform according to the inquiry keyword in the second inquiry request to obtain a second ciphertext corresponding to the second graph data, and sending the second ciphertext to a second user. Through the implementation manner, the second user can obtain the ciphertext data of the second graph data in the second service party.
Reviewing the above procedure, in the embodiment of the present specification, ciphertext data of service data of a plurality of service parties may be stored in the same knowledge graph, and when a user wants to query plaintext data of service data of a certain service party, it may be first determined whether the user has authority to view service data of the service party, and if so, the data is decrypted and the decryption result is fed back to the user. On the premise of protecting data safety, the problem of data island caused by the fact that each business party establishes a knowledge graph respectively is avoided.
According to another embodiment of the present invention, a privacy-preserving graph data query device is provided, which relates to a management platform and a storage platform, where the storage platform stores ciphertext data of a knowledge graph formed by aggregating graph data of a plurality of service parties, the ciphertext data is generated based on a target encryption system, the management platform stores authorized user information of each service party, and the device can be deployed on a server corresponding to the management platform.
Fig. 3 shows a schematic block diagram of a privacy preserving graph data querying apparatus in accordance with one embodiment. As shown in fig. 3, the privacy-preserving graph data query apparatus 300 includes: a receiving unit 301, configured to receive a first query request sent by a first user, where the first query request is used to request to query plaintext data of first graph data in a first service party from the storage platform; a determining unit 302, configured to determine, according to the user identifier of the first user, authorized user information of the first service party, whether the first user has authority to view service data of the first service party; an obtaining unit 303 configured to obtain, in response to determining that the first user has the authority, a first ciphertext corresponding to the first graph data from the storage platform, and obtain a first private key corresponding to the first service party from the target encryption system; a decryption unit 304 configured to invoke the target encryption system based on the first ciphertext and the first private key, so that the target encryption system decrypts the first ciphertext based on the first private key; and a return unit 305 configured to return the decryption result to the first user.
In some optional implementations of this embodiment, the target encryption system is configured to divide a complete private key corresponding to ciphertext data in the knowledge graph into a plurality of sub-private keys, where the first private key is one of the plurality of sub-private keys; the decryption unit 304 is further configured to submit the first private key and the first ciphertext to the target encryption system via a target interface, so that the target encryption system recovers a complete private key based on the first private key, and decrypts the first ciphertext using the complete private key.
In some optional implementations of this embodiment, the first private key is different from a second private key, where the second private key is a historically obtained private key for the first service party.
In some optional implementations of this embodiment, the apparatus 300 further includes: a transmitting unit (not shown in the figure) configured to transmit unauthorized information to the first user in response to determining that the first user does not have authority to view the service data of the first service party.
In some optional implementations of this embodiment, the apparatus 300 further includes: a request receiving unit (not shown in the figure) configured to receive a second query request sent by a second user, where the second query request is used to request to query ciphertext data of second graph data in a second service party from the storage platform; and a ciphertext transmitting unit (not shown) configured to acquire a second ciphertext corresponding to the second map data from the storage platform, and transmit the second ciphertext to the second user.
In some optional implementations of this embodiment, the management platform provides a query interface, where the query interface includes operation interfaces corresponding to the multiple service parties, and the first query request is sent by the first user through the operation interface corresponding to the first service party, where the query interface carries a service identifier of the first service party.
In some optional implementations of this embodiment, the first graph data includes a first node in the knowledge-graph; and the return unit 305 is further configured to display attribute information of the first node and/or a one-hop subgraph of the first node to the above-mentioned first user.
In some optional implementations of this embodiment, the first graph data includes a first edge in the knowledge-graph; and the return unit 305 is further configured to display the first side, and node information to which the first side is connected, to the first user.
According to an embodiment of another aspect, there is also provided a computer-readable storage medium having stored thereon a computer program which, when executed in a computer, causes the computer to perform the method described in fig. 2.
According to an embodiment of yet another aspect, there is also provided a computing device including a memory and a processor, wherein the memory has executable code stored therein, and the processor, when executing the executable code, implements the method described in fig. 2.
Those of ordinary skill would further appreciate that the elements and algorithm steps of the examples described in connection with the embodiments disclosed herein may be embodied in electronic hardware, in computer software, or in a combination of the two, and that the elements and steps of the examples have been generally described in terms of function in the foregoing description to clearly illustrate the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Those of ordinary skill in the art may implement the described functionality using different approaches for each particular application, but such implementation is not to be considered as beyond the scope of the present application.
The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied in hardware, in a software module executed by a processor, or in a combination of the two. The software modules may be disposed in Random Access Memory (RAM), memory, read Only Memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.
The foregoing description of the embodiments has been provided for the purpose of illustrating the general principles of the invention, and is not meant to limit the scope of the invention, but to limit the invention to the particular embodiments, and any modifications, equivalents, improvements, etc. that fall within the spirit and principles of the invention are intended to be included within the scope of the invention.