Method and device for sharing data

Abstract

The present disclosure discloses a method and apparatus for sharing data. The method includes: obtaining data of a first user of a first data holder and a first ciphertext identifier of the first user, where the first ciphertext identifier is obtained by encrypting the first user's user identifier using the first data holder's key and the second data holder's key in sequence; obtaining data of a second user of a second data holder and a second ciphertext identifier of the second user, where the second ciphertext identifier is obtained by encrypting the second user's user identifier using the second data holder's key and the first data holder's key in sequence; and if the first ciphertext identifier is the same as the second ciphertext identifier, sharing the data of the first user and / or the data of the second user between the first data holder and the second data holder.

Description

Technical Field

[0001] The present disclosure relates to the technical field of data sharing, and in particular to a method and device for sharing data. Background Art

[0002] Data sharing refers to collaboration among different data holders (e.g., businesses, institutions, and e-commerce platforms) through data sharing. Currently, data sharing is commonly used in sectors such as finance and e-commerce. In finance, financial institutions can share user data, such as loan information and default information, to better understand users' financial situations and conduct risk assessment and risk control. In e-commerce, e-commerce platforms need to share user data, such as purchasing behavior and spending habits, to better understand consumer habits and select target groups for marketing campaigns.

[0003] In existing data sharing solutions, each data holder needs to encrypt their user's user ID and data and send them to a trusted third party. The trusted third party then decrypts the ciphertext and stores the reported user ID and data in plain text. This way, when the first data holder needs to query a user's data, they can encrypt the user ID of the user to be queried and send it to the trusted third party. The trusted third party then matches the decrypted user ID with the stored user IDs. If a match is found, the data of the user corresponding to the queried user ID can be shared with the first data holder.

[0004] However, in the above data sharing solution, the trusted third party stores the user's data in plain text. If the trusted third party is attacked, it will directly lead to data leakage. Summary of the Invention

[0005] In view of this, the embodiments of the present disclosure are directed to providing a method and apparatus for sharing data, so as to improve the security of user data during the data sharing process.

[0006] In a first aspect, a method for sharing data is provided, comprising: obtaining data of a first user of a first data holder and a first ciphertext identifier of the first user, wherein the first ciphertext identifier is a ciphertext identifier obtained by encrypting the user identifier of the first user using the key of the first data holder and the key of the second data holder in sequence; obtaining data of a second user of a second data holder and a second ciphertext identifier of the second user, wherein the second ciphertext identifier is a ciphertext identifier obtained by encrypting the user identifier of the second user using the key of the second data holder and the key of the first data holder in sequence; if the first ciphertext identifier is the same as the second ciphertext identifier, sharing the data of the first user and / or the data of the second user between the first data holder and the second data holder.

[0007] In a second aspect, a device for sharing data is provided, the device comprising: a first acquisition unit, used to acquire data of a first user of a first data holder and a first ciphertext identifier of the first user, the first ciphertext identifier being a ciphertext identifier obtained by encrypting the user identifier of the first user using the key of the first data holder and the key of the second data holder in sequence; a second acquisition unit, used to acquire data of a second user of a second data holder and a second ciphertext identifier of the second user, the second ciphertext identifier being a ciphertext identifier obtained by encrypting the user identifier of the second user using the key of the second data holder and the key of the first data holder in sequence; a sharing unit, used to share the data of the first user and / or the data of the second user between the first data holder and the second data holder if the first ciphertext identifier is the same as the second ciphertext identifier.

[0008] According to a third aspect, a device for sharing data is provided, comprising a memory and a processor, wherein the memory stores executable code, and the processor is configured to execute the executable code to implement the method according to the first aspect.

[0009] In a fourth aspect, a computer-readable storage medium is provided, on which executable code is stored. When the executable code is executed, the method described in the first aspect can be implemented.

[0010] In a fifth aspect, a computer program product is provided, comprising an executable code, which, when executed, can implement the method described in the first aspect.

[0011] In the embodiment of the present disclosure, the commutativity principle of encryption operations is utilized to determine whether the first user and the second user are the same user by comparing the first ciphertext identifier of the first user in the first data holder with the second ciphertext identifier of the second user in the second data holder. When the first user and the second user are the same user, the data of the first user and / or the second user can be shared between the first data holder and the second data holder. In other words, the trusted third party can directly determine whether to share the above-mentioned first user's data and / or the second user's data between the first data holder and the second data holder based on the first ciphertext identifier of the first user and the second ciphertext identifier of the second user. In this way, the trusted third party does not need the plaintext of the user identifier, which is conducive to improving the security of the user's data during the data sharing process. This avoids the traditional data sharing process where the trusted third party needs to determine whether the corresponding user is a common user of the first data holder and the second data holder based on the plaintext of the user identifier, and then determine whether to share the user's data between the first data holder and the second data holder. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 Schematic diagram of a data sharing alliance architecture applicable to embodiments of the present disclosure.

[0013] Figure 2 The figure is a flowchart of a method for sharing data according to an embodiment of the present disclosure.

[0014] Figure 3 The figure is a flowchart of a method for sharing data according to another embodiment of the present disclosure.

[0015] Figure 4 2 is a schematic diagram of the structure of a device for sharing data according to an embodiment of the present disclosure.

[0016] Figure 5 FIG. 4 is a structural diagram of a device for sharing data according to another embodiment of the present disclosure. DETAILED DESCRIPTION

[0017] The technical solutions in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the drawings in the embodiments of the present disclosure. Obviously, the described embodiments are only part of the embodiments of the present disclosure, rather than all the embodiments.

[0018] In order to facilitate understanding of the present disclosure, the following Figure 1 The data sharing alliance architecture applicable to the embodiments of the present disclosure is introduced. Figure 1 The illustrated architecture includes multiple data holders 110 , a federation center 120 , and a database 130 .

[0019] Multiple data holders 110 are members of the data sharing alliance, such as enterprises, institutions, etc. that hold user data.

[0020] In some embodiments, the data holder may include a node server that can provide local services to the data holder. For example, the node server can encrypt the user identifier using the data holder's key. For another example, the node server can communicate with the alliance center 120 to query the user's data.

[0021] In other embodiments, the node servers described above can also run the business systems required by the data holder. For example, if the data holder is in the financial industry, the node server can run the financial industry business system. For another example, if the data holder is in the advertising push industry, the node server can run the business system of the advertising push platform.

[0022] The League Center 120 is typically deployed on a trusted third party (e.g., a government, regulatory agency, or third-party auditing organization) and communicates with the node server. For example, the League Center 120 may receive a query request from the node server to query user data, read the user data from the database 130 based on the query request, and then feed the retrieved user data back to the node server. For another example, the League Center 120 may also receive user data reported by the node server and store the reported user data on a trusted third party for query by other data holders.

[0023] In other embodiments, the alliance center 120 is further configured to encrypt user data to ensure the security of the user data during transmission.

[0024] The database (DB) 130 is used to store the user IDs reported by each data holder 110 and the user data corresponding to the user IDs. In some embodiments, to improve the security of user data, the DB 130 can be deployed by a trusted third party (e.g., a government, a regulatory agency, a third-party auditing agency, etc.).

[0025] Generally, data holders joining a data sharing alliance need to sign the following cooperation agreement:

[0026] First, when a user is a common user of multiple data holders in a data sharing alliance, the user's data needs to be shared among these multiple data holders.

[0027] Second, in the process of sharing data, the above-mentioned multiple data holders can only know the user's data itself, but cannot know who the data holder is who holds the data.

[0028] The following describes the aforementioned cooperation agreement using the example of sharing user loan information among financial institutions. Assume that the financial institutions participating in the data sharing alliance include Financial Institutions A, B, and C.

[0029] First, if user A borrows money from financial institution A and intends to conduct financial transactions with financial institution B, financial institution A must share user A's loan information with financial institution B as agreed. Since user A is not yet a customer of financial institution C, user A's loan information will not be shared with financial institution C.

[0030] Second, when sharing user a's loan information with financial institution B, only user a's loan information can be shared with financial institution B, but it cannot be shared which financial institution user a borrowed from.

[0031] To meet the aforementioned cooperation agreement, in traditional data sharing solutions, each data holder 110 needs to encrypt and send their user ID and data to the alliance center 120. In response, the alliance center 120 decrypts the ciphertext and stores the reported user ID and data in plaintext in the database 130. In some implementations, the user ID uniquely identifies the user. For example, the user ID can be a user's mobile phone number or ID number.

[0032] In this way, when the first data holder in the data sharing alliance needs to query the user's data, the user identifier of the user to be queried can be encrypted and sent to the alliance center 120. The alliance center 120 matches the user identifier of the user to be queried obtained after decryption with the user identifier stored in DB130. If a match is found, the data of the user corresponding to the queried user identifier can be shared with the first data holder.

[0033] However, in the above data sharing solution, the trusted third party stores the user's data in plain text. If the trusted third party is attacked, it will directly lead to data leakage.

[0034] To avoid the aforementioned issues, the present disclosure provides a data sharing solution. This solution leverages the commutative nature of encryption operations, described below, to allow a trusted third party to determine whether to share a user's data with multiple data holders based directly on the user's ciphertext identifier (i.e., the ciphertext obtained by encrypting the user's identifier using a key). This eliminates the need for data holders to store the user's identifier in plaintext with the trusted third party, improving data security during data sharing.

[0035] For ease of understanding, the following first introduces the commutativity of encryption operations.

[0036] The commutativity of encryption operations means that when multiple keys are used to encrypt the same data, the resulting ciphertext is the same regardless of how the encryption order of the multiple keys changes.

[0037] For example, when the data data is encrypted using the first key A' and the second key B' in different encryption orders respectively, the ciphertexts obtained after encryption are the same, that is, E_A'(E_B'(data))=E_B'(E_A'(data)), wherein E_A'(E_B'(data)) means that the ciphertext E_B'(data) is obtained by first encrypting the data data using the second key B', and then encrypting the ciphertext E_B'(data) using the first key A'; E_B'(E_A'(data)) means that the ciphertext E_A'(data) is obtained by first encrypting the data data using the first key A', and then encrypting the ciphertext E_A'(data) using the second key B'.

[0038] It should be noted that currently known keys generally satisfy the above-mentioned commutativity of encryption operations, such as keys based on elliptic curve cryptography (ECC) and keys based on the RSA encryption algorithm.

[0039] The following is based on Figure 1 The architecture shown, combined with Figure 2 A flowchart of a method for sharing data according to an embodiment of the present disclosure is introduced. Figure 2 The method shown may be performed by a trusted third party, e.g. Figure 1 In addition, Figure 1 The plurality of data holders 110 shown include a first data holder and a second data holder, wherein the second data holder may be one or more data holders other than the first data holder in the plurality of data holders.

[0040] Figure 2 The figure is a flowchart of a method for sharing data according to an embodiment of the present disclosure. Figure 2 The method shown includes steps S210 to S230.

[0041] In step S210, data of a first user of a first data holder and a first ciphertext identifier of the first user are obtained.

[0042] The first ciphertext identifier is a ciphertext identifier obtained by encrypting the first user's user identifier using the first data holder's key and the second data holder's key in sequence. Alternatively, the first ciphertext identifier is a ciphertext identifier obtained by first encrypting the first user's user identifier using the first data holder's key to obtain a third ciphertext identifier, which is then encrypted using the second data holder's key.

[0043] For example, the above-mentioned step S210 may include: receiving the data of the first user and the third ciphertext identifier of the first user from the first data holder, where the third ciphertext identifier is a ciphertext identifier obtained by encrypting the user identifier of the first user using the key of the first data holder; sending the third ciphertext identifier to the second data holder; receiving the first ciphertext identifier from the second data holder, where the first ciphertext identifier is a ciphertext identifier obtained by encrypting the third ciphertext identifier by the second data holder using the key of the second data holder.

[0044] Based on the above description of the process for generating the first ciphertext identifier, it can be seen that in some implementations, the trusted third party can obtain the first ciphertext identifier from the second data holder. Of course, in other implementations, after the second data holder generates the first ciphertext identifier, it can also be returned to the first data holder through the trusted third party. In this case, in step S210 above, the trusted third party can also obtain the first ciphertext identifier from the first data holder. This is not limited in the present embodiment.

[0045] There is a corresponding relationship between the above-mentioned first user data and the first ciphertext identifier. The first ciphertext identifier can be understood as being used to identify that the above-mentioned data is the data of the first user.

[0046] In step S220, the data of the second user of the second data holder and the second ciphertext identifier of the second user are obtained.

[0047] The second ciphertext identifier is a ciphertext identifier obtained by sequentially encrypting the second user's user identifier using the second data holder's key and the first data holder's key. Alternatively, the second ciphertext identifier is obtained by first encrypting the second user's user identifier using the second data holder's key to obtain a fourth ciphertext identifier, which is then encrypted using the first data holder's key.

[0048] Based on the above description of the second ciphertext identifier generation process, it can be seen that in some implementations, the trusted third party can obtain the second ciphertext identifier from the first data holder. Of course, in other implementations, after the first data holder generates the second ciphertext identifier, it can also be returned to the second data holder through the trusted third party. In this case, in step S220 above, the trusted third party can also obtain the second ciphertext identifier from the second data holder. This is not limited in the present embodiment.

[0049] In step S230 , if the first ciphertext identifier is the same as the second ciphertext identifier, the first user's data and / or the second user's data are shared between the first data holder and the second data holder.

[0050] Based on the commutativity of encryption operations described above, the fact that the first ciphertext identifier and the second ciphertext identifier are identical can be understood as meaning that the user identifier that generated the first ciphertext identifier and the user identifier that generated the second ciphertext identifier are the same. In other words, the first and second ciphertext identifiers correspond to the same user, meaning the first and second users are the same user. This allows the user's data to be shared between the first and second data holders.

[0051] On the other hand, if the first ciphertext identifier and the second ciphertext identifier are different, then it can be understood that the user identifier of the first ciphertext identifier and the user identifier that generated the second ciphertext identifier are different. In other words, the first ciphertext identifier and the second ciphertext identifier correspond to different users, that is, the first user and the second user are not the same user. In this way, the data of the first user and / or the second user can no longer be shared between the first data holder and the second data holder.

[0052] In the embodiment of the present disclosure, the commutativity principle of encryption operations is utilized to determine whether the first user and the second user are the same user by comparing the first ciphertext identifier of the first user in the first data holder with the second ciphertext identifier of the second user in the second data holder. When the first user and the second user are the same user, the data of the first user and / or the second user can be shared between the first data holder and the second data holder. In other words, the trusted third party can directly determine whether to share the above-mentioned first user's data and / or the second user's data between the first data holder and the second data holder based on the first ciphertext identifier of the first user and the second ciphertext identifier of the second user. In this way, the trusted third party does not need the plaintext of the user identifier, which is conducive to improving the security of the user's data during the data sharing process. This avoids the traditional data sharing process where the trusted third party needs to determine whether the corresponding user is a common user of the first data holder and the second data holder based on the plaintext of the user identifier, and then determine whether to share the user's data between the first data holder and the second data holder.

[0053] On the other hand, in the embodiments of the present disclosure, based on the interchangeability of encryption operations, a trusted third party can directly determine whether to share a user's data among multiple data holders based on the user's ciphertext identifier (i.e., the ciphertext obtained by encrypting the user's identifier using a key). This eliminates the need for data holders to store their data in plaintext with a trusted third party. Data sharing is achieved by ensuring that data remains within the domain (where "domain" can be understood as the data holder), thereby improving data security.

[0054] As described above, in order to determine whether the first user is a common user of the second data holder and the first data holder, the trusted third party needs to obtain the second ciphertext identifier from the first data holder or the second data holder. If, during subsequent data sharing, the trusted third party needs to obtain the second ciphertext identifier from the second data holder or the first data holder each time it needs to use it, this means that transmission resources (e.g., bandwidth) will be consumed to transmit the second ciphertext identifier, and the time it takes for the trusted third party to obtain the second ciphertext identifier will also increase.

[0055] Therefore, in order to reduce the transmission resources occupied by transmitting the second ciphertext identifier, or to reduce the time it takes for the trusted third party to obtain the second ciphertext identifier, in the embodiments of the present disclosure, the second ciphertext identifier can be directly stored in the trusted third party, that is, the second ciphertext identifier is a ciphertext identifier pre-stored in the trusted third party. Accordingly, the above step S220 can be understood as the trusted third party obtaining the second ciphertext identifier locally. Of course, if the issues of transmission resource occupation and the time it takes for the trusted third party to obtain the second ciphertext identifier are not considered, the trusted third party can also obtain the second ciphertext identifier from the first data holder or the second data holder.

[0056] In the embodiment of the present disclosure, the solution of storing the user identification of the second user in a ciphertext identification (i.e., the second ciphertext identification) in a trusted third party is beneficial to improving the privacy security of data compared to the traditional data sharing solution in which the user identification is stored in plain text in a trusted third party.

[0057] The way the trusted third party obtains the second user's data is similar to the way the trusted third party obtains the second ciphertext identifier. The trusted third party may use the second user's data (for example, it needs to share the second user's data with the first data holder), so the trusted third party will obtain the second user's data from the second data holder. However, if the trusted third party obtains the second user's data from the second data holder every time it needs to use the second user's data, it means that transmission resources (for example, bandwidth) will be occupied to transmit the second user's data. In addition, it will also increase the time it takes for the trusted third party to obtain the second user's data.

[0058] Therefore, in order to reduce the transmission resources occupied by transmitting the second user's data, or to reduce the time it takes for the trusted third party to obtain the second user's data, in the embodiments of the present disclosure, the second user's data can be directly stored in the trusted third party, that is, the second user's data is pre-stored in the trusted third party. Accordingly, the above step S220 can be understood as the trusted third party obtaining the second user's data locally. Of course, if the issues of transmission resource occupation and the time it takes for the trusted third party to obtain the second ciphertext identifier are not considered, the trusted third party can also obtain the second user's data from the second data holder.

[0059] In the embodiment of the present disclosure, although the data of the second user is stored in plain text in a trusted third party, the user identifier corresponding to the data of the second user is stored in the trusted third party in cipher text (i.e., the second cipher text identifier). In this case, even if the trusted third party is attacked, the attacker cannot obtain the user identifier corresponding to the data of the second user. In other words, the attacker can only know the specific content of the data of the second user, but cannot know who the second user is, which is conducive to improving the privacy security of the user's data.

[0060] In the data sharing scheme introduced above, if the first ciphertext identifier is different from the second ciphertext identifier, then it can be understood that the first user corresponding to the first ciphertext identifier is only the user of the first holder. In this case, if only the data of the first user and / or the data of the second user are no longer shared between the first data holder and the second data holder, then in the subsequent data sharing process, if the trusted third party needs to use the first ciphertext identifier, it still needs to obtain the first ciphertext identifier from the first data holder again. This method means that transmission resources (for example, bandwidth) need to be occupied to transmit the first ciphertext identifier. In addition, it will also increase the time for the trusted third party to obtain the first ciphertext identifier.

[0061] For example, the subsequent data sharing process needs to determine whether the third user in the second data holder is a common user between the first data holder and the second data holder. At this time, the trusted third party needs to re-obtain the first ciphertext identifier of the first user from the first data holder. This method means that transmission resources (for example, bandwidth) need to be occupied to transmit the first ciphertext identifier. In addition, it will also increase the time for the trusted third party to obtain the first ciphertext identifier.

[0062] Therefore, to avoid the above-mentioned problem, the embodiments of the present disclosure further provide a solution whereby, when the first ciphertext identifier and the second ciphertext identifier are different, the first ciphertext identifier can be stored. Thus, in the subsequent data sharing process, the trusted third party can directly determine whether to share the first user's data based on the stored first ciphertext identifier. Compared to a solution where the trusted third party re-obtains the first ciphertext identifier from the first data holder, this solution helps reduce the transmission resources used to transmit the first ciphertext identifier and shortens the time it takes for the trusted third party to obtain the first ciphertext identifier.

[0063] Similar to the above-mentioned method of the trusted third party obtaining the first ciphertext identifier, when the first ciphertext identifier is different from the second ciphertext identifier, if only the first data holder and the second data holder no longer share the first user's data and / or the second user's data, then in the subsequent data sharing process, if the trusted third party needs to use the first user's data, it still needs to obtain the first user's data from the first data holder again. This method means that transmission resources (for example, bandwidth) need to be occupied to transmit the first user's data. In addition, it will also increase the time it takes for the trusted third party to obtain the first user's data.

[0064] Therefore, to avoid the above-mentioned problem, in the embodiment of the present disclosure, when the first ciphertext identifier and the second ciphertext identifier are different, the first user's data can be stored. In this way, in the subsequent data sharing process, after the trusted third party determines that the first user's data needs to be shared, it can directly obtain the first user's data from the local server. Compared with the solution where the trusted third party obtains the first user's data from the first data holder, this is conducive to reducing the transmission resources for transmitting the first user's data and shortening the time it takes for the trusted third party to obtain the first user's data.

[0065] In the embodiment of the present disclosure, although the data of the first user is stored in plain text in a trusted third party, the user identifier corresponding to the data of the first user is stored in the trusted third party in cipher text (i.e., the first cipher text identifier). In this case, even if the trusted third party is attacked, the attacker cannot obtain the user identifier corresponding to the data of the first user. In other words, the attacker can only know the specific content of the data of the first user, but cannot know who the first user is, which is conducive to improving the privacy security of the user's data.

[0066] In the disclosed embodiments, the triggering conditions for the trusted third party to obtain the data of the first user of the first data holder and the first encrypted identifier of the first user are not specifically limited. In some embodiments, the first data holder may send the first encrypted identifier to the trusted third party when it needs to query the first user's data. Therefore, the first encrypted identifier may be included in a query request for querying data, or the first encrypted identifier may be directly used as the query request.

[0067] In other embodiments, the first data holder may proactively send the first user's data and the first ciphertext identifier of the first user to a trusted third party for sharing based on the cooperation agreement mentioned above, so that other data holders (for example, the second data holder) can query them.

[0068] As mentioned above, the data sharing scheme disclosed in this disclosure can be applied to various fields. Therefore, in order to improve the compatibility of the data sharing scheme, the data holder can use a multi-tuple structure to represent the user ID and data when generating data, that is, [user ID, data 1, data 2, ... data n ], where data1, data2, ...data n The data content attributes and number of tuples can be customized based on needs and are not limited in this embodiment. For example, in the financial field, the data generated by the data holder can be in the format of [id, date], where id represents the user's user ID and date represents the user's loan date.

[0069] Correspondingly, for the first user, after encrypting the user identifier of the first user, the first ciphertext identifier and data of the first user can be expressed as [first ciphertext identifier, data 11 ,data 12 ,……data 1n For the second user, after encrypting the user ID of the second user, the second ciphertext ID and data of the second user can be expressed as [second ciphertext ID, data 21 ,data 22 ,……data 2n ].

[0070] The aforementioned sharing of the first user's data and / or the second user's data between the first data holder and the second data holder may include a trusted third party sending the first user's data to the second data holder, or vice versa. This also satisfies the second clause of the aforementioned cooperation agreement, namely, sharing the user's data with a particular data holder while concealing the user's data holder. Of course, if compliance with the second clause of the aforementioned cooperation agreement is not required, the second data holder may also send the first user's data directly to the first data holder.

[0071] For example, for the first user, the first user's data belongs to the first data holder. When sharing the first user's data with the second data holder, a trusted third party can directly send the first user's data to the second data holder. In this way, the second data holder can only know the first user's data, but cannot know who the data holder is who holds the first user's data.

[0072] For another example, for the second user, the second user's data belongs to the second data holder. When sharing the second user's data with the first data holder, a trusted third party can directly send the second user's data to the first data holder. In this way, the first data holder can only know the second user's data, but cannot know the data holder who holds the second user's data.

[0073] In order to facilitate understanding of the solution of the embodiment of the present disclosure, the following is based on Figure 1 The architecture shown, combined with Figure 3 , taking the sharing of user loan information between financial institutions as an example, the method flow of this disclosure is introduced. Figure 1 In the architecture shown, the data holders participating in the data sharing alliance include financial institution A, financial institution B, and financial institution C.

[0074] Figure 3 The process shown can be specifically divided into a database building phase 310 and a query phase 320. The database building phase 310 includes steps S311 to S316, and the query phase 320 includes steps S321 to S326.

[0075] In the database building phase 310 , the database 130 is initially empty, and no data is stored in the database 130 .

[0076] In step S311, user a applies for a loan from financial institution A. At this time, financial institution A sends message #1 to the trusted third party: msgA(a)1=(E_A'(a), date A ), where E_A'(a) represents the encrypted identifier #1 obtained by encrypting the user identifier of user a using the key of financial institution A, date A Indicates the time when user a successfully completes the loan transaction at financial institution A.

[0077] In step S312 , the trusted third party broadcasts the received message # 1 to financial institutions B and C.

[0078] In step S313, financial institution B and financial institution C use their respective corresponding keys to encrypt ciphertext identifier #1 in message #1 to obtain ciphertext identifier #2: E_B'(E_A'(a)) and ciphertext identifier #3: E_C'(E_A'(a)).

[0079] In step S314, financial institution B returns message #2 carrying ciphertext identifier #2: E_B'(E_A'(a)) to the trusted third party: msg_B(a)1=(E_B'(E_A'(a)), date A); Financial institution C returns message #3 with ciphertext identifier #3: E_C'(E_A'(a)) to the trusted third party: msg_C(a)1=(E_C'(E_A'(a)),date A ).

[0080] In step S315, the trusted third party matches the ciphertext identifier #2 and the ciphertext identifier #3 with the ciphertext identifiers stored in the database 130. Since the database is empty at this time, the match fails and step S316 is executed.

[0081] In step S316, the trusted third party compares the ciphertext identifier #2 in message #2: E_B'(E_A'(a)) with the data date A Stored in the database, and the trusted third party compares the ciphertext identifier #3 in message #3: E_C'(E_A'(a)) with the data date A Store to database.

[0082] Query stage 320.

[0083] In step S321, if user a continues to apply for loan service at financial institution B, financial institution B sends message #4 to the trusted third party: msgB(a)2=(E_B'(a),date B ), where E_B'(a) represents the encrypted identifier #4 obtained by encrypting the user identifier of user a using the key of financial institution B, date B Indicates the time when user a applies for a loan from financial institution B.

[0084] In step S322 , the trusted third party broadcasts the received message # 4 to financial institutions A and C.

[0085] In step S323, financial institution A and financial institution C use their respective corresponding keys to encrypt ciphertext identifier #4 in message #4 to obtain ciphertext identifier #5: E_A'(E_B'(a)) and ciphertext identifier #6: E_C'(E_B'(a)).

[0086] In step S324, financial institution A returns message #5 carrying ciphertext identifier #5: E_A'(E_B'(a)) to the trusted third party: msg_A(a)2=(E_A'(E_B'(a)),date B ); Financial institution C returns message #6 with ciphertext identifier #6: E_C'(E_B'(a)) to the trusted third party: msg_C(a)2=(E_C'(E_B'(a)),date B ).

[0087] In step S325, the trusted third party matches ciphertext identifiers #5 and #6 with the ciphertext identifiers stored in the database. At this point, after step 316, ciphertext identifier #2: E_B' (E_A'(a)) is already stored in the database. Based on the commutativity of encryption operations described above, ciphertext identifier #5: E_A' (E_B'(a)) matches ciphertext identifier #2: E_B' (E_A'(a)), and step S326 is then executed.

[0088] In step S326, the trusted third party will send the data corresponding to the ciphertext identifier #2: E_B'(E_A'(a)) to A Shared with financial institution B.

[0089] Combined with the above Figures 1 to 3 , describes the method embodiment of the present disclosure in detail, and the following is combined with Figures 4 and 5 , the device embodiment of the present disclosure is described in detail. It should be understood that the description of the method embodiment corresponds to the description of the device embodiment, so that the parts not described in detail can refer to the previous method embodiment.

[0090] Figure 4 2 is a schematic diagram of the structure of a device for sharing data according to an embodiment of the present disclosure. Figure 4 The apparatus 400 shown may be deployed in a trusted third party, such as the alliance center 120. The apparatus 400 may include a first acquisition unit 410, a second acquisition unit 420, and a sharing unit 430. These units are described in detail below.

[0091] A first acquiring unit 410 is configured to acquire data of a first user of a first data holder and a first ciphertext identifier of the first user, where the first ciphertext identifier is obtained by encrypting the user identifier of the first user using a key of the first data holder and a key of a second data holder in sequence;

[0092] A second acquiring unit 420 is configured to acquire data of a second user of the second data holder and a second ciphertext identifier of the second user, where the second ciphertext identifier is obtained by encrypting the user identifier of the second user using the second data holder's key and the first data holder's key in sequence.

[0093] The sharing unit 430 is configured to share the data of the first user and / or the data of the second user between the first data holder and the second data holder if the first ciphertext identifier is the same as the second ciphertext identifier.

[0094] Optionally, the first acquisition unit 410 is specifically used to: receive the data of the first user and the third ciphertext identifier of the first user from the first data holder, where the third ciphertext identifier is a ciphertext identifier obtained by encrypting the user identifier of the first user using the key of the first data holder; send the third ciphertext identifier to the second data holder; receive the first ciphertext identifier from the second data holder, where the first ciphertext identifier is a ciphertext identifier obtained by encrypting the first ciphertext identifier by the second data holder using the key of the second data holder.

[0095] Optionally, the data of the second user is pre-stored data, and the second ciphertext identifier is a pre-stored ciphertext identifier. The device also includes: a storage unit for storing the data of the first user and the first ciphertext identifier if the first ciphertext identifier is different from the second ciphertext identifier.

[0096] Optionally, the sharing unit 430 is further configured to: send the second user's data to the first data holder, and / or send the first user's data to the second data holder.

[0097] Figure 5 FIG. 4 is a structural diagram of a device for sharing data according to another embodiment of the present disclosure. Figure 5 The illustrated apparatus 500 may be a device with data sharing capabilities deployed on a trusted third party, such as the alliance center 120. Apparatus 500 may include a memory 510 and a processor 520. Memory 510 may be used to store executable code. Processor 520 may be used to execute the executable code stored in memory 510 to implement the steps of the various methods described above. In some embodiments, apparatus 500 may also include a network interface 530, through which data exchange between processor 520 and external devices may be implemented.

[0098] In the embodiment of the present disclosure, the above-mentioned processor 520 can adopt a general central processing unit (CPU), a microprocessor, an application specific integrated circuit (ASIC), or one or more integrated circuits to execute relevant programs to implement the technical solution provided by the embodiment of the present disclosure.

[0099] The memory 510 may include a read-only memory and a random access memory, and provides instructions and data to the processor 520. A portion of the processor 520 may also include a non-volatile random access memory. For example, the processor 520 may also store device type information.

[0100] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any other combination. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present disclosure is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website, computer, server or data center to another website, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrations. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a digital video disc (DVD)), or a semiconductor medium (eg, a solid state disk (SSD)).

[0101] In the above embodiments, in various embodiments of the present disclosure, the size of the serial numbers of the above processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present disclosure.

[0102] Those skilled in the art will appreciate that the units and algorithm steps of the various examples described in conjunction with the embodiments of the present disclosure can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this disclosure.

[0103] In the several embodiments provided in the present disclosure, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0104] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0105] In addition, each functional unit in each embodiment of the present disclosure may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0106] The above description is merely a specific embodiment of the present disclosure, but the scope of protection of the present disclosure is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this disclosure should be included in the scope of protection of the present disclosure. Therefore, the scope of protection of the present disclosure should be based on the scope of protection of the claims.

Claims

1. A method for sharing data with a trusted third party, comprising: Obtaining data of a first user of a first data holder and a first ciphertext identifier of the first user, where the first ciphertext identifier is obtained by encrypting the user identifier of the first user using the key of the first data holder and the key of the second data holder in sequence, and the first ciphertext identifier is generated by the trusted third party acting as an intermediary for interaction between the first data holder and the second data holder; Obtaining data of a second user of the second data holder and a second ciphertext identifier of the second user, where the second ciphertext identifier is obtained by encrypting the user identifier of the second user using the second data holder's key and the first data holder's key in sequence, and the second ciphertext identifier is generated by the trusted third party acting as an intermediary for interaction between the first data holder and the second data holder; If the first ciphertext identifier is the same as the second ciphertext identifier, the data of the second user is sent to the first data holder, and / or the data of the first user is sent to the second data holder.

2. The method according to claim 1, wherein the data of the second user is pre-stored data, and the second ciphertext identifier is a pre-stored ciphertext identifier, the method further comprising: If the first ciphertext identifier is different from the second ciphertext identifier, the data of the first user and the first ciphertext identifier are stored.

3. The method according to claim 1, wherein obtaining the data of the first user of the first data holder and the first encrypted identifier of the first user comprises: receiving the data of the first user and a third ciphertext identifier of the first user from the first data holder, where the third ciphertext identifier is a ciphertext identifier obtained by encrypting the user identifier of the first user using the key of the first data holder; Sending the third ciphertext identifier to the second data holder; The first ciphertext identifier is received from the second data holder, where the first ciphertext identifier is a ciphertext identifier obtained by the second data holder encrypting the third ciphertext identifier using the second data holder's key.

4. A device for sharing data, applied to a trusted third party, comprising: a first acquiring unit, configured to acquire data of a first user of a first data holder and a first ciphertext identifier of the first user, wherein the first ciphertext identifier is obtained by encrypting the user identifier of the first user using a key of the first data holder and a key of a second data holder in sequence, and the first ciphertext identifier is generated by the trusted third party acting as an intermediary for interaction between the first data holder and the second data holder; a second acquiring unit, configured to acquire data of a second user of the second data holder and a second ciphertext identifier of the second user, wherein the second ciphertext identifier is obtained by encrypting the user identifier of the second user using the second data holder's key and the first data holder's key in sequence, and the second ciphertext identifier is generated by the trusted third party acting as an intermediary for interaction between the first data holder and the second data holder; A sharing unit is configured to send the second user's data to the first data holder if the first ciphertext identifier is the same as the second ciphertext identifier, and / or send the first user's data to the second data holder.

5. The apparatus according to claim 4, wherein the data of the second user is pre-stored data, and the second ciphertext identifier is a pre-stored ciphertext identifier, and the apparatus further comprises: A storage unit is configured to store the first user's data and the first ciphertext identifier if the first ciphertext identifier is different from the second ciphertext identifier.

6. The apparatus according to claim 4, wherein the first acquiring unit is specifically configured to: receiving the data of the first user and a third ciphertext identifier of the first user from the first data holder, where the third ciphertext identifier is a ciphertext identifier obtained by encrypting the user identifier of the first user using the key of the first data holder; Sending the third ciphertext identifier to the second data holder; The first ciphertext identifier is received from the second data holder, where the first ciphertext identifier is a ciphertext identifier obtained by the second data holder encrypting the third ciphertext identifier using the second data holder's key.

7. A device for sharing data, comprising a memory and a processor, wherein the memory stores executable code, and the processor is configured to execute the executable code to implement the method according to any one of claims 1 to 3.

Images