Integrity verification method, device, terminal equipment and verification server

Abstract

The present application is applicable to the field of terminal technology, and in particular to an integrity verification method, device, terminal equipment and verification server. The method obtains the file to be verified sent by the file server and the integrity verification information of the file to be verified, and the integrity verification information includes the root node signature information obtained by signing the target root node of the target hash tree using the first signature private key, the child node related to the file to be verified in the target hash tree, and the first signature public key corresponding to the first signature private key, the target hash tree is a hash tree constructed according to all files in the file server; the root node signature information is verified using the first signature public key; when the root node signature information is verified, the current root node corresponding to the target hash tree is constructed according to the file to be verified and the child node, and the integrity of the file to be verified is verified according to the current root node and the target root node, so as to solve the problem that all files need to be signed separately, resulting in a large amount of calculation.

Description

Technical Field

[0001] The present application belongs to the field of terminal technology, and in particular relates to an integrity verification method, apparatus, terminal equipment, verification server and computer-readable storage medium. Background Art

[0002] Integrity check refers to the technical means of checking the accuracy of files to detect whether the files have been illegally tampered with. With the continuous development of network technology, files downloaded or applied by terminal devices are easily tampered with illegally. Therefore, how to check the integrity of downloaded files or application files of terminal devices has become a problem that needs to be solved urgently by technical personnel in this field.

[0003] In the prior art, hash values ​​can be calculated for all files in advance, and each hash value can be signed and saved, so that the integrity of the file can be verified based on the saved signature results. This method of signing all files separately requires a large number of signature operations, which greatly increases the amount of calculation. Summary of the invention

[0004] The embodiments of the present application provide an integrity verification method, apparatus, terminal device, verification server and computer-readable storage medium, which can solve the problem that all files need to be signed separately in the existing integrity verification, resulting in a large amount of calculation.

[0005] In a first aspect, an embodiment of the present application provides an integrity verification method, which is applied to a terminal device. The integrity verification method includes:

[0006] Obtaining a file to be verified sent by a file server and integrity verification information of the file to be verified, wherein the integrity verification information includes root node signature information obtained by signing a target root node of a target hash tree using a first signature private key, child nodes related to the file to be verified in the target hash tree, and a first signature public key corresponding to the first signature private key, wherein the target hash tree is a hash tree constructed according to all files in the file server;

[0007] Using the first signature public key to verify the root node signature information;

[0008] When the root node signature information is verified, a current root node corresponding to the target hash tree is constructed according to the file to be verified and the child node;

[0009] The integrity of the file to be verified is verified according to the current root node and the target root node.

[0010] In the embodiment of the present application, a hash tree and a hash tree root node signature are used to perform integrity verification on the downloaded files of the terminal device, so that the integrity verification can be completed by only signing the root node without signing each file, which greatly reduces the calculation amount of the signature and alleviates the calculation burden.

[0011] In a possible implementation manner of the first aspect, after verifying the integrity of the file to be verified according to the current root node and the target root node, the method includes:

[0012] Obtaining target version verification information of the file to be verified, wherein the target version verification information is version verification information generated according to the target file version of the file to be verified;

[0013] The version validity of the file to be verified is verified according to the current file version of the file to be verified and the target version verification information.

[0014] Here, by requesting the integrity check and the version validity check separately, the real version of the file to be checked can be verified in a cryptographically secure manner to reduce the risk of file replacement and replay attacks.

[0015] Optionally, the target version verification information is chameleon signature information generated according to the target file version and the device identification of the terminal device;

[0016] Verifying the version legitimacy of the file to be verified according to the current file version of the file to be verified and the target version verification information includes:

[0017] Calculate a first chameleon hash value of the current file version according to a device private key corresponding to the terminal device and a chameleon random number in the chameleon signature information;

[0018] Calculate a second chameleon hash value corresponding to the chameleon signature information using the second signature public key in the chameleon signature information;

[0019] The version legitimacy of the file to be verified is verified according to the first chameleon hash value and the second chameleon hash value.

[0020] It should be understood that the target file version is signed by the Chameleon signature algorithm to utilize the non-repudiation, non-interaction and non-transferability of the Chameleon signature to ensure the unique legitimacy of the version information and reduce the risk of leakage.

[0021] Specifically, before calculating the first chameleon hash value of the current file version according to the device private key corresponding to the terminal device and the chameleon random number in the chameleon signature information, it includes: acquiring the device private key corresponding to the terminal device according to the device identifier.

[0022] For example, the embodiments of the present application can also generate the target version verification information corresponding to the file to be verified by generating a version hash tree and signing the root node of the version hash tree.

[0023] In a possible implementation manner of the first aspect, obtaining target version verification information of the file to be verified includes:

[0024] Obtain target version verification information of the file to be verified sent by the verification server, where the target version verification information is version verification information generated by the verification server according to the target file version of the file to be verified sent by the file server and the device identifier of the terminal device receiving the file to be verified.

[0025] Here, risk sharing can be achieved by generating target version verification information of the file to be verified by the verification server, thereby reducing the risk of the target version verification information being attacked.

[0026] Specifically, the target hash tree is a ternary hash tree, so as to reduce the level of the hash tree through the ternary hash tree, reduce the integrity check information required for the integrity check, and reduce the bandwidth occupation.

[0027] In a second aspect, an embodiment of the present application provides an integrity verification method, which is applied to a verification server, and the integrity verification method includes:

[0028] Acquire integrity verification information of each terminal device, where the integrity verification information includes initial root node signature information obtained by signing an initial root node of an initial hash tree using a first signature private key and a first signature public key corresponding to the first signature private key;

[0029] Verifying the initial root node signature information using the first signature public key;

[0030] When the signature information of the initial root node is verified, a target hash tree is constructed according to the initial root node;

[0031] Obtaining a local root node of the local hash tree and a target root node of the target hash tree;

[0032] The integrity of each of the terminal devices is verified according to the local root node and the target root node.

[0033] In the embodiment of the present application, the integrity of the terminal device is checked by using a hash tree and a hash tree root node signature, so that the terminal device and the verification server only need to sign the root node of the relevant hash tree instead of signing each file, which greatly reduces the amount of calculation of the terminal device and the verification server and alleviates the calculation burden of the terminal device and the verification server.

[0034] Optionally, the initial hash tree includes a first-level initial hash tree and a second-level initial hash tree, and the initial root node is the root node of the second-level initial hash tree;

[0035] The first-level initial hash tree is a hash tree constructed by each of the terminal devices according to each of the target files in the terminal devices;

[0036] The secondary initial hash tree is a hash tree constructed by each aggregation gateway according to each primary initial hash tree corresponding to each aggregation gateway.

[0037] Specifically, the process of the aggregation gateway constructing the secondary initial hash tree includes:

[0038] Obtaining a second signature public key sent by each of the terminal devices;

[0039] Using each of the second signature public keys respectively to verify the primary root node signature information sent by each of the terminal devices;

[0040] When the signature information of each of the first-level root nodes is verified, the second-level initial hash tree is constructed according to the first-level initial root node of each of the first-level initial hash trees.

[0041] It should be noted that when constructing the first-level initial hash tree, the terminal device can first sort the target files in the terminal device according to the first preset sorting method, and then construct the leaf nodes of the first-level initial hash tree corresponding to the terminal device according to the sorted target files. Here, the first preset sorting method can be a sorting method according to the ascending order of the first letter of the file name f_req (a→z), or a sorting method according to the descending order of the first letter of the file name f_req (z→a).

[0042] For example, when constructing the secondary initial hash tree, the aggregation gateway may first sort the terminal devices corresponding to the aggregation gateway according to the second preset sorting method, and then construct the secondary initial hash tree corresponding to the aggregation gateway according to the first-level initial root node of the first-level initial hash tree corresponding to the sorted terminal devices. Here, the second preset sorting method may be a sorting method from small to large according to the device identification (such as ID number) of the terminal device, or may be a sorting method from large to small according to the device identification (such as ID number) of the terminal device.

[0043] Here, by transferring most of the signature verification processes to the aggregation gateway, the computational workload of the verification server can be effectively reduced, alleviating the computational burden of the verification server.

[0044] Optionally, before obtaining the local root node of the local hash tree, the method includes:

[0045] Acquire a request file sent by the file server, wherein the request file is a file requested by each of the terminal devices from the file server;

[0046] Constructing a first-level local hash tree corresponding to each of the terminal devices according to the request file, and obtaining a first-level local root node of each of the first-level local hash trees;

[0047] Constructing a secondary local hash tree corresponding to each of the aggregation gateways according to each of the primary local root nodes, and obtaining a secondary local root node of each of the secondary local hash trees;

[0048] The local hash tree is constructed according to each of the secondary local root nodes.

[0049] It should be understood that when constructing the first-level local hash tree corresponding to the terminal device, the request file corresponding to the terminal device can be sorted according to the first preset sorting method used in the construction process of the aforementioned first-level initial hash tree, and the first-level local hash tree corresponding to the terminal device can be constructed according to the sorted request file. Similarly, when constructing the second-level local hash tree corresponding to the aggregation gateway, the terminal devices corresponding to the aggregation gateway can be sorted according to the second preset sorting method used in the construction process of the aforementioned second-level initial hash tree, and the second-level local hash tree corresponding to the aggregation gateway can be constructed according to the first-level local root node of the first-level local hash tree corresponding to the sorted terminal device, that is, in the process of constructing the local hash tree and the target hash tree, the root nodes at all levels are sorted by using the same preset sorting method to avoid different hash values ​​caused by different sorting, which affects the integrity verification result.

[0050] Optionally, verifying the integrity of each of the terminal devices according to the local root node and the target root node includes:

[0051] If the local root node is the same as the target root node, a verification result indicating that the integrity check of the terminal device has passed is obtained;

[0052] If the local root node is different from the target root node, a check result indicating that the integrity check of the terminal device fails is obtained, and the local hash tree is compared with the target hash tree;

[0053] According to the comparison result between the local hash tree and the target hash tree, the target terminal device that fails the integrity check is determined.

[0054] Specifically, the local hash tree and the target hash tree are both ternary hash trees, so that the levels of the hash tree can be reduced through the ternary hash tree, the amount of signature calculation can be reduced, and at the same time, the terminal device whose integrity has been damaged can be easily and quickly located.

[0055] In a third aspect, an embodiment of the present application provides an integrity verification device, which is applied to a terminal device, and the integrity verification device includes:

[0056] A file acquisition module, used to acquire a file to be verified sent by a file server and integrity verification information of the file to be verified, wherein the integrity verification information includes root node signature information obtained by signing a target root node of a target hash tree using a first signature private key, child nodes related to the file to be verified in the target hash tree, and a first signature public key corresponding to the first signature private key, wherein the target hash tree is a hash tree constructed according to all files in the file server;

[0057] A signature information verification module, used to verify the root node signature information using the first signature public key;

[0058] A current root node construction module, used to construct a current root node corresponding to the target hash tree according to the file to be verified and the child node when the root node signature information is verified;

[0059] The integrity verification module is used to verify the integrity of the file to be verified based on the current root node and the target root node.

[0060] Optionally, the integrity verification device further includes:

[0061] A version verification information acquisition module is used to obtain target version verification information of the file to be verified, wherein the target version verification information is version verification information generated according to the target file version of the file to be verified;

[0062] The version validity verification module is used to verify the version validity of the file to be verified according to the current file version of the file to be verified and the target version verification information.

[0063] In a possible implementation manner of the third aspect, the target version verification information is chameleon signature information generated according to the target file version and a device identifier of the terminal device;

[0064] The version validity verification module includes:

[0065] A first hash value calculation unit, configured to calculate a first chameleon hash value of the current file version according to a device private key corresponding to the terminal device and a chameleon random number in the chameleon signature information;

[0066] A second hash value calculation unit, configured to calculate a second chameleon hash value corresponding to the chameleon signature information using a second signature public key in the chameleon signature information;

[0067] A version validity verification unit is used to verify the version validity of the file to be verified according to the first chameleon hash value and the second chameleon hash value.

[0068] As an example, the integrity verification device further includes:

[0069] The device private key acquisition module is used to acquire the device private key corresponding to the terminal device according to the device identification.

[0070] Optionally, the version verification information acquisition module is specifically used to obtain target version verification information of the file to be verified sent by the verification server, and the target version verification information is version verification information generated by the verification server based on the target file version of the file to be verified sent by the file server and the device identifier of the terminal device that receives the file to be verified.

[0071] Specifically, the target hash tree is a ternary hash tree.

[0072] In a fourth aspect, an embodiment of the present application provides an integrity verification device, which is applied to a verification server, and the integrity verification device includes:

[0073] An integrity information acquisition module, used to obtain integrity verification information of each terminal device, wherein the integrity verification information includes initial root node signature information obtained by signing an initial root node of an initial hash tree using a first signature private key and a first signature public key corresponding to the first signature private key;

[0074] A signature information verification module, used to verify the initial root node signature information using the first signature public key;

[0075] A hash tree construction module, used to construct a target hash tree according to the initial root node when the signature information of the initial root node is verified;

[0076] A root node acquisition module, used to acquire a local root node of a local hash tree and a target root node of the target hash tree;

[0077] An integrity verification module is used to verify the integrity of each of the terminal devices based on the local root node and the target root node.

[0078] Optionally, the initial hash tree includes a first-level initial hash tree and a second-level initial hash tree, and the initial root node is the root node of the second-level initial hash tree;

[0079] The first-level initial hash tree is a hash tree constructed by each of the terminal devices according to each of the target files in the terminal devices;

[0080] The secondary initial hash tree is a hash tree constructed by each aggregation gateway according to each primary initial hash tree corresponding to each aggregation gateway.

[0081] Specifically, the aggregation gateway includes:

[0082] A signature public key acquisition unit, used to acquire the second signature public key sent by each of the terminal devices;

[0083] A signature information verification unit, used to verify the primary root node signature information sent by each of the terminal devices using each of the second signature public keys;

[0084] The hash tree construction unit is used to construct the second-level initial hash tree according to the first-level initial root node of each of the first-level initial hash trees when the signature information of each of the first-level root nodes is verified.

[0085] In a possible implementation manner of the fourth aspect, the integrity verification device further includes:

[0086] A request file acquisition module, used to acquire a request file sent by the file server, wherein the request file is a file requested by each of the terminal devices from the file server;

[0087] A first-level local hash tree construction module, used to construct a first-level local hash tree corresponding to each of the terminal devices according to the request file, and obtain a first-level local root node of each of the first-level local hash trees;

[0088] A secondary local hash tree construction module, used to construct a secondary local hash tree corresponding to each of the aggregation gateways according to each of the primary local root nodes, and obtain a secondary local root node of each of the secondary local hash trees;

[0089] The local hash tree construction module is used to construct the local hash tree according to each of the secondary local root nodes.

[0090] Optionally, the integrity verification module includes:

[0091] A verification result obtaining unit, configured to obtain a verification result indicating that the integrity check of the terminal device has passed if the local root node is the same as the target root node;

[0092] A hash tree comparison unit, configured to obtain a verification result indicating that the integrity check of the terminal device fails if the local root node is different from the target root node, and compare the local hash tree with the target hash tree;

[0093] The target terminal device determining unit is used to determine the target terminal device that fails the integrity check based on the comparison result of the local hash tree and the target hash tree.

[0094] Specifically, the local hash tree and the target hash tree are both ternary hash trees.

[0095] In a fifth aspect, an embodiment of the present application provides a terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the integrity verification method described in any one of the first aspects above when executing the computer program.

[0096] In a sixth aspect, an embodiment of the present application provides a verification server, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, and when the processor executes the computer program, the integrity verification method described in any one of the second aspects above is performed.

[0097] In a seventh aspect, an embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the integrity verification method described in any one of the first aspect or the second aspect is implemented.

[0098] In an eighth aspect, an embodiment of the present application provides a computer program product. When the computer program product is run on a terminal device, the terminal device executes the integrity verification method described in any one of the above-mentioned first aspects.

[0099] In a ninth aspect, an embodiment of the present application provides a computer program product. When the computer program product runs on a verification server, the verification server executes the integrity verification method described in any one of the first aspects above. BRIEF DESCRIPTION OF THE DRAWINGS

[0100] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0101] Figure 1 is a system schematic diagram of an integrity verification system provided by an embodiment of the present application;

[0102] Figure 2 is a system schematic diagram of an integrity verification system provided by another embodiment of the present application;

[0103] Figure 3 It is a schematic diagram of the structure of a mobile phone to which the integrity verification method provided in an embodiment of the present application is applicable;

[0104] Figure 4 Schematic diagram of software architecture to which the integrity verification method provided in one embodiment of the present application is applicable;

[0105] Figure 5 It is a flowchart of an integrity verification method provided by an embodiment of the present application;

[0106] Figure 5a It is an example diagram of a three-layer target hash tree constructed in an embodiment of the present application;

[0107] Figure 5b This is an example diagram of a hash tree provided in an embodiment of the present application;

[0108] Figure 5c is an example diagram of a hash tree constructed in an embodiment of the present application;

[0109] Figure 6 is a flowchart of an integrity verification method provided by another embodiment of the present application;

[0110] Figure 6a is an example diagram of a hash tree constructed in another embodiment of the present application;

[0111] Figure 7 It is a schematic diagram of the structure of an integrity verification device provided by an embodiment of the present application;

[0112] Figure 8 is a schematic diagram of the structure of an integrity verification device provided by another embodiment of the present application;

[0113] Fig. 9 It is a schematic diagram of the structure of a verification server provided in one embodiment of the present application. DETAILED DESCRIPTION

[0114] In the following description, specific details such as specific system structures, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to prevent unnecessary details from obstructing the description of the present application.

[0115] It should be understood that when used in the present specification and the appended claims, the term "comprising" indicates the presence of described features, wholes, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or combinations thereof.

[0116] It should also be understood that the term “and / or” used in the specification and appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes these combinations.

[0117] As used in the specification and appended claims of this application, the term "if" can be interpreted as "when" or "uponce" or "in response to determining" or "in response to detecting", depending on the context. Similarly, the phrase "if it is determined" or "if [described condition or event] is detected" can be interpreted as meaning "uponce it is determined" or "in response to determining" or "uponce [described condition or event] is detected" or "in response to detecting [described condition or event]", depending on the context.

[0118] In addition, in the description of the present application specification and the appended claims, the terms "first", "second", "third", etc. are only used to distinguish the descriptions and cannot be understood as indicating or implying relative importance.

[0119] References to "one embodiment" or "some embodiments" etc. described in the specification of this application mean that one or more embodiments of the present application include specific features, structures or characteristics described in conjunction with the embodiment. Therefore, the statements "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments", etc. that appear in different places in this specification do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized in other ways.

[0120] With the continuous development of electronic technology, the clustering and distribution trend of computer systems is constantly increasing. In a complex network system, a large number of terminal devices cooperate and work together. When any terminal device is attacked by a network attack, it will affect the security of itself and the entire network system. Therefore, it is imperative to verify the integrity of important files such as key configurations, patches, executable files, etc. of the terminal device. Among them, the files may include downloaded files of the terminal device and application files in the terminal device. Here, the downloaded file refers to the file that the terminal device has just downloaded from the file server and has not yet been applied. The application file refers to the file that is running or in use on the terminal device.

[0121] In the prior art, hash values ​​are generally calculated for all files in advance, and each hash value is signed and saved, so that the file integrity is verified according to the saved signature results. This method of signing all files separately requires the server or terminal device to perform a large number of signature operations, which greatly increases the calculation amount of the server or terminal device, resulting in a heavy calculation burden on the server or terminal device.

[0122] To solve the above problems, the embodiments of the present application provide an integrity verification method, an integrity verification device, an integrity verification system, a terminal device, a verification server and a computer-readable storage medium. Integrity verification can be performed by using a hash tree and signing only the root node of the hash tree. There is no need to sign each file, which can reduce the amount of calculation of the server or terminal device and alleviate the calculation burden of the server or terminal device.

[0123] like Figure 1 As shown, in the application scenario of performing integrity verification on the downloaded files of the terminal device, the integrity verification system provided by the embodiment of the present application may include a terminal device 10, a file server 11, a verification server 12 and a key management server 13. Among them, the terminal device 10 can be communicated with the file server 11, the verification server 12, and the key management server 13 respectively. The file server 11 can also be communicated with the verification server 12 and the key management server 13 respectively. The verification server 12 can also be communicated with the key management server 13. The key management server 13 can distribute corresponding signature keys to the terminal device 10, the file server 11, the verification server 12, etc.

[0124] Here, the file server 11 may construct a target hash tree corresponding to all files in the file server 11 in advance, and may send the root node of the target hash tree to the verification server 12 for signing. The verification server 12 may sign the root node of the target hash tree by obtaining the signature private key from the key management server 13, and may return the signature result and the signature public key to the file server 11. When the file server 11 sends a certain file to the terminal device 10 based on the file acquisition request of the terminal device 10, it may also send the integrity verification information corresponding to the file (including the signature result, the signature public key, and the child nodes related to the file in the target hash tree) to the terminal device 10. After the terminal device 10 obtains the file and the integrity verification information, it may first verify the signature result according to the signature public key. When the signature result is verified, the current root node corresponding to the target hash tree may be constructed according to the file and the child nodes in the integrity verification information; then, the current root node may be compared with the root node of the target hash tree contained in the signature result to determine the integrity of the file.

[0125] It is understandable that the operation of signing the root node of the target hash tree may also be performed by the file server 12 itself.

[0126] From the above, it can be seen that when performing integrity verification on the downloaded files of the terminal device, the verification server or file server only needs to sign the root node of the target hash tree, without signing each file, which greatly reduces the amount of calculation of the verification server or file server and alleviates the calculation burden of the verification server or file server.

[0127] like Figure 2 As shown, in the scenario of performing integrity check on each terminal device, the integrity check system may further include an aggregation gateway 14. The aggregation gateway 14 may be respectively connected to the terminal device 10, the verification server 12, and the key management server 13. Here, performing integrity check on each terminal device refers to performing integrity check on the application files in each terminal device.

[0128] The verification server 12 may obtain in advance each request file sent by the file server 11 and may construct a local hash tree according to each request file. The request files sent by the file server 11 are files that each terminal device 10 has requested from the file server 11.

[0129] When it is necessary to perform integrity verification on each of the terminal devices 10, the verification server 12 can send an integrity verification request to each of the terminal devices 10. After receiving the integrity verification request, each of the terminal devices 10 can obtain the target file in each of the terminal devices 10 to build the first-level initial hash tree corresponding to each of the terminal devices, and can obtain the first-level initial root node of each first-level initial hash tree; then, the first-level initial root node of each first-level initial hash tree can be signed by obtaining the first signature private key from the key management server 13, and the initial integrity verification information containing the first signature result can be sent to the corresponding aggregation gateway 14. Each of the aggregation gateways 14 can respectively use the corresponding first signature public key to verify the first signature result in each initial integrity check information. After each first signature result is verified, each of the aggregation gateways 14 can build a secondary initial hash tree corresponding to each of the aggregation gateways according to the primary initial root node of each primary initial hash tree; then the secondary initial root node of each secondary initial hash tree can be obtained, and the secondary initial root node of the secondary initial hash tree can be signed by obtaining the second signature private key from the key management server 13, and the integrity check information containing the second signature result can be sent to the verification server 12. The verification server 12 can respectively use the corresponding second signature public key to verify each second signature result in each integrity check information. After each second signature result is verified, the verification server 12 can build a target hash tree according to the secondary initial root node of each secondary initial hash tree, and can compare the target root node of the target hash tree with the local root node of the local hash tree to determine the integrity of each of the terminal devices.

[0130] From the above, it can be seen that when performing integrity verification on the terminal device, the terminal device 10 and the aggregation gateway 14 only need to sign the root node of the relevant hash tree, without signing each file, which greatly reduces the amount of calculation of the terminal device 10 and the aggregation gateway 14 and alleviates the calculation burden of the terminal device 10 and the aggregation gateway 14.

[0131] The terminal device 10 can be a mobile phone, a tablet computer, a wearable device, a vehicle-mounted device, an augmented reality (AR) / virtual reality (VR) device, a laptop computer, an ultra-mobile personal computer (UMPC), a netbook, a personal digital assistant (PDA), and the like. The embodiment of the present application does not impose any limitation on the specific type of the terminal device.

[0132] Take the terminal device 10 as a mobile phone as an example. Figure 3 The block diagram shows a partial structure of a mobile phone provided in an embodiment of the present application. Figure 3 The mobile phone includes: a radio frequency (RF) circuit 310, a memory 320, an input unit 330, a display unit 340, a sensor 350, an audio circuit 360, a wireless fidelity (WiFi) module 370, a processor 380, and a power supply 390. Those skilled in the art will understand that Figure 3 The mobile phone structure shown in the figure does not constitute a limitation on the mobile phone, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0133] Combine the following Figure 3 A detailed introduction to the various components of the mobile phone:

[0134] The RF circuit 310 can be used for receiving and sending signals during information transmission or calls. In particular, after receiving the downlink information of the base station, it is sent to the processor 380 for processing; in addition, the designed uplink data is sent to the base station. Generally, the RF circuit includes but is not limited to an antenna, at least one amplifier, a transceiver, a coupler, a low noise amplifier (Low Noise Amplifier, LNA), a duplexer, etc. In addition, the RF circuit 310 can also communicate with the network and other devices through wireless communication. The above wireless communication can use any communication standard or protocol, including but not limited to Global System of Mobile communication (Global System of Mobile communication, GSM), General Packet Radio Service (General Packet Radio Service, GPRS), Code Division Multiple Access (Code Division Multiple Access, CDMA), Wideband Code Division Multiple Access (Wideband Code Division Multiple Access, WCDMA), Long Term Evolution (Long Term Evolution, LTE)), email, Short Messaging Service (SMS), etc.

[0135] The memory 320 can be used to store software programs and modules. The processor 380 executes various functional applications and data processing of the mobile phone by running the software programs and modules stored in the memory 320. The memory 320 can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc.; the data storage area can store data created according to the use of the mobile phone (such as audio data, a phone book, etc.), etc. In addition, the memory 320 can include a high-speed random access memory, and can also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage devices.

[0136] The input unit 330 can be used to receive input digital or character information, and to generate key signal input related to the user settings and function control of the mobile phone. Specifically, the input unit 330 may include a touch panel 331 and other input devices 332. The touch panel 331, also known as a touch screen, can collect the user's touch operation on or near it (such as the user's operation on the touch panel 331 or near the touch panel 331 using any suitable object or accessory such as a finger, stylus, etc.), and drive the corresponding connection device according to a pre-set program. Optionally, the touch panel 331 may include two parts: a touch detection device and a touch controller. Among them, the touch detection device detects the user's touch orientation, detects the signal brought by the touch operation, and transmits the signal to the touch controller; the touch controller receives the touch information from the touch detection device, converts it into contact coordinates, and then sends it to the processor 380, and can receive and execute commands sent by the processor 380. In addition, the touch panel 331 can be implemented in various types such as resistive, capacitive, infrared, and surface acoustic waves. In addition to the touch panel 331, the input unit 330 may also include other input devices 332. Specifically, other input devices 332 may include but are not limited to one or more of a physical keyboard, function keys (such as volume control keys, switch keys, etc.), a trackball, a mouse, a joystick, etc.

[0137] The display unit 340 can be used to display information input by the user or information provided to the user and various menus of the mobile phone. The display unit 340 may include a display panel 341. Optionally, the display panel 341 may be configured in the form of a liquid crystal display (LCD), an organic light-emitting diode (OLED), etc. Further, the touch panel 331 may cover the display panel 341. When the touch panel 331 detects a touch operation on or near it, it is transmitted to the processor 380 to determine the type of touch event. Subsequently, the processor 380 provides a corresponding visual output on the display panel 341 according to the type of touch event. Although in Figure 3 In the embodiment, the touch panel 331 and the display panel 341 are used as two independent components to realize the input and output functions of the mobile phone, but in some embodiments, the touch panel 331 and the display panel 341 can be integrated to realize the input and output functions of the mobile phone.

[0138] The mobile phone may also include at least one sensor 350, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor and a proximity sensor, wherein the ambient light sensor may adjust the brightness of the display panel 341 according to the brightness of the ambient light, and the proximity sensor may turn off the display panel 341 and / or the backlight when the mobile phone is moved to the ear. As a type of motion sensor, the accelerometer sensor can detect the magnitude of acceleration in all directions (generally three axes), and can detect the magnitude and direction of gravity when stationary. It can be used for applications that identify the posture of the mobile phone (such as horizontal and vertical screen switching, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometer, tapping), etc.; as for other sensors that can be configured in the mobile phone, such as gyroscopes, barometers, hygrometers, thermometers, infrared sensors, etc., they will not be repeated here.

[0139] The audio circuit 360, the speaker 361, and the microphone 362 can provide an audio interface between the user and the mobile phone. The audio circuit 360 can transmit the received audio data to the speaker 361 after converting the electrical signal, which is converted into a sound signal for output; on the other hand, the microphone 362 converts the collected sound signal into an electrical signal, which is received by the audio circuit 360 and converted into audio data, and then the audio data is output to the processor 380 for processing, and then sent to another mobile phone through the RF circuit 310, or the audio data is output to the memory 320 for further processing.

[0140] WiFi is a short-range wireless transmission technology. The mobile phone can help users send and receive emails, browse web pages and access streaming media through the WiFi module 370. It provides users with wireless broadband Internet access. Figure 3A WiFi module 370 is shown, but it is understandable that it is not an essential component of the mobile phone and can be omitted as needed without changing the essence of the invention.

[0141] The processor 380 is the control center of the mobile phone. It uses various interfaces and lines to connect various parts of the entire mobile phone. By running or executing software programs and / or modules stored in the memory 320, and calling data stored in the memory 320, it executes various functions of the mobile phone and processes data, thereby monitoring the mobile phone as a whole. Optionally, the processor 380 may include one or more processing units; preferably, the processor 380 may integrate an application processor and a modem processor, wherein the application processor mainly processes the operating system, user interface, and application programs, and the modem processor mainly processes wireless communications. It is understandable that the above-mentioned modem processor may not be integrated into the processor 380.

[0142] The mobile phone also includes a power supply 390 (such as a battery) for supplying power to various components. Preferably, the power supply can be logically connected to the processor 380 through a power management system, so that the power management system can manage charging, discharging, power consumption and other functions.

[0143] Although not shown, the mobile phone may further include a camera. Optionally, the camera may be located at the front or rear of the mobile phone, which is not limited in the present embodiment.

[0144] Optionally, the mobile phone may include a single camera, a dual camera, or a triple camera, etc., which is not limited in the embodiments of the present application.

[0145] For example, a mobile phone may include three cameras, one for the main camera, one for the wide-angle camera, and one for the telephoto camera.

[0146] Optionally, when the mobile phone includes multiple cameras, all of the cameras may be front-mounted, or all of the cameras may be rear-mounted, or some may be front-mounted and others may be rear-mounted, and this is not limited in the embodiments of the present application.

[0147] In addition, although not shown, the mobile phone may also include a Bluetooth module, etc., which will not be described in detail here.

[0148] Figure 4 Schematic diagram of the software structure of the mobile phone of the embodiment of the present application. Taking the mobile phone operating system as the Android system as an example, in some embodiments, the Android system is divided into four layers, namely the application layer, the application framework layer (framework, FWK), the system layer and the hardware abstraction layer, and the layers communicate with each other through software interfaces.

[0149] like Figure 4As shown, the application layer can be a series of application packages, and the application packages can include short message, calendar, camera, video, navigation, gallery, call and other applications.

[0150] The application framework layer provides an application programming interface (API) and a programming framework for the application programs of the application layer. The application framework layer may include some predefined functions, such as a function for receiving events sent by the application framework layer.

[0151] like Figure 4 As shown, the application framework layer may include a window manager, a resource manager, a notification manager, and the like.

[0152] The window manager is used to manage window programs. The window manager can obtain the display screen size, determine whether there is a status bar, lock the screen, capture the screen, etc. The content provider is used to store and obtain data and make the data accessible to applications. The data may include video, images, audio, calls made and received, browsing history and bookmarks, phone books, etc.

[0153] The resource manager provides various resources for applications, such as localized strings, icons, images, layout files, video files, and so on.

[0154] The notification manager enables applications to display notification information in the status bar. It can be used to convey notification-type messages and can disappear automatically after a short stay without user interaction. For example, the notification manager is used to notify download completion, message reminders, etc. The notification manager can also be a notification that appears in the system top status bar in the form of a chart or scroll bar text, such as notifications of applications running in the background, or a notification that appears on the screen in the form of a dialog window. For example, a text message is displayed in the status bar, a prompt sound is emitted, an electronic device vibrates, an indicator light flashes, etc.

[0155] The application framework layer may also include:

[0156] The view system includes visual controls, such as controls for displaying text, controls for displaying pictures, etc. The view system can be used to build applications. The display interface can be composed of one or more views. For example, a display interface including a text notification icon can include a view for displaying text and a view for displaying pictures.

[0157] The phone manager is used to provide the communication functions of the mobile phone, such as the management of call status (including answering, hanging up, etc.).

[0158] The system layer may include multiple functional modules, such as sensor service module, physical state recognition module, 3D graphics processing library (such as OpenGL ES), etc.

[0159] The sensor service module is used to monitor the sensor data uploaded by various sensors at the hardware layer and determine the physical state of the phone;

[0160] Physical state recognition module, used to analyze and recognize user gestures, faces, etc.;

[0161] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

[0162] The system layer may also include:

[0163] The surface manager is used to manage the display subsystem and provide the fusion of 2D and 3D layers for multiple applications.

[0164] The media library supports playback and recording of a variety of commonly used audio and video formats, as well as static image files, etc. The media library can support a variety of audio and video encoding formats, such as: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc.

[0165] The hardware abstraction layer is a layer between hardware and software. The hardware abstraction layer can include display drivers, camera drivers, sensor drivers, etc., which are used to drive related hardware of the hardware layer, such as display screens, cameras, sensors, etc.

[0166] [Example 1]

[0167] The integrity verification method provided in the first embodiment can be implemented on a mobile phone with the above hardware structure / software structure to perform integrity verification on the downloaded files of the mobile phone. That is, after the mobile phone downloads a file from the file server, it can perform integrity verification on the file by using the integrity verification method provided in this embodiment before applying the file to ensure that the file downloaded by the mobile phone is not tampered with, the version is legal, and the source is traceable. Figure 1 The integrity verification system shown provides a detailed description of the integrity verification method provided in this embodiment.

[0168] like Figure 5 As shown, the integrity verification method provided in this embodiment may include:

[0169] S501, obtaining a file to be verified and integrity verification information of the file to be verified sent by a file server, wherein the integrity verification information includes root node signature information obtained by signing a target root node of a target hash tree using a first signature private key, child nodes related to the file to be verified in the target hash tree, and a first signature public key corresponding to the first signature private key, wherein the target hash tree is a hash tree constructed based on all files in the file server;

[0170] It should be understood that when a file server is initialized or a file is updated, the file server can construct a target hash tree corresponding to all files in the file server, and can sign the target root node of the target hash tree to obtain the root node signature information corresponding to the target root node.

[0171] For example, the file server may also send the target root node of the target hash tree to the verification server, and the verification server may sign the target root node, and may return the root node signature information obtained by the signature and the signature public key corresponding to the signature to the file server, so as to achieve the purpose of separating the generation and signature of the target root node and reduce the risk of the root node signature information being attacked.

[0172] It should be noted that the file server or the verification server can sign the target root node by obtaining a signature key (including a first signature private key and a first signature public key) from a key management server. Specifically, the target root node can be signed by the first signature private key. Here, the signature key can be a signature key corresponding to any signature algorithm, which is not limited in this embodiment.

[0173] For example, the signature key may be a signature key corresponding to an RSA signature algorithm. Assuming that the first signature private key corresponding to the RSA signature algorithm is d and the first signature public key is (e, n), the root node signature information of the target root node H_root may be sign(H_root)=(H_root) d mod n.

[0174] It should be understood that when signing the target root node, signature validity period information can also be added to shorten the validity period of the root node signature information, reduce the attack time window of the root node signature information being attacked, and reduce the risk of the root node signature information being attacked.

[0175] In a possible implementation, the target hash tree may be a ternary hash tree, so as to reduce the levels of the hash tree through the ternary hash tree, reduce the integrity check information required for the integrity check, and reduce bandwidth usage.

[0176] As an example but not limitation, the leaf node of the target hash tree can be the hash value of the file name of any file in the file server and the file metadata of the file, and other nodes except the leaf node can be the hash values ​​of all child nodes of the node.

[0177] For example, Figure 5a An example diagram of a three-layer target hash tree constructed by the file server is shown, in which a leaf node H_leaf of one layer in the three-layer target hash tree is i It can be H(f_i||matadata i ), the second-level child node H_father j Can be H(H_leaf i-1 ||H_leaf i ||H_leaf i+1 ), where H_leaf i-1 、H_leaf i and H_leaf i+1 For H_father j The target root node H_root of the third layer can be H(H_father1||H_father2||H_father3). Here, f_i is the file name, and matadadata i is metadata, || is a connector, and H is a hash function. It should be understood that the hash function may be a secure hash function (such as SHA-256) or any other type of hash function, which is not limited in this embodiment.

[0178] It should be understood that when the mobile phone sends a file acquisition request to the file server to request a certain file, or when the file server sends a file update instruction of a certain file to the mobile phone, and the mobile phone confirms to update the file according to the file update instruction, the file server can send the file to the mobile phone, and can send the integrity verification information corresponding to the file to the mobile phone. Here, the file obtained by the mobile phone is the file to be verified in S601.

[0179] It is understandable that the integrity check information may include the signature information of the root node of the target hash tree corresponding to the file to be checked, the child nodes in the target hash tree related to the file to be checked, and the first signature public key. The root node signature information is the information after the file server or the verification server signs the root node of the target hash tree using the first signature private key, and the first signature public key corresponds to the first signature private key. The child nodes in the target hash tree related to the file to be checked may include the child nodes in the target hash tree that belong to the same parent node H_father as the file to be checked. jLeaf node, parent node H_father j The child nodes on the full hash path to the target root node, as well as the target root node.

[0180] Specifically, the parent node H_father j The child nodes on the complete hash path to the target root node are those whose parent node is H_father. j Start generating all child nodes required for the target root node of the target hash tree.

[0181] For example, in Figure 5a In the application scenario shown, when the file f_6 corresponding to H_leaf6 is the file to be verified sent by the file server to the mobile phone, the child nodes on the complete hash path from the parent node H_father2 corresponding to H_leaf6 to the target root node H_root may include H_father1 and H_father3, that is, the child nodes related to the file f_6 to be verified in the target hash tree may include leaf node H_leaf4, leaf node H_leaf5, child node H_father1, child node H_father3 and root node H_root.

[0182] For example, in Figure 5b In the application scenario shown, when the file f_6 corresponding to H_leaf6 is the file to be verified sent by the file server to the mobile phone, the child nodes on the complete hash path from the parent node H_ffather2 corresponding to H_leaf6 to the target root node H_root may include H_ffather1, H_ffather3, H_sfather1, H_sfather3, H_tfather2 and H_tfather3, that is, the child nodes related to the file f_6 to be verified in the target hash tree may include leaf node H_leaf4, leaf node H_leaf5, child node H_ffather1, child node H_ffather3, child node H_sfather1, child node H_sfather3, child node H_tfather2 and child node H_tfather3 and root node H_root.

[0183] S502: Use the first signature public key to verify the root node signature information;

[0184] It should be understood that the integrity verification information obtained by the mobile phone may include the root node signature information and the original information corresponding to the root node signature information (ie, the target root node H_root).

[0185] Here, after the mobile phone obtains the file to be verified and the integrity verification information corresponding to the file to be verified, it can use the first signature public key in the integrity verification information to verify the root node signature information to determine whether the integrity verification information is verification information with a legal source and traceable, thereby determining whether the file to be verified is a file with a legal source and traceable.

[0186] For example, when the first signature public key is (e, n) and the root node signature information of the target root node H_root is sign(H_root)=(H_root) d In the application scenario of mod n, the mobile phone can use the first signature public key (e, n) to verify the signature of sign (H_root) and obtain the signature verification information H'_root = (sign (H_root)) e mod n, in order to determine whether the integrity verification information is from a legitimate and traceable source based on the signature verification information H'_root and the target root node H_root.

[0187] Among them, when the signature verification information H'_root and the target root node H_root are the same, the verification result of the root node signature information verification passing can be obtained, wherein the verification passing indicates that the integrity verification information is verification information with a legal source and traceable, and can be used for the integrity verification of the file to be verified to determine the integrity of the file to be verified and determine whether the file to be verified is a file with a legal source and traceable. When the signature verification information H'_root and the target root node H_root are different, the verification result of the root node signature information verification failing can be obtained, wherein the verification failing indicates that the integrity verification information is not verification information with a legal source and traceable, so that the file to be verified can be directly determined to be a file with an illegal source.

[0188] It should be noted that when the verification result is that the root node signature information verification fails, the mobile phone can record the verification result that the file to be verified is of illegal source in the verification log of the mobile phone to facilitate the subsequent viewing of the verification results. At the same time, the mobile phone can also present the verification results in real time on the display screen of the mobile phone, reminding the user of the mobile phone that the file currently obtained may be of illegal source, and informing the user of the current file download risk.

[0189] S503: When the root node signature information is verified, construct a current root node corresponding to the target hash tree according to the file to be verified and the child node;

[0190] It should be understood that when the root node signature information is verified, that is, when the integrity verification information is of a legitimate and traceable source, the mobile phone can construct the current root node corresponding to the target hash tree based on the file to be verified and the sub-nodes in the integrity verification information.

[0191] For example, when the file to be verified is Figure 5a When the file f_6 corresponding to H_leaf6 shown in the figure is shown, the mobile phone can first calculate the leaf node H'_leaf6=H(f_6||matadata6') corresponding to the file to be verified according to the file name f_6 of the file f_6 and the component metadata matadata6'; then, the child node H'_father2=H(H(f_4||matadata4)||H(f_5||matadata5)||H'(f_6||matadata6)) can be calculated according to H'_leaf6 and the leaf nodes H_leaf4 and H_leaf5 belonging to the same parent node as H'_leaf6 in the integrity verification information; finally, the current root node H'_root=H(H_father1||H'_father2||H_father3) corresponding to the target hash tree can be calculated according to H'_father2 and the child nodes H_father1 and H_father3 on the complete hash path from H'_father2 to the target root node H_root.

[0192] Here, the mobile phone can also restore and construct the target hash tree based on the file to be verified and the child nodes, and then determine the root node of the restored target hash tree as the current root node of the target hash tree, that is, the mobile phone can first calculate the hash value of the file name and file metadata of the file to be verified, and can determine the calculated hash value as the leaf node corresponding to the file to be verified, and then can restore and construct the target hash tree based on the leaf node and the child nodes in the integrity verification information.

[0193] It should be noted that the position of each node in the restored and constructed target hash tree is the same as the position of each node in the original target hash tree, so as to avoid errors in the calculation of hash values ​​due to incorrect node positions, thereby reducing the accuracy of the integrity check. That is, the integrity check information may also include the position information of the leaf nodes corresponding to the file to be checked in the target hash tree and the position information of each child node in the target hash tree. Therefore, when the mobile phone restores and constructs the target hash tree based on the file to be checked and each child node in the integrity check information, it can restore and construct the target hash tree in combination with the position information of the file to be checked and the position information of each child node. For example, when the file to be checked is Figure 5aWhen the file f_6 corresponding to H_leaf6 shown in FIG. 1 is obtained, the mobile phone can construct the following according to the sub-nodes in the file to be verified and the integrity verification information: Figure 5c The target hash tree shown.

[0194] S504: Verify the integrity of the file to be verified according to the current root node and the target root node.

[0195] Specifically, after the mobile phone constructs the current root node corresponding to the target hash tree according to the file to be verified and the child nodes in the integrity verification information, the current root node of the target hash tree can be compared with the target root node of the target hash tree to determine the integrity of the file to be verified. Wherein, when the current root node is the same as the target root node, a verification result that the integrity verification of the file to be verified passes can be obtained, and the integrity verification passes means that the file to be verified is a file obtained from the file server with complete and untampered content, a legitimate source, and traceable; when the current root node is different from the target root node, a verification result that the integrity verification of the file to be verified fails can be obtained, and the integrity verification fails means that the file to be verified is a file with damaged integrity, that is, it can be indicated that the file to be verified is a file with tampered content.

[0196] It should be noted that when the mobile phone obtains a verification result that the integrity check of the file to be verified fails, the mobile phone can record the verification result that the integrity check of the file to be verified fails in the verification log of the mobile phone to facilitate subsequent viewing of the verification results. At the same time, the mobile phone can also present the verification results in real time on the display screen of the mobile phone, reminding the user of the mobile phone that the file currently obtained may be a file with tampered content, and informing the user of the current file download risk.

[0197] In this embodiment, the integrity of the downloaded files of the mobile phone is checked by using a hash tree and signing the root node of the hash tree, so that the integrity check can be completed by only signing the root node without signing each file, which greatly reduces the calculation amount of the signature and alleviates the calculation burden.

[0198] In the integrity check, when there is a historical version of the file to be checked, if the file to be checked with the historical version is used to replace the current version of the file to be checked and sent to the mobile phone, the mobile phone can also obtain the verification result that the integrity check of the file to be checked has passed when performing integrity check on the received file to be checked. However, the file to be checked obtained by the mobile phone at this time is not the file requested by the mobile phone or the file server expects to be sent to the mobile phone, but may be a file re-posted by the attacker. Therefore, in order to resist the replay attack using the historical version file, after verifying the integrity of the file to be checked according to the current root node and the target root node, when the verification result obtained is the verification result that the integrity check of the file to be checked has passed, the mobile phone can also obtain the target version verification information of the file to be checked, and can verify the version legitimacy of the file to be checked according to the current file version of the file to be checked and the target version verification information, wherein the target version verification information can be the version verification information generated according to the target file version of the file to be checked.

[0199] Here, by requesting the integrity check and the version validity check separately, the real version of the file to be checked can be verified in a cryptographically secure manner to reduce the risk of file replacement and replay attacks.

[0200] It should be noted that when the file server sends the file to be verified and the integrity verification information corresponding to the file to be verified to the mobile phone, it can also generate the target version verification information of the file to be verified in real time according to the target file version of the file to be verified sent by it, and can send the target version verification information to the mobile phone based on the version verification information acquisition request sent by the mobile phone.

[0201] Optionally, when the file server sends the file to be verified and the integrity verification information corresponding to the file to be verified to the mobile phone, it can also send the target file version of the file to be verified sent by it to the verification server in real time. The verification server can then generate the target version verification information of the file to be verified based on the target file version, and can send the target version verification information to the mobile phone based on the version verification information acquisition request sent by the mobile phone, so as to share the risk by executing the generation of verification information through the verification server, thereby reducing the risk of the target version verification information being attacked.

[0202] For example, the file server or the verification server may sign the target file version using a signature key corresponding to any signature algorithm, and may use the version signature information corresponding to the target file version obtained by signing as the target version verification information.

[0203] Here, after the mobile phone obtains the verification result that the integrity verification of the file to be verified has passed, it can send a version verification request to the file server or the verification server to determine whether the file to be verified is a replacement file, etc. through version verification. The file server or the verification server can send the version signature information obtained by the aforementioned signature and the corresponding signature public key to the mobile phone according to the version verification request, and the mobile phone can verify the version signature information using the received signature public key, and can compare the verified target file version with the current file version currently received by the mobile phone. If the two are the same, it can be determined that the file to be verified of the current file version is a file with a legal version, that is, it can be considered that the file to be verified of the current file version is a legal file sent by the file server; if the two are not the same, it can be determined that the file to be verified of the current file version is a file with an illegal version, that is, it can be considered that the file to be verified of the current file version may be a replacement file, indicating that the file sent to the mobile phone by the file server may have been replaced by an attacker, etc.

[0204] In one possible implementation, the file server or the verification server may sign the target file version using a chameleon signature algorithm, that is, the target version verification information may be chameleon signature information generated based on the target file version and the device identifier of the terminal device, thereby utilizing the non-repudiation, non-interactivity, and non-transferability characteristics of the chameleon signature to ensure the unique legitimacy of the version information and reduce the risk of leakage.

[0205] For example, when the file server sends the file to be verified and the integrity verification information corresponding to the file to be verified to the mobile phone, it can also use the chameleon signature algorithm to generate in real time the chameleon signature information of the target file version of the sent file to be verified and the device identification of the mobile phone that receives the file to be verified (for example, the device ID or device number of the mobile phone, etc.).

[0206] Optionally, when the file server sends the file to be verified and the integrity verification information corresponding to the file to be verified to the mobile phone, it can also send the target file version of the file to be verified and the device identification of the mobile phone that receives the file to be verified to the verification server in real time. The verification server can then use the chameleon signature algorithm to generate chameleon signature information corresponding to the target file version and the device identification, so as to share risks by executing the chameleon signature operation through the verification server, thereby reducing the risk of the target version verification information being attacked.

[0207] It should be noted that the process of the verification server generating chameleon signature information using the chameleon signature algorithm may specifically be:

[0208] First, two large prime numbers p and q can be randomly selected through the key management server, so that p = kq + 1, and an element of order q can be selected Then the device private key corresponding to the device identifier req_ID can be randomly selected through the key management server Calculate the device public key y corresponding to the device private key x = g x mod p, and the device private key x can be sent to the mobile phone corresponding to the device identifier req_ID, and the relevant information of the device public key (req_ID, y, g, p) can also be sent to the verification server.

[0209] After receiving the target file version vers_f_req and the device identifier req_ID sent by the file server, the verification server can first generate a signature key corresponding to the verification server, for example, a signature private key d corresponding to the verification server and a signature public key (e, n) corresponding to the verification server; then a chameleon random number can be selected. The chameleon random number r and the relevant information of the device public key sent by the key management server can be used to calculate the chameleon hash value h_req_ID=g of the target file version vers_f_req vers_f_req g rx mod p; finally, the calculated chameleon hash value h_req_ID can be signed using the signature private key corresponding to the verification server sign(h_req_ID)=(h_req_ID) d mod n, so as to obtain the chameleon signature information (req_ID, vers_f_req, r, sign(h_req_ID), (e, n), g, p) corresponding to the target file version vers_f_req, and send the chameleon signature information (req_ID, vers_f_req, r, sign(h_req_ID), (e, n), g, p) to the mobile phone based on the version verification information acquisition request of the mobile phone.

[0210] It should be understood that the process of the file server generating chameleon signature information using the chameleon signature algorithm is similar to the process of the verification server generating chameleon signature information using the chameleon signature algorithm, and the basic principles are the same. For the sake of simplicity, they will not be repeated here.

[0211] Specifically, after the mobile phone obtains the chameleon signature information of the file to be verified, it can first use the device private key obtained from the key management server and the chameleon random number in the chameleon signature information to calculate the first chameleon hash value h_req_ID'=g of the current file version vers_f_req' corresponding to the file to be verified. vers_f_req’ g rxmodp; then the signature public key (e, n) in the chameleon signature information can be used to calculate the second chameleon hash value H'=(sign(h_req_ID)) corresponding to the chameleon signature information e mod n; finally, the validity of the version of the file to be verified can be verified according to the first chameleon hash value h_req_ID' and the second chameleon hash value H'. Here, when the first chameleon hash value h_req_ID' and the second chameleon hash value H' are the same, it can be determined that the file version of the file to be verified is legal, that is, it can be considered that the file to be verified is a legal file currently sent by the file server; when the first chameleon hash value h_req_ID' and the second chameleon hash value H' are different, it can be determined that the file version of the file to be verified is illegal, that is, it can be considered that the file to be verified may be a replaced or re-posted file.

[0212] It should be noted that when the mobile phone obtains that the file version of the file to be verified is illegal, the mobile phone can record the verification result of the illegal file version of the file to be verified in the verification log of the mobile phone to facilitate the subsequent viewing of the verification results. At the same time, the mobile phone can also present the verification results in real time on the display screen of the mobile phone, reminding the user of the mobile phone that the file currently obtained may be an illegal file that has been replaced or re-released, and informing the user of the current file download risk.

[0213] It should be understood that the file server and / or the verification server may also generate the target version verification information corresponding to the file to be verified by generating a version hash tree and signing the root node of the version hash tree.

[0214] Specifically, when the file server sends the file to be verified and the integrity verification information corresponding to the file to be verified to the mobile phone, it can also generate a version hash tree in real time according to the target file version of the file to be verified sent by it and the target file version of all other files in the file server, and can sign the root node of the version hash tree to generate the target version verification information corresponding to the file to be verified. Or the file server can send the root node of the version hash tree to the verification server, so as to generate the target version verification information corresponding to the file to be verified by signing the root node of the version hash tree through the verification server. When receiving the version verification information acquisition request sent by the mobile phone, the file server or the verification server can send the target version verification information (including the root node signature information of the version hash tree, the signature public key and the related sub-nodes in the version hash tree) to the mobile phone, and the mobile phone can verify the current file version of the file to be verified based on the received target version verification information.

[0215] Among them, the process of the mobile phone verifying the current file version of the file to be verified based on the version hash tree is similar to the process of the mobile phone verifying the integrity of the file to be verified based on the target hash tree. The basic principles are the same and will not be repeated here for the sake of simplicity.

[0216] [Example 2]

[0217] The integrity verification method provided in the second embodiment can be used in Figure 2 The integrity verification system shown in the figure is implemented in the verification server to perform integrity verification on each terminal device, that is, the integrity verification method provided in this embodiment can be used to perform integrity verification on the application files in each terminal device to ensure that the application files in each terminal device are not tampered with and the version is legal. Figure 2 The integrity verification system shown provides a detailed description of the integrity verification method provided in this embodiment.

[0218] like Figure 6 As shown, the integrity verification method provided in this embodiment may include:

[0219] S601. Acquire integrity verification information of each terminal device, where the integrity verification information includes initial root node signature information obtained by signing an initial root node of an initial hash tree using a first signature private key and a first signature public key corresponding to the first signature private key;

[0220] It should be noted that the initial hash tree may include a first-level initial hash tree and a second-level initial hash tree, and the initial root node is the root node of the second-level initial hash tree. The first-level initial hash tree is a hash tree constructed by each terminal device according to each target file in each terminal device, and the second-level initial hash tree is a hash tree constructed by each aggregation gateway according to the first-level initial hash tree of each terminal device corresponding to each aggregation gateway.

[0221] Optionally, both the first-level initial hash tree and the second-level initial hash tree are ternary hash trees, so as to reduce the level of hash trees through the ternary hash trees and reduce the amount of signature calculation.

[0222] Take the terminal device as a mobile phone as an example. When it is necessary to verify the integrity of each mobile phone, the verification server can send an integrity verification request to each mobile phone. After each mobile phone receives the integrity verification request, it can obtain the target file in each mobile phone to build a first-level initial hash tree corresponding to each mobile phone. Among them, the target file in each mobile phone is all or part of the files obtained by each mobile phone from the file server. Here, any parent node in the first-level initial hash tree is the hash value of all child nodes corresponding to the parent node, and the leaf node of the first-level initial hash tree is the hash value of the file name f_req, file metadata matadata_f_req and file version vers_f_req of the target file, that is, the leaf node Hash_f_req_ID of the first-level initial hash tree = H(req_ID||f_req||matadata_f_req||vers_f_req).

[0223] It should be noted that when constructing the first-level initial hash tree, the mobile phone can first sort the target files corresponding to the mobile phone according to the first preset sorting method, and then construct the leaf nodes of the first-level initial hash tree corresponding to the mobile phone according to the sorted target files. Here, the first preset sorting method can be a sorting method according to the first letter of the file name f_req in ascending order (a→z), or a sorting method according to the first letter of the file name f_req in descending order (z→a).

[0224] like Figure 6a As shown, mobile phone ID1 can construct a first-level initial hash tree corresponding to mobile phone ID1 based on the target files (f1_req_ID1 to f3_req_ID1) in mobile phone ID1, mobile phone ID2 can construct a first-level initial hash tree corresponding to mobile phone ID2 based on the target files (f1_req_ID2 to f9_req_ID2) in mobile phone ID2, and mobile phone ID3 can construct a first-level initial hash tree corresponding to mobile phone ID3 based on the target files (f1_req_ID3 to f3_req_ID3) in mobile phone ID3. Among them, f1_req_ID1 is the first target file in mobile phone ID1 after being sorted according to the above-mentioned first preset sorting method, and f3_req_ID1 is the third target file in mobile phone ID1 after being sorted according to the above-mentioned first preset sorting method, and other expressions are similar to this.

[0225] For example, after the mobile phone obtains the first-level initial hash tree, it can first obtain the first-level initial root node Hash_IDi of the first-level initial hash tree, and then use the signature private key corresponding to the mobile phone to sign the first-level initial root node sign(Hash_IDi)=(Hash_IDi) d_IDimod n, obtain the first-level initial root node signature information, and can send the initial integrity verification information Info_IDi={Hash_IDi,sign(Hash_IDi),(e_IDi,n)} containing the first-level initial root node signature information to the aggregation gateway corresponding to the mobile phone, where d_IDi is the signature private key corresponding to mobile phone IDi, and (e_IDi,n) is the signature public key corresponding to mobile phone IDi.

[0226] For example, the first-level initial root node of each first-level initial hash tree may be signed by obtaining the signature private key corresponding to each mobile phone from the key management server.

[0227] It should be understood that after the aggregation gateway receives the initial integrity verification information Info_Dii sent by each mobile phone corresponding to it, it can use the signature public key corresponding to each mobile phone to verify the first-level initial root node signature information sign (Hash_IDi) in the initial integrity verification information Info_IDi sent by each mobile phone. When the first-level initial root node signature information sign (Hash_IDi) corresponding to the aggregation gateway is verified, the aggregation gateway can build the second-level initial hash tree corresponding to the aggregation gateway according to the first-level initial root node in each initial integrity verification information Info_IDi it receives. Here, the process of verifying the first-level initial root node signature information sign (Hash_IDi) in the initial integrity verification information Info_IDi is similar to the process of verifying the root node signature information of the target root node in Example 1, and the basic principle is the same. For the sake of simplicity, it will not be repeated here.

[0228] When constructing the secondary initial hash tree, the aggregation gateway may first sort the mobile phones corresponding to the aggregation gateway according to the second preset sorting method, and then construct the secondary initial hash tree corresponding to the aggregation gateway according to the first-level initial root node of the first-level initial hash tree corresponding to the sorted mobile phones. Here, the second preset sorting method may be a sorting method from small to large according to the device identification (such as the mobile phone ID number) of the mobile phone, or may be a sorting method from large to small according to the device identification (such as the mobile phone ID number) of the mobile phone.

[0229] like Figure 6aAs shown, the aggregation gateway Agg1 can construct the secondary initial hash tree corresponding to the aggregation gateway Aggr1 according to the first-level initial root nodes Hash_ID1, Hash_ID2 and Hash_ID3 of the first-level initial hash tree sent by the corresponding mobile phone ID1, mobile phone ID2 and mobile phone ID3. Among them, mobile phone ID1 is the mobile phone ranked first after sorting according to the above second preset sorting method, mobile phone ID2 is the mobile phone ranked second after sorting according to the above second preset sorting method, and mobile phone ID3 is the mobile phone ranked third after sorting according to the above second preset sorting method.

[0230] For example, after the aggregation gateway obtains the secondary initial hash tree, it can first obtain the secondary initial root node Hash_Aggi of the secondary initial hash tree, and then use the signature private key corresponding to the aggregation gateway (i.e., the first signature private key corresponding to the first signature public key described in S602) to sign the secondary initial root node sign(Hash_Aggi)=(Hash_Aggi) d_Aggi mod n, obtain the secondary initial root node signature information, and send the integrity check information Info_Aggi={Hash_Aggi,sign(Hash_Aggi),(e_Aggi,n)} containing the secondary initial root node signature information to the verification server. Wherein, d_Aggi is the first signature private key corresponding to the aggregation gateway Aggi, and (e_Aggi,n) is the first signature public key corresponding to the aggregation gateway Aggi.

[0231] For example, the second-level initial root node of each second-level initial hash tree may be signed by acquiring the first signature private key corresponding to each aggregation gateway from the key management server.

[0232] S602: Use the first signature public key to verify the initial root node signature information;

[0233] Here, after receiving the integrity verification information Info_Aggi sent by each aggregation gateway, the verification server can use the first signature public key corresponding to each aggregation gateway to verify the secondary initial root node signature information in the integrity verification information Info_Aggi sent by each aggregation gateway.

[0234] For example, the first signature public key A corresponding to the aggregation gateway Agg1 can be used to verify the secondary initial root node signature information in the integrity verification information Info_Agg1 sent by the aggregation gateway Agg1, the first signature public key B corresponding to the aggregation gateway Agg2 can be used to verify the secondary initial root node signature information in the integrity verification information Info_Agg2 sent by the aggregation gateway Agg2, and the first signature public key C corresponding to the aggregation gateway Agg3 can be used to verify the secondary initial root node signature information in the integrity verification information Info_Agg3 sent by the aggregation gateway Agg1.

[0235] It should be understood that the process of verifying the secondary initial root node signature information in the integrity verification information Info_Aggi is similar to the process of verifying the root node signature information of the target root node in Example 1, and the basic principles are the same. For the sake of simplicity, it will not be repeated here.

[0236] S603: When the signature information of the initial root node is verified, a target hash tree is constructed according to the initial root node;

[0237] It should be understood that when the signature information of each secondary initial root node is verified, the verification server can construct a target hash tree based on the secondary initial root node in each integrity check information Info_Aggi it receives. The target hash tree can also be a ternary hash tree, so as to reduce the level of the hash tree through the ternary hash tree, reduce the signature calculation amount, and facilitate the subsequent rapid positioning of the terminal device whose integrity has been damaged.

[0238] Specifically, the verification server may first sort the aggregation gateways according to a third preset sorting method, and then construct the target hash tree according to the secondary initial root node of the secondary initial hash tree corresponding to the sorted aggregation gateways. Here, the third preset sorting method may be a sorting method from small to large according to the gateway identifier (e.g., gateway ID number) of the aggregation gateway, or may be a sorting method from large to small according to the gateway identifier (e.g., gateway ID number) of the aggregation gateway.

[0239] S604, obtaining a local root node of the local hash tree and a target root node of the target hash tree;

[0240] It should be noted that after the mobile phone obtains the file from the file server, the file server may also send the request files (including file name, file version and file metadata, etc.) requested by each mobile phone to the verification server in real time or regularly, and the verification server may build a first-level local hash tree corresponding to each mobile phone based on the request file. For example, the first-level local hash tree corresponding to mobile phone A can be built based on the request files a, b, c, d, e, f, g, h and i corresponding to mobile phone A, and the first-level local hash tree corresponding to mobile phone B can be built based on the request files j, k and l corresponding to mobile phone B. Here, the construction process of the first-level local hash tree is similar to the construction process of the aforementioned first-level initial hash tree, and the basic principles are the same. For the sake of simplicity, it will not be repeated here.

[0241] It should be understood that when the verification server constructs the first-level local hash tree corresponding to the mobile phone, it can sort the request files corresponding to the mobile phone according to the first preset sorting method used in the construction process of the aforementioned first-level initial hash tree, and can construct the first-level local hash tree corresponding to the mobile phone based on the sorted request files.

[0242] For example, when the first preset sorting method used in the construction process of the aforementioned first-level initial hash tree is a sorting method based on the ascending order of the first letter of the file name f_req (a→z), the verification server can sort the requested files based on the ascending order of the first letter of the file name f_req (a→z).

[0243] Here, after the verification server obtains the first-level local hash tree corresponding to each mobile phone, it can first obtain the first-level local root node of each first-level local hash tree and the aggregation gateway corresponding to each mobile phone, and can group each first-level local root node according to the aggregation gateway, that is, the first-level local root nodes corresponding to the mobile phones corresponding to the same aggregation gateway can be divided into the same group; then, the second-level local hash tree corresponding to each aggregation gateway can be constructed according to the first-level local root node corresponding to each aggregation gateway.

[0244] It should be understood that when the verification server constructs the secondary local hash tree corresponding to the aggregation gateway, it can sort the mobile phones corresponding to the aggregation gateway according to the second preset sorting method used in the construction process of the aforementioned secondary initial hash tree, and can construct the secondary local hash tree corresponding to the aggregation gateway according to the first-level local root node of the first-level local hash tree corresponding to the sorted mobile phones.

[0245] For example, when the second preset sorting method used in the construction process of the aforementioned secondary initial hash tree is to sort the mobile phone ID numbers from small to large, the verification server can sort the mobile phones in ascending order according to the mobile phone ID numbers.

[0246] Here, after obtaining the secondary local hash trees corresponding to each aggregation gateway, the verification server can obtain the secondary local root nodes of each secondary local hash tree, and can construct the local hash tree according to the secondary local root nodes corresponding to each secondary local hash tree.

[0247] It should be understood that when the verification server constructs the local hash tree, it can sort each aggregation gateway according to the third preset sorting method used in the construction process of the target hash tree described above, and can construct the local hash tree according to the secondary local root node of the secondary local hash tree corresponding to the sorted aggregation gateway.

[0248] In this embodiment, during the construction of the local hash tree and the target hash tree, the root nodes at all levels are sorted using the same preset sorting method to avoid different hash values ​​caused by different sorting, thereby affecting the integrity check result.

[0249] S605: Verify the integrity of each of the terminal devices according to the local root node and the target root node.

[0250] Specifically, if the local root node is the same as the target root node, the verification server can determine that the integrity check of the terminal device has passed, that is, the application files in all terminal devices have not been tampered with or replaced; if the local root node is not the same as the target root node, the verification server can determine that the integrity check of the terminal device has failed, that is, the integrity of one or more terminal devices has been destroyed, that is, the application files in one or more terminal devices have been tampered with or replaced.

[0251] For example, when the verification result of the terminal device failing the integrity check is obtained, the verification server can locate the target terminal device whose integrity has been compromised by comparing the local hash tree with the target hash tree, that is, the target terminal device whose integrity has been compromised can be determined based on the comparison result of the local hash tree with the target hash tree.

[0252] This embodiment uses a hash tree and signs the root node of the hash tree to perform integrity verification on the terminal device, so that the terminal device and the aggregation gateway only need to sign the root node of the relevant hash tree, and do not need to sign each file, which greatly reduces the amount of calculation of the terminal device and the aggregation gateway, and alleviates the calculation burden of the terminal device and the aggregation gateway. At the same time, by transferring most of the signature verification process to the aggregation gateway, the amount of calculation of the verification server can be reduced, and the calculation burden of the verification server can be alleviated.

[0253] It should be understood that the size of the serial numbers of the steps in the above embodiments 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 application.

[0254] Corresponding to the integrity verification method described in the above embodiment, Figure 7 and Figure 8 A structural block diagram of an integrity verification device provided in an embodiment of the present application is shown. For ease of explanation, only the parts related to the embodiment of the present application are shown.

[0255] like Figure 7 As shown, an embodiment of the present application provides an integrity verification device, which is applied to a terminal device. The integrity verification device may include:

[0256] The file acquisition module 701 is used to acquire the file to be verified sent by the file server and the integrity verification information of the file to be verified, wherein the integrity verification information includes the root node signature information obtained by signing the target root node of the target hash tree using the first signature private key, the child nodes related to the file to be verified in the target hash tree, and the first signature public key corresponding to the first signature private key, and the target hash tree is a hash tree constructed according to all files in the file server;

[0257] A signature information verification module 702 is used to verify the root node signature information using the first signature public key;

[0258] The current root node construction module 703 is used to construct the current root node corresponding to the target hash tree according to the file to be verified and the child node when the root node signature information is verified;

[0259] The integrity verification module 704 is used to verify the integrity of the file to be verified based on the current root node and the target root node.

[0260] Optionally, the integrity verification device may further include:

[0261] A version verification information acquisition module is used to obtain target version verification information of the file to be verified, wherein the target version verification information is version verification information generated according to the target file version of the file to be verified;

[0262] The version validity verification module is used to verify the version validity of the file to be verified according to the current file version of the file to be verified and the target version verification information.

[0263] In a possible implementation, the target version verification information is chameleon signature information generated according to the target file version and the device identification of the terminal device;

[0264] Accordingly, the version validity verification module may include:

[0265] A first hash value calculation unit, configured to calculate a first chameleon hash value of the current file version according to a device private key corresponding to the terminal device and a chameleon random number in the chameleon signature information;

[0266] A second hash value calculation unit, configured to calculate a second chameleon hash value corresponding to the chameleon signature information using a second signature public key in the chameleon signature information;

[0267] A version validity verification unit is used to verify the version validity of the file to be verified according to the first chameleon hash value and the second chameleon hash value.

[0268] For example, the integrity verification device may further include:

[0269] The device private key acquisition module is used to acquire the device private key corresponding to the terminal device according to the device identification.

[0270] Optionally, the version verification information acquisition module is specifically used to obtain target version verification information of the file to be verified sent by the verification server, and the target version verification information is version verification information generated by the verification server based on the target file version of the file to be verified sent by the file server and the device identifier of the terminal device that receives the file to be verified.

[0271] Specifically, the target hash tree is a ternary hash tree.

[0272] like Figure 8 As shown, an embodiment of the present application provides an integrity verification device, which is applied to a verification server. The integrity verification device may include:

[0273] The integrity information acquisition module 801 is used to obtain integrity verification information of each terminal device, where the integrity verification information includes initial root node signature information obtained by signing the initial root node of the initial hash tree using the first signature private key and the first signature public key corresponding to the first signature private key;

[0274] A signature information verification module 802 is used to verify the initial root node signature information using the first signature public key;

[0275] A hash tree construction module 803 is used to construct a target hash tree according to the initial root node when the signature information of the initial root node is verified;

[0276] A root node acquisition module 804 is used to acquire a local root node of a local hash tree and a target root node of the target hash tree;

[0277] The integrity verification module 805 is used to verify the integrity of each terminal device according to the local root node and the target root node.

[0278] Optionally, the initial hash tree includes a first-level initial hash tree and a second-level initial hash tree, and the initial root node is the root node of the second-level initial hash tree;

[0279] The first-level initial hash tree is a hash tree constructed by each of the terminal devices according to each of the target files in the terminal devices;

[0280] The secondary initial hash tree is a hash tree constructed by each aggregation gateway according to each primary initial hash tree corresponding to each aggregation gateway.

[0281] Specifically, the aggregation gateway may include:

[0282] A signature public key acquisition unit, used to acquire the second signature public key sent by each of the terminal devices;

[0283] A signature information verification unit, used to verify the primary root node signature information sent by each of the terminal devices using each of the second signature public keys;

[0284] The hash tree construction unit is used to construct the second-level initial hash tree according to the first-level initial root node of each of the first-level initial hash trees when the signature information of each of the first-level root nodes is verified.

[0285] In a possible implementation, the integrity verification device may further include:

[0286] A request file acquisition module, used to acquire a request file sent by the file server, wherein the request file is a file requested by each of the terminal devices from the file server;

[0287] A first-level local hash tree construction module, used to construct a first-level local hash tree corresponding to each of the terminal devices according to the request file, and obtain a first-level local root node of each of the first-level local hash trees;

[0288] A secondary local hash tree construction module, used to construct a secondary local hash tree corresponding to each of the aggregation gateways according to each of the primary local root nodes, and obtain a secondary local root node of each of the secondary local hash trees;

[0289] The local hash tree construction module is used to construct the local hash tree according to each of the secondary local root nodes.

[0290] Optionally, the integrity verification module may include:

[0291] A verification result obtaining unit, configured to obtain a verification result indicating that the integrity check of the terminal device has passed if the local root node is the same as the target root node;

[0292] A hash tree comparison unit, configured to obtain a verification result indicating that the integrity check of the terminal device fails if the local root node is different from the target root node, and compare the local hash tree with the target hash tree;

[0293] The target terminal device determining unit is used to determine the target terminal device that fails the integrity check based on the comparison result of the local hash tree and the target hash tree.

[0294] Specifically, the local hash tree and the target hash tree are both ternary hash trees.

[0295] It should be noted that the information interaction, execution process, etc. between the above-mentioned devices / units are based on the same concept as the method embodiment of the present application. Their specific functions and technical effects can be found in the method embodiment part and will not be repeated here.

[0296] The technicians in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In practical applications, the above-mentioned function allocation can be completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated in a processing unit, or each unit can exist physically separately, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, which will not be repeated here.

[0297] Fig. 9 This is a schematic diagram of the structure of the verification server provided in one embodiment of the present application. Fig. 9 As shown, the verification server 9 of this embodiment includes: at least one processor 90 ( Fig. 9 Only one is shown in the figure) a processor, a memory 91, and a computer program 92 stored in the memory 91 and executable on the at least one processor 90, and when the processor 90 executes the computer program 92, the steps in any of the integrity verification method embodiments in the above-mentioned embodiment 2 are implemented.

[0298] The verification server 9 can be a computing device such as a desktop computer, a notebook, a PDA, or a cloud server. The verification server can include, but is not limited to, a processor 90 and a memory 91. Those skilled in the art can understand that Fig. 9 It is only an example of the verification server 9 and does not constitute a limitation on the verification server 9. It may include more or fewer components than shown in the figure, or a combination of certain components, or different components, for example, it may also include input and output devices, network access devices, etc.

[0299] The processor 90 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc.

[0300] In some embodiments, the memory 91 may be an internal storage unit of the verification server 9, such as a hard disk or memory of the verification server 9. In other embodiments, the memory 91 may also be an external storage device of the verification server 9, such as a plug-in hard disk, a smart memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, a flash card (Flash Card), etc. equipped on the verification server 9. Further, the memory 91 may also include both an internal storage unit of the verification server 9 and an external storage device. The memory 91 is used to store an operating system, an application program, a boot loader (BootLoader), data, and other programs, such as the program code of the computer program, etc. The memory 91 may also be used to temporarily store data that has been output or is to be output.

[0301] Similarly, the terminal device also includes at least one processor, a memory, and a computer program stored in the memory and executable on the at least one processor, and the processor implements the steps in any of the integrity verification method embodiments in the above-mentioned embodiment 1 when executing the computer program. Here, the principles of the processor and the memory are the same as those of the processor 90 and the memory 91 described above, and for the sake of simplicity, they are not described here.

[0302] An embodiment of the present application further provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in the above-mentioned method embodiments can be implemented.

[0303] The embodiment of the present application provides a computer program product. When the computer program product is run on a terminal device, the terminal device can implement the steps in the first embodiment of the above method when executing the computer program product.

[0304] The embodiment of the present application provides a computer program product. When the computer program product runs on a verification server, the verification server can implement the steps in the second embodiment of the above method when executing the computer program product.

[0305] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, which can be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium can at least include: any entity or device that can carry the computer program code to the camera / terminal device, recording medium, computer memory, read-only memory (ROM, Read-Only Memory), random access memory (RAM, RandomAccess Memory), electric carrier signal, telecommunication signal and software distribution medium. For example, a USB flash drive, a mobile hard disk, a disk or an optical disk. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electric carrier signals and telecommunication signals.

[0306] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0307] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein 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. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0308] In the embodiments provided in the present application, it should be understood that the disclosed device / terminal device / verification server and method can be implemented in other ways. For example, the device / terminal device / verification server embodiments described above are merely schematic. For example, the division of the modules or units is only a logical function division. There may be other division methods in actual implementation, 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.

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

[0310] The embodiments described above are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, a person skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. Such modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. A method for integrity verification, characterized in that: Applied to a terminal device, the integrity verification method includes: Obtaining a file to be verified sent by a file server and integrity verification information of the file to be verified, wherein the integrity verification information includes root node signature information obtained by signing a target root node of a target hash tree using a first signature private key, child nodes related to the file to be verified in the target hash tree, and a first signature public key corresponding to the first signature private key, wherein the target hash tree is a hash tree constructed according to all files in the file server; Using the first signature public key to verify the root node signature information; When the root node signature information is verified, a current root node corresponding to the target hash tree is constructed according to the file to be verified and the child node; Verifying the integrity of the file to be verified according to the current root node and the target root node; Obtaining target version verification information of the file to be verified, where the target version verification information is chameleon signature information generated according to the target file version of the file to be verified and the device identification of the terminal device; Calculate a first chameleon hash value of the current file version of the file to be verified according to a device private key corresponding to the terminal device and a chameleon random number in the chameleon signature information; Calculate a second chameleon hash value corresponding to the chameleon signature information using the second signature public key in the chameleon signature information; The version legitimacy of the file to be verified is verified according to the first chameleon hash value and the second chameleon hash value.

2. The integrity verification method according to claim 1, characterized in that: Before calculating the first chameleon hash value of the current file version of the file to be verified according to the device private key corresponding to the terminal device and the chameleon random number in the chameleon signature information, the method includes: Obtain a device private key corresponding to the terminal device according to the device identification.

3. The integrity verification method according to claim 1, characterized in that: The step of obtaining the target version verification information of the file to be verified includes: Obtain target version verification information of the file to be verified sent by the verification server, where the target version verification information is version verification information generated by the verification server according to the target file version of the file to be verified sent by the file server and the device identifier of the terminal device receiving the file to be verified.

4. The integrity verification method according to any one of claims 1 to 3, characterized in that: The target hash tree is a ternary hash tree.

5. A method for integrity verification, characterized in that: Applied to the verification server, the integrity verification method includes: Acquire integrity verification information of each terminal device, the integrity verification information including initial root node signature information obtained by signing an initial root node of an initial hash tree using a first signature private key and a first signature public key corresponding to the first signature private key, the initial hash tree including a first-level initial hash tree and a second-level initial hash tree, the initial root node being the root node of the second-level initial hash tree; the construction process of the second-level initial hash tree includes: each aggregation gateway acquires a second signature public key sent by each of the terminal devices; and each of the second signature public keys is used to verify the first-level root node signature information sent by each of the terminal devices; when each of the first-level root node signature information is verified, the second-level initial hash tree is constructed according to the first-level initial root node of each of the first-level initial hash trees; Verifying the initial root node signature information using the first signature public key; When the signature information of the initial root node is verified, a target hash tree is constructed according to the initial root node; Obtaining a local root node of the local hash tree and a target root node of the target hash tree; The integrity of each of the terminal devices is verified according to the local root node and the target root node.

6. The integrity verification method according to claim 5, characterized in that: The first-level initial hash tree is a hash tree constructed by each of the terminal devices according to each of the target files in the terminal devices; The secondary initial hash tree is a hash tree constructed by each aggregation gateway according to each primary initial hash tree corresponding to each aggregation gateway.

7. The integrity verification method according to claim 6, characterized in that: Before obtaining the local root node of the local hash tree, the method includes: Obtaining a request file sent by a file server, wherein the request file is a file requested by each of the terminal devices from the file server; Constructing a first-level local hash tree corresponding to each of the terminal devices according to the request file, and obtaining a first-level local root node of each of the first-level local hash trees; Constructing a secondary local hash tree corresponding to each of the aggregation gateways according to each of the primary local root nodes, and obtaining a secondary local root node of each of the secondary local hash trees; The local hash tree is constructed according to each of the secondary local root nodes.

8. The integrity verification method according to claim 5, characterized in that: The checking the integrity of each of the terminal devices according to the local root node and the target root node comprises: If the local root node is the same as the target root node, a verification result indicating that the integrity check of the terminal device has passed is obtained; If the local root node is different from the target root node, a check result indicating that the integrity check of the terminal device fails is obtained, and the local hash tree is compared with the target hash tree; According to the comparison result between the local hash tree and the target hash tree, the target terminal device that fails the integrity check is determined.

9. The integrity verification method according to any one of claims 5 to 8, characterized in that: The local hash tree and the target hash tree are both ternary hash trees.

10. An integrity verification device, characterized in that: Applied to a terminal device, the integrity verification device comprises: A file acquisition module, used to acquire a file to be verified sent by a file server and integrity verification information of the file to be verified, wherein the integrity verification information includes root node signature information obtained by signing a target root node of a target hash tree using a first signature private key, child nodes related to the file to be verified in the target hash tree, and a first signature public key corresponding to the first signature private key, wherein the target hash tree is a hash tree constructed according to all files in the file server; A signature information verification module, used to verify the root node signature information using the first signature public key; A current root node construction module, used to construct a current root node corresponding to the target hash tree according to the file to be verified and the child node when the root node signature information is verified; An integrity verification module, used to verify the integrity of the file to be verified according to the current root node and the target root node; A version verification information acquisition module, used to obtain the target version verification information of the file to be verified, wherein the target version verification information is chameleon signature information generated according to the target file version of the file to be verified and the device identification of the terminal device; A version legitimacy verification module is used to calculate the first chameleon hash value of the current file version of the file to be verified based on the device private key corresponding to the terminal device and the chameleon random number in the chameleon signature information; use the second signature public key in the chameleon signature information to calculate the second chameleon hash value corresponding to the chameleon signature information; and verify the version legitimacy of the file to be verified based on the first chameleon hash value and the second chameleon hash value.

11. The integrity verification device according to claim 10, characterized in that: The integrity verification device also includes: The device private key acquisition module is used to acquire the device private key corresponding to the terminal device according to the device identification.

12. The integrity verification device according to claim 10, characterized in that: The version verification information acquisition module is specifically used to obtain the target version verification information of the file to be verified sent by the verification server. The target version verification information is the version verification information generated by the verification server based on the target file version of the file to be verified sent by the file server and the device identifier of the terminal device that receives the file to be verified.

13. The integrity verification device according to any one of claims 10 to 12, characterized in that: The target hash tree is a ternary hash tree.

14. An integrity verification device, characterized in that: Applied to the verification server, the integrity verification device comprises: An integrity information acquisition module is used to obtain integrity verification information of each terminal device, the integrity verification information includes initial root node signature information obtained by signing the initial root node of the initial hash tree using the first signature private key and the first signature public key corresponding to the first signature private key, the initial hash tree includes a first-level initial hash tree and a second-level initial hash tree, the initial root node is the root node of the second-level initial hash tree; the construction process of the second-level initial hash tree includes: each aggregation gateway obtains the second signature public key sent by each of the terminal devices; each of the second signature public keys is used to verify the first-level root node signature information sent by each of the terminal devices; when the first-level root node signature information is verified, the second-level initial hash tree is constructed according to the first-level initial root node of each of the first-level initial hash trees; A signature information verification module, used to verify the initial root node signature information using the first signature public key; A hash tree construction module, used to construct a target hash tree according to the initial root node when the signature information of the initial root node is verified; A root node acquisition module, used to acquire a local root node of a local hash tree and a target root node of the target hash tree; An integrity verification module is used to verify the integrity of each of the terminal devices based on the local root node and the target root node.

15. The integrity verification device according to claim 14, characterized in that: The first-level initial hash tree is a hash tree constructed by each of the terminal devices according to each of the target files in the terminal devices; The secondary initial hash tree is a hash tree constructed by each aggregation gateway according to each primary initial hash tree corresponding to each aggregation gateway.

16. The integrity verification device according to claim 15, characterized in that: The integrity verification device also includes: A request file acquisition module, used to acquire a request file sent by a file server, wherein the request file is a file requested by each terminal device from the file server; A first-level local hash tree construction module, used to construct a first-level local hash tree corresponding to each of the terminal devices according to the request file, and obtain a first-level local root node of each of the first-level local hash trees; A secondary local hash tree construction module, used to construct a secondary local hash tree corresponding to each of the aggregation gateways according to each of the primary local root nodes, and obtain a secondary local root node of each of the secondary local hash trees; The local hash tree construction module is used to construct the local hash tree according to each of the secondary local root nodes.

17. The integrity verification device according to claim 14, characterized in that: The integrity check module comprises: A verification result obtaining unit, configured to obtain a verification result indicating that the integrity check of the terminal device has passed if the local root node is the same as the target root node; A hash tree comparison unit, configured to obtain a verification result indicating that the integrity check of the terminal device fails if the local root node is different from the target root node, and compare the local hash tree with the target hash tree; The target terminal device determining unit is used to determine the target terminal device that fails the integrity check based on the comparison result of the local hash tree and the target hash tree.

18. The integrity verification device according to any one of claims 14 to 17, characterized in that: The local hash tree and the target hash tree are both ternary hash trees.

19. A terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the integrity verification method according to any one of claims 1 to 4 is implemented.

20. A verification server, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the integrity verification method according to any one of claims 5 to 9 is implemented.

21. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the integrity verification method according to any one of claims 1 to 9 is implemented.

Images