System, method and apparatus for verifying data authenticity

Abstract

The present specification provides a system, method and device for verifying data authenticity, the system comprising: an audited party for obtaining encrypted data from a data source and sending a key data acquisition request to an auditing party, the key data acquisition request containing description information of the encrypted data; receiving the key data returned by the auditing party in response to the key data acquisition request, and generating a corresponding decryption key according to the key data returned by the auditing party; decrypting the encrypted data based on the generated decryption key, and sending the decrypted data obtained by decryption to a data user; an auditing party for receiving the key data acquisition request sent by the audited party, and returning the key data to the audited party; a data user for receiving the decrypted data sent by the audited party, and in the case that the description information of the decrypted data matches the description information of the encrypted data, acknowledging the authenticity of the decrypted data.

Description

TECHNICAL FIELD

[0001] Embodiments of the present specification belong to the technical field of communication, and particularly relate to a system, method and device for verifying data authenticity. BACKGROUND

[0002] In the existing service link, the data processing flow is that the data acquisition party acquires data from the data source and sends the acquired data to the data user for use. In this process, the data acquisition party can tamper with the acquired data, and the data user cannot verify the authenticity of the data sent by the data acquisition party.

[0003] For example, in the salary transfer scenario, there are human resources outsourcing and labor dispatching services running on the human resources salary transfer platform. In these services, the human resources company provides personnel management and salary payment services for the employer. Since the employer and the human resources platform have an account period in the salary payment link, the human resources platform needs to advance the salary. The employer and the human resources platform mainly realize the salary captain through email. Email information can be used as effective trade background materials to form accounts receivable. Therefore, the email verification service for verifying the authenticity of email information has become an important part.

[0004] Currently, there are two ways to verify the authenticity of email information: first, the user proves the authenticity of the email through screenshots, photos, etc.; second, the communication process is built into a hardware trusted environment, and the email verification service of the hardware trusted environment is used to verify the email information. In these two ways, the former is simple to operate, but still has a high risk of tampering, and the latter is not easy to tamper with, but requires complex hardware support and is high in cost. SUMMARY

[0005] The purpose of the present specification is to provide a system, method and device for verifying data authenticity.

[0006] According to a first aspect of one or more embodiments of the present specification, a system for verifying data authenticity is provided, the system comprising:

[0007] The audited party acquires encrypted data from the data source, sends a key data acquisition request to the auditing party, the key data acquisition request containing description information of the encrypted data, receives the key data returned by the auditing party in response to the key data acquisition request, and generates a corresponding decryption key according to the key data returned by the auditing party; decrypts the encrypted data based on the generated decryption key, and sends the decrypted data obtained by decryption to the data user;

[0008] The auditing party receives the key data acquisition request sent by the audited party, and returns the key data to the audited party.

[0009] The data user receives the decrypted data sent by the audited party, and in the case that the description information of the decrypted data matches the description information of the encrypted data, the authenticity of the decrypted data is recognized.

[0010] According to a second aspect of one or more embodiments of the present specification, a method for verifying data authenticity is provided, applied to an audited party, and the method comprises:

[0011] An encrypted data is obtained from a data source, and a key data acquisition request is sent to the auditing party, wherein the key data acquisition request comprises description information of the encrypted data;

[0012] The key data returned by the auditing party in response to the key data acquisition request is received, and a corresponding decryption key is generated according to the key data returned by the auditing party;

[0013] The encrypted data is decrypted based on the generated decryption key, and the decrypted data obtained by decryption is sent to a data user, so that the data user recognizes the authenticity of the decrypted data in the case that the description information of the decrypted data matches the description information of the encrypted data.

[0014] According to a third aspect of one or more embodiments of the present specification, a method for verifying data authenticity is provided, applied to an auditing party, and the method comprises:

[0015] A key data acquisition request sent by an audited party is received, wherein the key data acquisition request comprises description information of encrypted data;

[0016] The key data of the decryption key corresponding to the encrypted data is returned to the audited party, so that the audited party generates a corresponding decryption key according to the key data returned by the auditing party, decrypts the encrypted data based on the generated decryption key, and sends the decrypted data to a data user, so that the data user recognizes the authenticity of the decrypted data in the case that the description information of the decrypted data matches the description information of the encrypted data.

[0017] According to a fourth aspect of one or more embodiments of the present specification, a device for verifying data authenticity is provided, applied to an audited party, and the device comprises:

[0018] An obtaining unit: obtaining encrypted data from a data source, and sending a key data acquisition request to an auditing party, wherein the key data acquisition request comprises description information of the encrypted data;

[0019] A generating unit: generating a corresponding decryption key according to the key data returned by the auditing party;

[0020] The sending unit decrypts the encrypted data based on the generated decryption key, and sends the decrypted data to a data user, so that the data user recognizes authenticity of the decrypted data if description information of the decrypted data matches the description information of the encrypted data.

[0021] According to a fifth aspect of one or more embodiments of the present specification, an apparatus for verifying data authenticity is provided, applied to an auditing party, and the apparatus comprises:

[0022] The first receiving unit receives a key data acquisition request sent by an audited party, and the key data acquisition request comprises description information of encrypted data.

[0023] The returning unit returns key data of a decryption key corresponding to the encrypted data to the audited party, so that the audited party generates a corresponding decryption key according to the key data returned by the auditing party, decrypts the encrypted data based on the generated decryption key, sends the decrypted data to a data user, so that the data user recognizes authenticity of the decrypted data if description information of the decrypted data matches the description information of the encrypted data.

[0024] According to a sixth aspect of one or more embodiments of the present specification, an electronic device is provided, comprising:

[0025] A processor;

[0026] A memory for storing processor executable instructions;

[0027] The processor implements the method of any one of the second aspect or the third aspect by running the executable instructions.

[0028] According to a seventh aspect of one or more embodiments of the present specification, a computer readable storage medium is provided, and the computer readable storage medium stores computer instructions, and the instructions are executed by a processor to implement the steps of the method of any one of the second aspect or the third aspect.

[0029] In the embodiments of the present specification, the audited party obtains the decryption key by sending a key data acquisition request containing the description information of the encrypted data to the auditing party. The encrypted data is decrypted by the decryption key, and the decrypted data obtained by decryption is sent to the data user, so that the data user can recognize the authenticity of the decrypted data in the case that the description information of the decrypted data matches the description information of the encrypted data, thereby realizing the verification of the data authenticity. Compared with the screenshot, the above-mentioned entire verification process does not involve manual participation, and there is no risk of being tampered with; and since the above-mentioned verification process does not need to be built into the hardware trusted environment, the cost is low. BRIEF DESCRIPTION OF DRAWINGS

[0030] In order to more clearly illustrate the technical solutions of the embodiments of the present specification, the drawings needed in the embodiment description will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments described in the present specification, and those skilled in the art can also obtain other drawings according to these drawings without creative labor.

[0031] Figure 1 FIG. 1 is a system architecture diagram of verifying data authenticity provided by an exemplary embodiment.

[0032] Figure 2 FIG. 2 is a flowchart of a method of verifying data authenticity provided by an exemplary embodiment.

[0033] Figure 3 FIG. 3 is an interaction diagram of a key agreement process provided by an exemplary embodiment.

[0034] Figure 4a FIG. 4 is a schematic diagram of an encryption key generation process provided by an exemplary embodiment.

[0035] Figure 4b FIG. 5 is a schematic diagram of another encryption key generation process provided by an exemplary embodiment.

[0036] Figure 5 FIG. 6 is a schematic diagram of email authentication provided by an exemplary embodiment.

[0037] Figure 6 FIG. 7 is a flowchart of another method of verifying data authenticity provided by an exemplary embodiment.

[0038] Figure 7 FIG. 8 is a structural schematic diagram of a device provided by an exemplary embodiment.

[0039] Figure 8 FIG. 9 is a block diagram of an apparatus for verifying data authenticity provided by an exemplary embodiment.

[0040] Figure 9 This is a block diagram of another training apparatus for verifying the authenticity of data, provided in an exemplary embodiment. Detailed Implementation

[0041] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0042] by Figure 1 For example, Figure 1 This is an exemplary embodiment of a system architecture diagram for verifying the authenticity of data. For example... Figure 1 As shown in the diagram, the data source 11, the auditee 12, the auditor 13, and the data user 14 are included.

[0043] Data source 11 is the data provider, which can be a device capable of storing and transmitting data. Auditee 12 is the aforementioned data acquirer, who can obtain data from data source 11 and send it to data user 14 for use. To prevent data tampering by auditee 12, data source 11 can negotiate with auditee 12 and auditor 13 to encrypt the data using a key before providing it. Auditor 13 can be a third-party notary platform other than data source 11 and auditee 12.

[0044] Since at least a portion of the key data used to generate the decryption key is provided by the auditor 13, the auditee 12 needs to obtain the key data from the auditor 13 if it wants to decrypt the encrypted data provided by the data source 11. The auditor 13 can only send the key data to the auditee 12 after receiving the description information of the encrypted data from the auditee 12. After receiving the key data provided by the auditor 13, the auditee 12 can generate a decryption key, decrypt the encrypted data, and send the decrypted data to the data user 14. If the auditee 12 has tampered with the data, the description information of the decrypted data will not match the description information of the encrypted data. Therefore, the data user 14 can determine that the auditee 12 has not tampered with the data if the description information of the encrypted data matches, thus acknowledging the authenticity of the decrypted data.

[0045] In different scenarios, the data user 14 corresponds to different business systems, for example: in the salary email authentication scenario, the data source 11 can be a storage server of a mail system, the audited party 12 can be a mail client corresponding to a user, the auditor 13 can be a third-party notarization platform, and the data user 14 can be a financial system of a user company; or in the freight scenario, the data source 11 can be a server with the function of issuing a delivery order, the audited party 12 can be a client corresponding to a user, the auditor 13 can be a third-party notarization platform, and the data user 14 can be a server corresponding to a supplier.

[0046] The following will be described in detail Figure 2 The method for semantic segmentation is described in detail. Figure 2 A flowchart of a method for verifying data authenticity provided by an example embodiment is shown in Figure 2 The method is applied to an audited party and at least includes the following steps:

[0047] In step 202, encrypted data is obtained from a data source, and a key data acquisition request is sent to an auditor, wherein the key data acquisition request contains description information of the encrypted data.

[0048] The description information of the encrypted data can include at least one of the following: a hash value of the encrypted data, the encrypted data itself, and attribute information of the encrypted data.

[0049] The audited party can calculate the hash value of the encrypted data by performing a hash operation on the encrypted data. Since the hash values of the data in the encrypted state and the decrypted state are matched, the subsequent data user can compare the hash value of the encrypted data with the hash value of the decrypted data to determine whether the data has been tampered with by the audited party. The attribute information of the encrypted data can be information describing the basic attributes of the encrypted data, such as the data type, name, length, etc. of the encrypted data.

[0050] Of course, the description information of the encrypted data can be any two or a combination of two of the hash value of the encrypted data, the encrypted data itself, and the attribute information of the encrypted data, for example: the description information of the encrypted data is the hash value of the encrypted data and the encrypted data itself, or the encrypted data itself and the attribute information of the encrypted data, or the hash value of the encrypted data, the encrypted data itself, and the attribute information of the encrypted data. This specification does not limit this.

[0051] In step 204, the key data returned by the auditor in response to the key data acquisition request is received, and a corresponding decryption key is generated according to the key data returned by the auditor.

[0052] In an embodiment, the generating of the decryption key according to the key data returned by the auditor comprises: in a case that the returned key data is all key data for generating the decryption key, the auditee generates the decryption key according to all the key data returned by the auditor; in a case that the returned key data is part of key data for generating the decryption key, the auditee generates the decryption key according to the part of key data returned by the auditor and part of key data stored locally.

[0053] The key data returned by the auditor can be all key data for generating the decryption key, or can be part of key data for generating the encryption key, which is related to the key negotiation process of the auditor, the auditee and the data source. Before the auditee obtains the encrypted data from the data source, the auditor, the auditee and the data source negotiate the key, and the negotiated key is used to encrypt the data in the data source.

[0054] The following will be described in combination with Figure 3 The process of key negotiation will be described in detail. Figure 3 Fig. 1 is an interaction diagram of a key negotiation process provided by an exemplary embodiment, as shown in the figure, the interaction diagram can comprise the following steps: Figure 3

[0055] Step 302, the auditee sends a key negotiation request.

[0056] The auditee sends a key negotiation request to the data source, which can comprise a first random number generated by the auditee, and version, algorithm and other information supported by the auditee. The first random number is part of key data for generating the encryption key. The auditee sends the version, algorithm and other information to the data source to unify the version and algorithm in the key encryption process with the data source. In a case that the data source does not support the version or algorithm sent by the auditee, the negotiation will be interrupted, and the result of the key negotiation with the data source is negotiation failure; only in a case that the data source supports the version and algorithm sent by the auditee, the negotiation can continue. Of course, the key negotiation request can also comprise other information, such as the IP or certificate of the auditee, which is not limited in the present specification.

[0057] Step 304, the data source returns the negotiation result.

[0058] The data source returns the negotiation result to the auditee, which can comprise the algorithm determined by the data source and the auditee after negotiation, the certificate for indicating the identity of the data source, and the second random number generated by the data source. The second random number is part of key data for generating the encryption key, and the algorithm and the certificate after negotiation can determine that the data source can support the version and algorithm of the auditee, and the negotiation process can continue.​

[0059] Step 306, the audited party sends an encrypted key data acquisition request. Step 308, the auditor returns part of the key data. Step 310, the audited party sends part of the key data.

[0060] The random number sent by the audited party to the data source is the third random number. According to the algorithm determined in step 304, the third random number can be generated by the auditor and the audited party jointly, or can be generated by the auditor alone. For example, the part of the key data returned by the auditor can be a 24-byte random number. After receiving the 24-byte random number returned by the auditor, the audited party can generate another 24-byte random number, and send the 48-byte random number as the third random number to the data source; or the part of the key data returned by the auditor can be a 24-byte random number, and the audited party can directly forward the 24-byte random number as the third random number to the data source. In the case where the third random number is generated by the auditor and the audited party jointly, the key data for generating the decryption key returned by the auditor in the foregoing decryption process is part of the key data, and the key data for generating the decryption key is provided by the auditor and the audited party jointly; in the case where the third random number is generated by the auditor alone, the key data for generating the decryption key returned by the auditor in the foregoing decryption process is all of the key data, and the key data for generating the decryption key is provided by the auditor alone. It is worth noting that whether the random number sent by the audited party or the random number sent by the auditor is encrypted by the unique algorithm provided by the data source, the audited party cannot decrypt the 24-bit random number of the auditor, which makes the audited party unable to generate the encryption key, but the data source can decrypt the key data sent by the audited party according to the unique algorithm, thereby generating the encryption key.

[0061] Step 312, the data source generates an encryption key according to the key data.

[0062] After receiving the third random number sent by the audited party, the data source can calculate the first, second and third random numbers according to the algorithm determined in step 304 to generate an encryption key. When the audited party subsequently obtains data from the data source, the data source can encrypt the data according to the generated encryption key. The encryption process can be symmetric key encryption or asymmetric key encryption, which is not limited in the present specification. The encryption key is not permanently valid. After the data is encrypted once and sent to the audited party, the encryption key will be invalid, and the three parties will negotiate to generate a new encryption key to deal with the next data encryption.

[0063] The embodiment provides a key agreement method, in which, in addition to the audited party and the data source, the auditing party also participates in the key agreement process as a third party, so that the audited party must obtain part or all of the key data from the auditing party to generate a decryption key when decrypting encrypted data, thereby laying a foundation for verifying data authenticity.

[0064] In an embodiment, the key agreement process of the auditing party, the audited party and the data source is implemented based on a TLSNotary algorithm of a TLS protocol.

[0065] As described above, the audited party can generate a decryption key according to the key data returned by the auditing party. The generation process of the decryption key is described in detail below. Figure 4a 、 4b The generation process of the decryption key is described in detail below. Figure 4a 、 4b As shown in FIG. 5, the auditing party and the audited party respectively generate a random number of 24 bytes, and respectively expand and calculate A and B of 48 bytes. The auditing party can send the first 24 bytes of A to the audited party, so that the audited party calculates and generates C1 of 24 bytes according to the first 24 bytes of A and B. The audited party can send the last 24 bytes of B to the auditing party, so that the auditing party calculates and generates C2 of 24 bytes according to the last 24 bytes of A and B. The audited party can expand and calculate D1 of 140 bytes according to C1, and intercept the first 20 bytes of D1 as D11 and the last 120 bytes of D1 as D12. The auditing party can expand and calculate D2 of 140 bytes according to C2, and intercept the first 20 bytes of D2 as D21 and the last 120 bytes of D2 as D22. The decryption key of the encrypted data includes two parts, a first decryption key and a second decryption key. After receiving the encrypted data, the audited party can obtain D22 from the auditing party, and generate the second decryption key according to D12 and D22. The auditing party will send D21 to the audited party only when receiving the description information of the encrypted data sent by the audited party. The audited party can generate the first decryption key according to D11 and D21. The audited party can decrypt the encrypted data according to the generated first decryption key and the second decryption key.

[0066] The embodiment provides a generation method of a decryption key. Since the audited party can obtain part of the key data and generate the decryption key only when sending the description information of the encrypted data to the auditing party, the subsequent data user can determine the authenticity of the data according to the description information of the encrypted data.

[0067] Step 206, decrypt the encrypted data based on the generated decryption key, and send the decrypted data to the data user, so that the data user recognizes the authenticity of the decrypted data in the case that the description information of the decrypted data matches the description information of the encrypted data.

[0068] In the case that the description information of the decrypted data matches the description information of the encrypted data, the data user can determine that the audited party has not tampered with the encrypted data, thereby recognizing the authenticity of the decrypted data.

[0069] In an embodiment, the method further comprises: the data user obtains the description information of the encrypted data from the auditing party, and compares the description information of the decrypted data with the description information of the encrypted data; or the data user sends the description information of the decrypted data to the auditing party, so that the auditing party compares the description information of the decrypted data with the description information of the encrypted data, and receives the comparison result returned by the auditing party.

[0070] As mentioned before, in different scenarios, the data user corresponds to different business systems, for example: in the salary email authentication scenario, the data user 14 can be the financial system of the user company; in the freight scenario, the data user 14 can be the server corresponding to the supplier.

[0071] The following will be described in detail Figure 5 the process of verifying the authenticity of data in the email authentication scenario, Figure 5 is a schematic diagram of email authentication provided by an exemplary embodiment, as Figure 5 shown, the data source 501 can be the server corresponding to the email system, the audited party 502 can be the email client corresponding to the user, the auditing party 505 can be the third-party notary platform, and the financial system 508 can be the data user. The audited party 502 includes the email interface 503 opened by the user and the authentication plug-in 504 set on the email server, and the auditing party 505 includes the TLSNotary backend 506 and the verification module 507.

[0072] Before data transmission, the data source 501 has carried out key negotiation with the audited party 502 and the auditing party 505, and generates an encryption key. The data source 501 can encrypt the mail using the encryption key when the user account receives the mail, and send the encrypted mail to the mail server corresponding to the user. The mail interface 503 can provide the information that a new mail is received to the user, and in the case that the user clicks the mail, the audited party 502 can send a key data acquisition request (the key data acquisition request includes the hash value of the encrypted mail) to the TLSNotary backend 506 through the right verification plug-in 504 to generate a decryption key, and decrypt the encrypted mail according to the decryption key. The decrypted mail will be displayed on the mail interface 503. The user can choose to send the decrypted mail to the financial system 508 to notify the corresponding company financial user of the monthly salary. After receiving the decrypted mail, the financial system 508 can send the decrypted mail to the verification module 507 in the auditing party 505. The verification module 507 can obtain the hash value of the encrypted mail from the TLSNotary backend 506, and compare the two hash values in the case that the hash value of the decrypted mail is calculated. If the hash value of the encrypted mail is consistent with the hash value of the decrypted mail, the verification is passed to the financial system 508; if the hash value of the encrypted mail is inconsistent with the hash value of the decrypted mail, the verification fails to the financial system 508. In the case that the financial system 508 receives the verification, the corresponding salary on the mail is paid to the user; in the case that the financial system 508 receives the verification, the user is reminded that the authenticity of the mail is doubtful.

[0073] The embodiment provides a method for verifying the authenticity of the mail, so that the financial system can determine the authenticity of the salary mail sent by the user through the third-party notarization platform, thereby ensuring that the user will not tamper with the salary mail information privately.

[0074] In an embodiment, the negotiation information in the key negotiation process of the auditing party, the audited party and the data source is shared between the auditing party, the audited party and the data source; the decryption data obtained by decrypting the encrypted data based on the generated decryption key is sent to the data user, so that the data user recognizes the authenticity of the decryption data in the case that the description information of the decryption data matches the description information of the encrypted data, comprising: sending the decryption data and the negotiation information corresponding to the decryption data to the data user, so that the data user recognizes the authenticity of the decryption data in the case that the description information of the decryption data matches the description information of the encrypted data, and the negotiation information of the decryption data matches the negotiation information of the encrypted data.

[0075] The negotiation information in the key negotiation process can include Figure 3Any one or more of the first random number, the second random number, the third random number in the embodiment, or Figure 4a , 4b A, B, C1, etc. in the embodiment. For example: the audited party can send the first random number, the second random number, the third random number and the decrypted data to the data user, and the data user can obtain the description information of the encrypted data and the first random number, the second random number, the third random number in the negotiation process from the audited party. Only in the case that the description information of the decrypted data matches the description information of the encrypted data, and the first random number, the second random number, the third random number sent by the audited party matches the first random number, the second random number, the third random number obtained from the audited party, the data user can recognize the authenticity of the decrypted data.

[0076] Figure 6 is a flowchart of another method for verifying data authenticity provided by an example embodiment, as shown in Figure 2 The method is applied to an audited party and at least includes the following steps:

[0077] Step 602, receiving a key data acquisition request sent by an audited party, wherein the key data acquisition request contains description information of encrypted data.

[0078] As described above, the description information of the encrypted data includes at least one of the following: the hash value of the encrypted data, the encrypted data itself, and the attribute information of the encrypted data.

[0079] Step 604, returning the key data of the decryption key corresponding to the encrypted data to the audited party, so that the audited party uses the key data returned by the audited party to generate a corresponding decryption key, and decrypts the encrypted data based on the generated decryption key, and sends the decrypted data to a data user, so that the data user recognizes the authenticity of the decrypted data in the case that the description information of the decrypted data matches the description information of the encrypted data.

[0080] As described above, the method further includes: receiving the description information of the decrypted data sent by the data user; comparing the description information of the decrypted data with the description information of the encrypted data, and returning the comparison result to the data user.

[0081] As described above, before the audited party obtains the encrypted data from the data source, the method further includes: performing key negotiation with the audited party and the data source, and the key obtained through the negotiation is used to encrypt the data at the data source.

[0082] The negotiation information in the key negotiation process among the auditing party, the audited party and the data source is shared among the auditing party, the audited party and the data source, as described above; the key data of the decryption key corresponding to the encrypted data is returned to the audited party, so that the audited party generates a corresponding decryption key according to the key data returned by the auditing party, and decrypts the encrypted data based on the generated decryption key, and sends the decrypted data to a data user, so that the data user recognizes the authenticity of the decrypted data in the case that the description information of the decrypted data matches the description information of the encrypted data, including: the key data of the decryption key corresponding to the encrypted data is returned to the audited party, so that the audited party generates a corresponding decryption key according to the key data returned by the auditing party, and decrypts the encrypted data based on the generated decryption key, and sends the decrypted data and the negotiation information corresponding to the decrypted data to the data user, so that the data user recognizes the authenticity of the decrypted data in the case that the description information of the decrypted data matches the description information of the encrypted data, and the negotiation information of the decrypted data matches the negotiation information of the encrypted data.

[0083] The key negotiation process among the auditing party, the audited party and the data source is implemented based on a TLSNotary algorithm of a TLS protocol, as described above.

[0084] The present specification also proposes a system for verifying data authenticity, including:

[0085] The audited party is configured to obtain encrypted data from a data source, and send a key data obtaining request to an auditing party, the key data obtaining request containing description information of the encrypted data; receive key data returned by the auditing party in response to the key data obtaining request, and generate a corresponding decryption key according to the key data returned by the auditing party; decrypt the encrypted data based on the generated decryption key, and send the decrypted data obtained by decryption to a data user; the auditing party is configured to receive the key data obtaining request sent by the audited party, and return the key data to the audited party; and the data user is configured to receive the decrypted data sent by the audited party, and recognize the authenticity of the decrypted data in the case that the description information of the decrypted data matches the description information of the encrypted data.

[0086] The description information of the encrypted data includes at least one of the following: a hash value of the encrypted data, the encrypted data itself, and attribute information of the encrypted data, as described above.

[0087] As described above, the generating the decryption key according to the key data returned by the auditor includes: in a case that the returned key data is all key data for generating the decryption key, the auditee generates the decryption key according to all the key data returned by the auditor; in a case that the returned key data is partial key data for generating the decryption key, the auditee generates the decryption key according to the partial key data returned by the auditor and partial key data stored locally.

[0088] As described above, the system further includes: the data user obtains description information of the encrypted data from the auditor, and compares the description information of the decrypted data with the description information of the encrypted data; or, the data user sends the description information of the decrypted data to the auditor, so that the auditor compares the description information of the decrypted data with the description information of the encrypted data, and receives the comparison result returned by the auditor.

[0089] As described above, before the auditee obtains the encrypted data from the data source, the system further includes: the auditor, the auditee and the data source perform key negotiation, and the negotiated key is used to encrypt the data in the data source.

[0090] As described above, the negotiation information in the key negotiation process between the auditor, the auditee and the data source is shared among the auditor, the auditee and the data source; the decrypting the encrypted data based on the generated decryption key and sending the decrypted data to a data user includes: the auditee sends the decrypted data and the negotiation information corresponding to the decrypted data to the data user; the case that the description information of the decrypted data matches the description information of the encrypted data includes: the case that the description information of the decrypted data matches the description information of the encrypted data, and the negotiation information of the decrypted data matches the negotiation information of the encrypted data.

[0091] As described above, the key negotiation process between the auditor, the auditee and the data source is implemented based on a TLSNotary algorithm of a TLS protocol.

[0092] Figure 7 FIG. 1 is a schematic structural diagram of an apparatus provided by an example embodiment. Please refer to Figure 7At the hardware level, the device includes a processor 702, an internal bus 704, a network interface 706, a memory 708, and a non-volatile memory 710, and can also include other hardware required by functions. One or more embodiments of the present specification can be implemented in a software manner, such as reading a corresponding computer program from the non-volatile memory 710 into the memory 708 by the processor 702 and then running. Of course, in addition to the software implementation, one or more embodiments of the present specification do not exclude other implementations, such as logic devices or a combination of software and hardware, and the like, that is, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or a logic device.

[0093] As shown in Figure 8 , Figure 8 is a block diagram of an apparatus for verifying data authenticity provided by an exemplary embodiment, which can be applied to a device as shown in Figure 8 to implement the technical solutions of the present specification; the apparatus applied to the audited party includes:

[0094] The acquisition unit 802 is configured to acquire encrypted data from a data source, and send a key data acquisition request to an auditing party, wherein the key data acquisition request contains description information of the encrypted data;

[0095] The generation unit 804 is configured to receive key data returned by the auditing party in response to the key data acquisition request, and generate a corresponding decryption key according to the key data returned by the auditing party;

[0096] The sending unit 806 is configured to decrypt the encrypted data based on the generated decryption key, and send the decrypted data obtained by decryption to a data user, so that the data user acknowledges the authenticity of the decrypted data in a case where description information of the decrypted data matches the description information of the encrypted data.

[0097] Optionally, the description information of the encrypted data includes at least one of the following: a hash value of the encrypted data, the encrypted data itself, and attribute information of the encrypted data.

[0098] Optionally, the generation unit 804 is specifically configured to:

[0099] In a case where the returned key data is all key data for generating the decryption key, the audited party generates a decryption key according to all key data returned by the auditing party;

[0100] In a case where the returned key data is part of the key data for generating the decryption key, the audited party generates a decryption key according to part of the key data returned by the auditing party and part of the key data stored locally.

[0101] Optionally, before obtaining the encrypted data from the data source, the apparatus further comprises:

[0102] a negotiation unit 808, configured to perform key negotiation with the auditing party and the data source, and the negotiated key is used to encrypt data at the data source.

[0103] Optionally, negotiation information in the key negotiation process of the auditing party, the audited party and the data source is shared among the auditing party, the audited party and the data source.

[0104] The sending unit 806 is specifically configured to send the decrypted data and the negotiation information corresponding to the decrypted data to the data user, so that the data user approves the authenticity of the decrypted data in the case that the description information of the decrypted data matches the description information of the encrypted data, and the negotiation information of the decrypted data matches the negotiation information of the encrypted data.

[0105] Optionally, the key negotiation process of the auditing party, the audited party and the data source is implemented based on the TLSNotary algorithm of the TLS protocol.

[0106] As shown in Figure 9 , Figure 9 is a block diagram of another device for verifying data authenticity provided by an exemplary embodiment, which can be applied to the device as shown in Figure 9 to implement the technical solutions of the present specification; the device is applied to an auditing party and comprises:

[0107] A first receiving unit 902 is configured to receive a key data obtaining request sent by an audited party, and the key data obtaining request contains description information of encrypted data.

[0108] A returning unit 904 is configured to return key data of a decryption key corresponding to the encrypted data to the audited party, so that the audited party generates a corresponding decryption key according to the key data returned by the auditing party, and decrypts the encrypted data based on the generated decryption key, and sends the decrypted data to a data user, so that the data user approves the authenticity of the decrypted data in the case that the description information of the decrypted data matches the description information of the encrypted data.

[0109] Optionally, the description information of the encrypted data comprises at least one of the following: a hash value of the encrypted data, the encrypted data itself, and attribute information of the encrypted data.

[0110] Optionally, further comprising:

[0111] The second receiving unit 906 is configured to receive the description information of the decrypted data sent by the data user.

[0112] The comparison unit 908 is configured to compare the description information of the decrypted data with the description information of the encrypted data, and return a comparison result to the data user.

[0113] Optionally, before the audited party obtains the encrypted data from the data source, the apparatus further comprises:

[0114] The negotiation unit 910 is configured to perform key negotiation with the audited party and the data source, and the negotiated key is used to encrypt the data in the data source.

[0115] Optionally, the returning unit 904 is specifically configured to return the key data of the decryption key corresponding to the encrypted data to the audited party, so that the audited party generates a corresponding decryption key according to the key data returned by the auditing party, and decrypts the encrypted data based on the generated decryption key, and sends the decrypted data and the negotiation information corresponding to the decrypted data to the data user, so that the data user recognizes the authenticity of the decrypted data in the case that the description information of the decrypted data matches the description information of the encrypted data, and the negotiation information of the decrypted data matches the negotiation information of the encrypted data.

[0116] Optionally, the key negotiation process of the auditing party, the audited party and the data source is implemented based on a TLSNotary algorithm of a TLS protocol.

[0117] In the 1990s, it was quite obvious to distinguish whether an improvement in a technology was in hardware (e.g., improvement in circuit structures of diodes, transistors, switches, etc.) or in software (improvement in method flow). However, as technology has evolved, many improvements in method flow today can be considered as direct improvements in hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structures by programming the improved method flow into hardware circuits. Therefore, it cannot be said that an improvement in a method flow cannot be implemented by hardware entity modules. For example, a programmable logic device (PLD) (e.g., a field programmable gate array (FPGA)) is an integrated circuit whose logic function is determined by user programming of the device. A digital system is "integrated" on a PLD by the designer programming it, rather than by asking a chip manufacturer to design and fabricate a custom integrated circuit chip. Moreover, instead of manually fabricating integrated circuit chips, this programming is now mostly implemented by "logic compiler" software, which is similar to software compilers used in program development, and the original code to be compiled is written in a specific programming language, which is called a hardware description language (HDL), and there are many such languages, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., and the most commonly used are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should be aware that, as long as the method flow is logically programmed in the above-mentioned hardware description languages and programmed into an integrated circuit, a hardware circuit implementing the logical method flow can be easily obtained.

[0118] The controller can be implemented in any suitable way, for example, the controller can take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code, such as software or firmware, executable by the (micro)processor, logic gates, switches, an application specific integrated circuit (ASIC), a programmable logic controller and an embedded microcontroller, examples of which include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20 and Silicone Labs C8051F320, the memory controller can also be implemented as part of the control logic of the memory. The skilled person will also appreciate that, in addition to implementing the controller in pure computer readable program code, it is possible to implement the controller in the form of logic gates, switches, an application specific integrated circuit, a programmable logic controller and an embedded microcontroller, etc. to perform the same functions by logically programming the method steps. Such a controller can therefore be considered to be a hardware component, and the means included therein to perform the various functions can also be considered to be structures within the hardware component. Alternatively, or even additionally, the means to perform the various functions can be considered to be both a software module implementing the method and a structure within a hardware component.

[0119] The systems, apparatuses, modules or units illustrated by the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, the present application does not exclude that with the development of computer technology in the future, computers implementing the functions of the above embodiments can be personal computers, laptop computers, vehicle human-computer interaction devices, cellular phones, camera phones, smart phones, personal digital assistants, media players, navigation devices, email devices, game consoles, tablet computers, wearable devices, or combinations of any of these devices.

[0120] Although the method operations of the embodiments of the present specification are described in sequential order, some of the operations can in practical implementations be performed concurrently, in parallel, or in a different order. The above described embodiments of the present specification are meant to be illustrative only and not limiting. Many variations of the above described embodiments of the present specification can become apparent to those of skill in the art in view of the above teachings. For example, while the embodiments of the present specification have been described with respect to the use of a computer-based system for implementing the methods and techniques described herein, those skilled in the art will recognize the implementation of the present specification can be implemented using hardware, software, firmware, or some combination of hardware, software, and firmware. Embodiments of the present specification can also be implemented as "hard-wired" devices that perform the steps or functionality described herein. Embodiments of the present specification can also be implemented using a combination of software and hardware. Embodiments of the present specification can also be implemented as a computer program product, which can include a computer-readable medium having stored computer program code means. The computer-readable medium can be a machine-readable storage

[0121] For the sake of description, the above-described apparatuses are described in functional modules for convenience. Of course, when implementing one or more of the present specification, the functions of each module can be implemented in one or more software and / or hardware, or the modules implementing the same function can be implemented by a combination of sub-modules or sub-units. The above-described apparatus embodiment is only illustrative, for example, the division of the units is only a logical function division, and actual implementation can have another division manner, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the displayed or discussed each other can be indirect coupling or communication connection through some interface, device or unit, and can be electrical, mechanical or other forms.

[0122] The present application is described with reference to flowcharts and / or block diagrams of the methods, apparatus (system) and computer program products according to embodiments of the present application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and a combination of flows and / or blocks in the flowcharts and / or block diagrams can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing apparatus to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing apparatus produce a means for implementing the functions specified in the flowcharts and / or block diagrams. Figure 1 The functions specified in a flow or multiple flows and / or blocks Figure 1 The apparatus for implementing the functions specified in a flow or multiple flows and / or blocks.

[0123] These computer program instructions can also be stored in a computer- readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the Figure 1 function specified in the flow or flows and / or blocks Figure 1 of the block or blocks.

[0124] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the Figure 1 function specified in the flow or flows and / or blocks Figure 1 of the block or blocks.

[0125] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0126] The memory can include non-persistent memory and / or volatile memory, such as random access memory (RAM) and / or cache memory, non-volatile memory, such as read-only memory (ROM), EPROM, and / or flash memory. The memory is an example of computer-readable media.

[0127] Computer-readable media includes permanent and non-permanent, moveable and non- moveable media that can be implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile discs (DVDs) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, graphene storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible to computing devices. According to the definition herein, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.

[0128] Those skilled in the art will appreciate that the one or more embodiments described herein can be provided as a method, a system or a computer program product. Accordingly, the one or more embodiments described herein can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the one or more embodiments described herein can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROMs, optical storage devices, etc.) embodying computer readable code.

[0129] The one or more embodiments described herein can be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. The one or more embodiments described herein can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote computer storage media including memory storage devices.

[0130] The various embodiments described in this specification can be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. The various embodiments described in this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote computer storage media including memory storage devices.

[0131] The above description is only some embodiments of the one or more embodiments described in this specification and is not intended to limit the one or more embodiments described in this specification. Those skilled in the art can make various modifications and changes to the one or more embodiments described in this specification. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the one or more embodiments described in this specification shall be included in the scope of the claims.

Claims

1. A system for verifying the authenticity of data, the system comprising: The auditee is used to obtain encrypted data from the data source and send a key data acquisition request to the auditor, wherein the key data acquisition request contains descriptive information of the encrypted data; The system receives key data returned by the auditing party in response to the key data acquisition request, and generates a corresponding decryption key based on the key data returned by the auditing party; it decrypts the encrypted data based on the generated decryption key, and sends the decrypted data and the corresponding negotiation information to the data user; the description information of the encrypted data includes a hash value. The auditing party is configured to receive a key data acquisition request sent by the auditee and return the key data to the auditee. The data user is configured to receive decrypted data sent by the auditee, and to recognize the authenticity of the decrypted data if the description information of the decrypted data matches the description information of the encrypted data and the negotiation information of the decrypted data matches the negotiation information of the encrypted data. In this process, the auditing party, the auditee, and the data source conduct a three-party key negotiation before data encryption. The negotiated key is used to encrypt the data at the data source. The negotiation information during the key negotiation process is shared among the three parties. The negotiation information for the encrypted data is obtained from the auditing party. The negotiation information includes random numbers and key generation parameters during the key negotiation process.

2. The system according to claim 1, wherein the description information of the encrypted data further includes at least one of the following: the encrypted data itself, and the attribute information of the encrypted data.

3. The system according to claim 1, wherein generating the corresponding decryption key based on the key data returned by the auditing party includes: If the returned key data is all the key data used to generate the decryption key, the auditee generates the decryption key based on all the key data returned by the auditor. If the returned key data is a partial key data for generating the decryption key, the auditee generates the decryption key based on the partial key data returned by the auditor and the partial key data stored locally.

4. The system according to claim 1, further comprising: The data user obtains the description information of the encrypted data from the reviewer and compares the description information of the decrypted data with the description information of the encrypted data.

5. In the system according to claim 1, the key negotiation process between the auditor, the auditee, and the data source is implemented based on the TLSNotary algorithm of the TLS protocol.

6. A method for verifying the authenticity of data, applied to the auditee, the method comprising: The encrypted data is obtained from the data source, and a key data retrieval request is sent to the auditor. The key data retrieval request includes a description of the encrypted data, which includes a hash value. Receive the key data returned by the auditing party in response to the key data acquisition request, and generate the corresponding decryption key based on the key data returned by the auditing party; The encrypted data is decrypted based on the generated decryption key, and the decrypted data and the corresponding negotiation information are sent to the data user so that the data user can recognize the authenticity of the decrypted data if the description information of the decrypted data matches the description information of the encrypted data and the negotiation information of the decrypted data matches the negotiation information of the encrypted data. In this process, the auditing party, the auditee, and the data source conduct a three-party key negotiation before data encryption. The negotiated key is used to encrypt the data at the data source. The negotiation information during the key negotiation process is shared among the three parties. The negotiation information for the encrypted data is obtained from the auditing party. The negotiation information includes random numbers and key generation parameters during the key negotiation process.

7. The method according to claim 6, wherein the description information of the encrypted data further includes at least one of the following: the encrypted data itself, and the attribute information of the encrypted data.

8. The method according to claim 6, wherein generating the corresponding decryption key based on the key data returned by the auditing party includes: If the returned key data is all the key data used to generate the decryption key, the auditee generates the decryption key based on all the key data returned by the auditor. If the returned key data is a partial key data for generating the decryption key, the auditee generates the decryption key based on the partial key data returned by the auditor and the partial key data stored locally.

9. The method according to claim 6, wherein the key negotiation process between the auditor, the auditee, and the data source is implemented based on the TLSNotary algorithm of the TLS protocol.

10. A method for verifying the authenticity of data, applied by an auditor, the method comprising: Receive a key data retrieval request sent by the auditee, wherein the key data retrieval request contains description information of encrypted data; the description information of the encrypted data includes a hash value; The key data of the decryption key corresponding to the encrypted data is returned to the auditee, so that the auditee can: generate a corresponding decryption key based on the key data returned by the auditee, decrypt the encrypted data based on the generated decryption key, and send the decrypted data and the negotiation information corresponding to the decrypted data to the data user, so that the data user can recognize the authenticity of the decrypted data if the description information of the decrypted data matches the description information of the encrypted data and the negotiation information of the decrypted data matches the negotiation information of the encrypted data; Specifically, before the auditee obtains encrypted data from the data source, the auditor, the auditee, and the data source conduct a three-party key negotiation before data encryption. The negotiated key is used to encrypt the data at the data source, and the negotiation information during the key negotiation process is shared among the three parties. The negotiation information for the encrypted data is obtained from the auditor. The negotiation information includes random numbers and key generation parameters from the key negotiation process.

11. The method according to claim 10, wherein the description information of the encrypted data further includes at least one of the following: the encrypted data itself, and the attribute information of the encrypted data.

12. The method of claim 10, further comprising: Receive description information of the decrypted data sent by the data user; The description information of the decrypted data is compared with the description information of the encrypted data, and the comparison result is returned to the data user.

13. The method according to claim 10, wherein the key negotiation process between the auditing party, the auditee, and the data source is implemented based on the TLSNotary algorithm of the TLS protocol.

14. An apparatus for verifying the authenticity of data, applied to an auditee, the apparatus comprising: Acquisition Unit: Acquires encrypted data from the data source and sends a key data acquisition request to the auditor. The key data acquisition request includes descriptive information of the encrypted data, including a hash value. Generation unit: Receives key data returned by the auditing party in response to the key data acquisition request, and generates a corresponding decryption key based on the key data returned by the auditing party; Sending unit: Decrypts the encrypted data based on the generated decryption key, and sends the decrypted data and the corresponding negotiation information to the data user, so that the data user recognizes the authenticity of the decrypted data if the description information of the decrypted data matches the description information of the encrypted data and the negotiation information of the decrypted data matches the negotiation information of the encrypted data; In this process, the auditing party, the auditee, and the data source conduct a three-party key negotiation before data encryption. The negotiated key is used to encrypt the data at the data source. The negotiation information during the key negotiation process is shared among the three parties. The negotiation information for the encrypted data is obtained from the auditing party. The negotiation information includes random numbers and key generation parameters during the key negotiation process.

15. An apparatus for verifying the authenticity of data, used by an auditor, the apparatus comprising: First receiving unit: receives a key data acquisition request sent by the auditee, wherein the key data acquisition request includes description information of encrypted data; The description information of the encrypted data includes a hash value; Return Unit: Returns the key data of the decryption key corresponding to the encrypted data to the auditee, so that the auditee can: generate a corresponding decryption key based on the key data returned by the auditee, decrypt the encrypted data based on the generated decryption key, and send the decrypted data and the negotiation information corresponding to the decrypted data to the data user, so that the data user can recognize the authenticity of the decrypted data if the description information of the decrypted data matches the description information of the encrypted data and the negotiation information of the decrypted data matches the negotiation information of the encrypted data; Specifically, before the auditee obtains encrypted data from the data source, the auditor, the auditee, and the data source conduct a three-party key negotiation before data encryption. The negotiated key is used to encrypt the data at the data source, and the negotiation information during the key negotiation process is shared among the three parties. The negotiation information for the encrypted data is obtained from the auditor. The negotiation information includes random numbers and key generation parameters from the key negotiation process.

16. An electronic device comprising: processor; Memory used to store processor-executable instructions; The processor implements the method as described in any one of claims 6-13 by executing the executable instructions.

17. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 6-13.

Images