WO2021114918A1

WO2021114918A1 - Integrity checking method and apparatus, terminal device and verification server

Info

Publication number: WO2021114918A1
Application number: PCT/CN2020/124157
Authority: WO
Inventors: 李永凯
Original assignee: 华为技术有限公司
Priority date: 2019-12-13
Filing date: 2020-10-27
Publication date: 2021-06-17
Also published as: CN112989430A

Abstract

The present application is applicable to the technical field of terminals, and relates in particular to an integrity checking method and apparatus, a terminal device and a verification server. The method comprises: acquiring a file to be checked, that is sent by a file server, and integrity checking information of the file to be checked, wherein the integrity checking information comprises root node signature information obtained by means of signing a target root node of a target hash tree using a first signature private key, a child node, that is related to the file to be checked, in the target hash tree, and a 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; verifying the root node signature information using the first signature public key; when the verification of the root node signature information is passed, according to the file to be checked and the child node, constructing the current root node corresponding to the target hash tree; and according to the current root node and the target root node, checking the integrity of the file to be checked. The problem of a large amount of calculation due to the fact that all files need to be signed respectively at present is solved.

Description

Integrity verification method, device, terminal equipment and verification server

This application claims the priority of a Chinese patent application filed with the State Intellectual Property Office, the application number is 201911284197.5, and the application name is "Integrity Check Method, Device, Terminal Equipment and Verification Server" on December 13, 2019, and its entire contents Incorporated in this application by reference.

Technical field

This application belongs to the field of terminal technology, and in particular relates to integrity verification methods, devices, terminal equipment, verification servers, and computer-readable storage media.

Background technique

Integrity verification refers to the technical means of verifying the accuracy of files to detect whether the files have been tampered with illegally. With the continuous development of network technology, files downloaded or applied by terminal devices are easily tampered with illegally. Therefore, how to verify the integrity of downloaded files or application files of terminal devices has become an urgent problem for those skilled in the art.

In the prior art, it is possible to separately calculate hash values for all files in advance, and to separately sign and save each hash value, so as to verify the integrity of the file according to the stored signature results. This method of separately signing all files requires a large number of signature operations, which greatly increases the amount of calculation.

Summary of the invention

The embodiments of the application provide an integrity verification method, device, terminal equipment, verification server, and computer-readable storage medium, which can solve the need to separately sign all files in the existing integrity verification, which causes a large amount of calculation. The problem.

In the first aspect, an embodiment of the present application provides an integrity check method, which is applied to a terminal device, and the integrity check method includes:

Obtain the file to be verified sent by the file server and the integrity check information of the file to be verified, where the integrity check information includes the root obtained by signing the target root node of the target hash tree with the first signature private key Node signature information, 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 based on the file Hash tree constructed by all files in the server;

Verifying the signature information of the root node by using the first signature public key;

When the root node signature information is verified, construct the current root node corresponding to the target hash tree according to the file to be verified and the child nodes;

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

In the embodiment of the present application, the integrity check of the downloaded file of the terminal device is performed by using the hash tree and the signature of the root node of the hash tree, so that the integrity check can be completed only by signing the root node. Signing each file greatly reduces the amount of signature calculation and eases the calculation burden.

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

Acquiring target version verification information of the file to be verified, where the target version verification information is version verification information generated according to the target file version of the file to be verified;

Verify the version legality of the file to be verified according to the current file version of the file to be verified and the target version verification information.

Here, by separately requesting the integrity check and the version legality check, the true version of the file to be verified can be verified in a cryptographically safe manner, so as to reduce the risk of file replacement and replay attacks.

Optionally, the target version verification information is chameleon signature information generated according to the target file version and the device identifier of the terminal device;

The verifying the version legality 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:

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;

Calculating the second chameleon hash value corresponding to the chameleon signature information by using the second signature public key in the chameleon signature information;

Verifying the legality of the version of the file to be verified according to the hash value of the first chameleon and the hash value of the second chameleon.

It should be understood that the target file version is signed by the chameleon signature algorithm to use the non-repudiation, non-interactivity, and non-transmission characteristics of the chameleon signature to ensure the unique legitimacy of the version information and reduce the risk of leakage.

Specifically, before the calculation of 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, the method includes: obtaining according to the device identification The device private key corresponding to the terminal device.

For example, the embodiment of the present application 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.

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

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

Here, the target version verification information of the file to be verified can be generated by the verification server to realize risk sharing, thereby reducing the risk of the target version verification information being attacked.

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.

In the 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:

Obtain the integrity check information of each terminal device, the integrity check information includes the initial root node signature information obtained by signing the initial root node of the initial hash tree with the first signature private key, and the private signature information with the first signature. The first signature public key corresponding to the key;

Verifying the initial root node signature information by using the first signature public key;

When the initial root node signature information is verified, construct a target hash tree according to the initial root node;

Acquiring the local root node of the local hash tree and the target root node of the target hash tree;

The integrity of each terminal device is verified according to the local root node and the target root node.

In the embodiment of the present application, the terminal device is checked for integrity by using the hash tree and the root node signature of the hash tree, so that both the terminal device and the verification server only need to sign the root node of the related hash tree, and There is no need to sign every file, which greatly reduces the calculation amount of the terminal device and the verification server, and eases the calculation burden of the terminal device and the verification server.

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 a 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;

The second-level initial hash tree is a hash tree constructed by each aggregation gateway according to each first-level initial hash tree corresponding to each aggregation gateway.

Specifically, the process of constructing the secondary initial hash tree by the aggregation gateway includes:

Acquiring the second signature public key sent by each of the terminal devices;

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

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

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 can construct the corresponding terminal device according to the sorted target files. Each leaf node of the first-level initial hash tree. Here, the first preset sorting method may be a sorting method in ascending order (a→z) according to the first letter of the file name f_req, or may be a sorting method in descending order (z→a) according to the first letter of the file name f_req.

For example, when constructing the second-level 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 may according to the first-level initial hash tree corresponding to the sorted terminal devices The first-level initial root node of is constructed the second-level initial hash tree corresponding to the aggregation gateway. 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 small to large sorting manner according to the device identification (such as ID number) of the terminal device. The sorting method.

Here, by transferring most of the signature verification process to the aggregation gateway, the calculation amount of the verification server can be effectively reduced, and the calculation burden of the verification server can be alleviated.

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

Acquiring a request file sent by the file server, where the request file is a file requested by each terminal device from the file server;

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

Constructing a second-level local hash tree corresponding to each of the aggregation gateways according to each of the first-level local root nodes, and obtaining the second-level local root node of each of the second-level local hash trees;

The local hash tree is constructed according to each of the second-level local root nodes.

It should be understood that when constructing the first-level local hash tree corresponding to the terminal device, the request files corresponding to the terminal device can be sorted according to the first preset sorting method used in the construction 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 files. Similarly, when constructing the secondary 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 of the aforementioned secondary 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, during the construction of the local hash tree and the target hash tree, pass Use the same preset sorting method to sort the root nodes at all levels to avoid different hash values caused by different sorts and affect the integrity check result.

Optionally, the checking the integrity of each terminal device according to the local root node and the target root node includes:

If the local root node is the same as the target root node, a verification result that the integrity verification of the terminal device passes is obtained;

If the local root node and the target root node are not the same, obtain a verification result that the integrity check of the terminal device fails, and compare the local hash tree with the target hash tree;

According to the comparison result of the local hash tree and the target hash tree, a target terminal device that fails the integrity check is determined.

Specifically, the local hash tree and the target hash tree are both ternary hash trees, so as to reduce the level of the hash tree through the ternary hash tree, reduce the amount of signature calculation, and at the same time, it is convenient to quickly locate the integrity damage Terminal equipment.

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:

The file obtaining module is used to obtain the file to be verified sent by the file server and the integrity check information of the file to be verified, and the integrity check information includes the target of the target hash tree using the first signature private key The root node signature information obtained by the root node signature, 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, the target hash The tree is a hash tree constructed based on all files in the file server;

A signature information verification module, configured to use the first signature public key to verify the root node signature information;

The current root node construction module is configured to construct the current root node corresponding to the target hash tree according to the file to be verified and the child nodes when the root node signature information is verified;

The integrity check module is used to check the integrity of the file to be checked according to the current root node and the target root node.

Optionally, the integrity verification device further includes:

A version verification information acquisition module, configured to acquire target version verification information of the file to be verified, where the target version verification information is version verification information generated according to the target file version of the file to be verified;

The version legitimacy verification module is configured to verify 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.

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 the device identification of the terminal device;

The version legality check module includes:

The first hash value calculation unit is configured to calculate 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;

The second hash value calculation unit is configured to use the second signature public key in the chameleon signature information to calculate the second chameleon hash value corresponding to the chameleon signature information;

The version legitimacy verification unit is configured to verify the version legitimacy of the file to be verified according to the first chameleon hash value and the second chameleon hash value.

For example, the integrity verification device further includes:

The device private key obtaining module is configured to obtain the device private key corresponding to the terminal device according to the device identifier.

Optionally, the version verification information obtaining module is specifically configured to obtain the target version verification information of the file to be verified sent by the verification server, and the target version verification information is the verification server according to the file The target file version of the file to be verified sent by the server and version verification information generated by the device identifier of the terminal device that receives the file to be verified.

Specifically, the target hash tree is a trigeminal hash tree.

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:

The integrity information obtaining module is used to obtain the integrity check information of each terminal device. The integrity check information includes the initial root node signature information obtained by signing the initial root node of the initial hash tree with the first signature private key And a first signature public key corresponding to the first signature private key;

A signature information verification module, configured to verify the initial root node signature information by using the first signature public key;

A hash tree construction module, configured to construct a target hash tree according to the initial root node when the initial root node signature information is verified;

A root node obtaining module, configured to obtain the local root node of the local hash tree and the target root node of the target hash tree;

The integrity check module is used to check the integrity of each terminal device according to the local root node and the target root node.

Specifically, the aggregation gateway includes:

A signature public key acquisition unit, configured to acquire a second signature public key sent by each of the terminal devices;

The signature information verification unit is configured to use each of the second signature public keys to verify the first-level root node signature information sent by each of the terminal devices;

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

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

A request file obtaining module, configured to obtain a request file sent by the file server, where the request file is a file requested by each terminal device from the file server;

A first-level local hash tree construction module, configured to construct a first-level local hash tree corresponding to each terminal device according to the request file, and obtain the first-level local root node of each first-level local hash tree;

The second-level local hash tree building module is used to construct the second-level local hash tree corresponding to each of the aggregation gateways according to each of the first-level local root nodes, and obtain the second-level local hash tree of each of the second-level local hash trees. Root node

The local hash tree construction module is used to construct the local hash tree according to each of the second-level local root nodes.

Optionally, the integrity check module includes:

A verification result obtaining unit, configured to obtain a verification result that the integrity verification of the terminal device passes if the local root node is the same as the target root node;

A hash tree comparison unit, configured to obtain a verification result 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 and the target hash tree;

The target terminal device determining unit is configured to determine the target terminal device that fails the integrity check according to the comparison result of the local hash tree and the target hash tree.

Specifically, the local hash tree and the target hash tree are both trigeminal hash trees.

In a fifth aspect, an embodiment of the present application provides a terminal device, including a memory, a processor, and a computer program stored in the memory and running on the processor. When the processor executes the computer program, The integrity verification method described in any one of the above-mentioned first aspects is implemented.

In a sixth aspect, an embodiment of the present application provides a verification server, including a memory, a processor, and a computer program stored in the memory and running on the processor. When the processor executes the computer program, The integrity verification method described in any one of the above-mentioned second aspects is implemented.

In a seventh aspect, an embodiment of the present application provides a computer-readable storage medium, the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, any of the first or second aspects described above is implemented. The integrity check method described in one item.

In an eighth aspect, the embodiments of the present application provide a computer program product, which when the computer program product runs on a terminal device, causes the terminal device to execute the integrity verification method described in any one of the above-mentioned first aspects.

In a ninth aspect, an embodiment of the present application provides a computer program product, which when the computer program product runs on a verification server, causes the verification server to execute the integrity verification method described in any one of the above second aspects.

Description of the drawings

FIG. 1 is a system schematic diagram of an integrity verification system provided by an embodiment of the present application;

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

FIG. 3 is a schematic structural diagram of a mobile phone to which the integrity verification method provided by an embodiment of the present application is applicable;

FIG. 4 is a schematic diagram of a software architecture to which the integrity verification method provided by an embodiment of the present application is applicable;

FIG. 5 is a schematic flowchart of an integrity verification method provided by an embodiment of the present application;

Fig. 5a is an example diagram of a three-layer target hash tree constructed by an embodiment of the present application;

FIG. 5b is an example diagram of a hash tree provided by an embodiment of the present application;

FIG. 5c is an example diagram of a hash tree constructed by an embodiment of the present application;

FIG. 6 is a schematic flowchart of an integrity verification method provided by another embodiment of the present application;

Fig. 6a is an example diagram of a hash tree constructed by another embodiment of the present application;

FIG. 7 is a schematic structural diagram of an integrity verification device provided by an embodiment of the present application;

FIG. 8 is a schematic structural diagram of an integrity verification device provided by another embodiment of the present application;

Fig. 9 is a schematic structural diagram of a verification server provided by an embodiment of the present application.

Detailed ways

In the following description, for the purpose of illustration rather than limitation, specific details such as a specific system structure and technology are proposed for 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 can 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 avoid unnecessary details from obstructing the description of this application.

It should be understood that when used in the specification and appended claims of this application, the term "comprising" indicates the existence of the described features, wholes, steps, operations, elements and/or components, but does not exclude one or more other The existence or addition of features, wholes, steps, operations, elements, components, and/or collections thereof.

It should also be understood that the term "and/or" used in the specification and appended claims of this application refers to any combination of one or more of the items listed in the associated and all possible combinations, and includes these combinations.

As used in the description of this application and the appended claims, the term "if" can be construed as "when" or "once" or "in response to determination" or "in response to detecting ". Similarly, the phrase "if determined" or "if detected [described condition or event]" can be interpreted as meaning "once determined" or "in response to determination" or "once detected [described condition or event]" depending on the context ]" or "in response to detection of [condition or event described]".

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

The reference to "one embodiment" or "some embodiments" described in the specification of this application means that one or more embodiments of this application include a specific feature, structure, or characteristic described in combination with the embodiment. Therefore, the words "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments", etc. appearing in different places in this specification are not necessarily All refer to the same embodiment, but mean "one or more but not all embodiments" unless it is specifically emphasized otherwise. The terms "including", "including", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized.

With the continuous development of electronic technology, the clustering and distributed 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 suffers a network attack, it will affect the security of itself and the entire network system. Therefore, it is imperative to verify the integrity of key configurations, patches, executable files and other important files of terminal equipment. Among them, the file may include the download file of the terminal device and the application file in the terminal device. Here, the downloaded file refers to a 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 running or in use on the terminal device

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

In order 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, which can be achieved by using a hash tree and The integrity check is performed only by signing the root node of the hash tree, without signing each file, which can reduce the calculation amount of the server or terminal device and alleviate the calculation burden of the server or terminal device.

As shown in FIG. 1, in an application scenario of performing integrity verification on a downloaded file of a terminal device, the integrity verification system provided in an 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. Wherein, the terminal device 10 may be in communication connection with the file server 11, the verification server 12, and the key management server 13 respectively. The file server 11 may also be in communication connection with the verification server 12 and the key management server 13 respectively. The verification server 12 may also be in communication connection with the key management server 13. The key management server 13 may distribute corresponding signature keys to the terminal device 10, the file server 11, the verification server 12, and the like.

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 can sign the root node of the target hash tree by obtaining the signature private key from the key management server 13, and can return the signature result and the signature public key to the file server 11. When the file server 11 sends a file to the terminal device 10 based on the file acquisition request of the terminal device 10, it may also send the integrity check information corresponding to the file (including the signature result, the signature public key, and the signature public key). The child nodes related to the file in the target hash tree) are sent to the terminal device 10. After the terminal device 10 obtains the file and the integrity check information, it can first verify the signature result according to the signature public key. When the signature result is verified, it can be based on the file and the integrity check information. The child nodes in constructs the current root node corresponding to the target hash tree; subsequently, the current root node can be compared with the root node of the target hash tree contained in the signature result to determine the file Completeness.

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.

It can be seen from the above that when the integrity check of the downloaded file of the terminal device is performed, the verification server or the file server only needs to sign the root node of the target hash tree, and does not need to sign each file, which greatly The calculation amount of the verification server or the file server is reduced, and the calculation burden of the verification server or the file server is alleviated.

As shown in FIG. 2, in the scenario of performing integrity verification on each terminal device, the integrity verification system may further include an aggregation gateway 14. Wherein, the aggregation gateway 14 may be in communication connection with the terminal device 10, the verification server 12, and the key management server 13 respectively. Here, performing an integrity check on each terminal device refers to performing an integrity check on an application file in each terminal device.

The verification server 12 may obtain each request file sent by the file server 11 in advance, and may construct a local hash tree according to each request file. Wherein, each requested file sent by the file server 11 is a file requested by each terminal device 10 from the file server 11.

When it is necessary to perform an integrity check on each of the terminal devices 10, the verification server 12 may send an integrity check request to each of the terminal devices 10. After each terminal device 10 receives the integrity check request, it can obtain the target file in each terminal device 10 to construct the first-level initial hash tree corresponding to each terminal device, and can obtain each first-level initial hash tree. The first-level initial root node of the 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 including the first signature result is sent to the corresponding aggregation gateway 14. Each aggregation gateway 14 can 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 aggregation gateway 14 then The second-level initial hash tree corresponding to each aggregation gateway can be constructed according to the first-level initial root node of each first-level initial hash tree; then the second-level initial root node of each second-level initial hash tree can be obtained, and The second-level initial root node of the second-level 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 signed. Send to the verification server 12. The verification server 12 can use the corresponding second signature public key to verify each second signature result in each integrity verification information. After each second signature result is verified, the verification server 12 can The target hash tree is constructed according to the second-level initial root node of each second-level initial hash tree, and the target root node of the target hash tree can be compared with the local root node of the local hash tree to determine each The integrity of the terminal equipment.

It can be seen from the above that when performing integrity verification on a terminal device, both the terminal device 10 and the aggregation gateway 14 only need to sign the root node of the relevant hash tree, instead of signing every file. The calculation amount of the terminal device 10 and the aggregation gateway 14 is greatly reduced, and the calculation burden of the terminal device 10 and the aggregation gateway 14 is alleviated.

The terminal device 10 may be a mobile phone, a tablet computer, a wearable device, a vehicle-mounted device, an augmented reality (AR)/virtual reality (VR) device, a notebook computer, an ultra-mobile personal computer (ultra-mobile personal computer). On terminal devices such as computer, UMPC), netbooks, and personal digital assistants (personal digital assistants, PDAs), the embodiments of this application do not impose any restrictions on the specific types of terminal devices.

Take the terminal device 10 as a mobile phone as an example. Fig. 3 shows a block diagram of a part of the structure of a mobile phone provided in an embodiment of the present application. 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, and a processor 380 , And power supply 390 and other components. Those skilled in the art can understand that the structure of the mobile phone shown in FIG. 3 does not constitute a limitation on the mobile phone, and may include more or less components than those shown in the figure, or a combination of some components, or different component arrangements.

The following is a detailed introduction to each component of the mobile phone in conjunction with Figure 3:

The RF circuit 310 can be used for receiving and sending signals during the process of sending and receiving information or talking. In particular, after receiving the downlink information of the base station, it is processed by the processor 380; 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 (LNA), a duplexer, and the like. In addition, the RF circuit 310 can also communicate with the network and other devices through wireless communication. The above-mentioned wireless communication can use any communication standard or protocol, including but not limited to Global System of Mobile Communication (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (Code Division) Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Long Term Evolution (LTE), Email, Short Messaging Service (SMS), etc.

The memory 320 may 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 may mainly include a program storage area and a data storage area. The program storage area may store an operating system, an application program required by at least one function (such as a sound playback function, an image playback function, etc.), etc.; Data created by the use of mobile phones (such as audio data, phone book, etc.), etc. In addition, the memory 320 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one magnetic disk storage device, a flash memory device, or other volatile solid-state storage devices.

The input unit 330 may be used to receive inputted digital or character information, and generate key signal input related to 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 called a touch screen, can collect user touch operations on or near it (for example, the user uses any suitable objects or accessories such as fingers, stylus, etc.) on the touch panel 331 or near the touch panel 331. Operation), and drive the corresponding connection device according to the preset 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 position, 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 the commands sent by the processor 380. In addition, the touch panel 331 can be implemented in multiple types such as resistive, capacitive, infrared, and surface acoustic wave. In addition to the touch panel 331, the input unit 330 may also include other input devices 332. Specifically, the other input device 332 may include, but is not limited to, one or more of a physical keyboard, function keys (such as volume control buttons, switch buttons, etc.), trackball, mouse, and joystick.

The display unit 340 may 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 can cover the display panel 341. When the touch panel 331 detects a touch operation on or near it, it transmits it to the processor 380 to determine the type of the touch event, and then the processor 380 determines the type of the touch event. The type provides corresponding visual output on the display panel 341. Although in FIG. 3, the touch panel 331 and the display panel 341 are used as two independent components to realize the input and input functions of the mobile phone, but in some embodiments, the touch panel 331 and the display panel 341 can be integrated. Realize the input and output functions of the mobile phone.

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 can include an ambient light sensor and a proximity sensor. The ambient light sensor can adjust the brightness of the display panel 341 according to the brightness of the ambient light. The proximity sensor can close the display panel 341 and/or when the mobile phone is moved to the ear. Or backlight. As a kind of motion sensor, the accelerometer sensor can detect the magnitude of acceleration in various directions (usually three-axis), and can detect the magnitude and direction of gravity when it is stationary. It can be used to identify mobile phone posture applications (such as horizontal and vertical screen switching, related Games, magnetometer posture calibration), vibration recognition related functions (such as pedometer, percussion), etc.; as for other sensors such as gyroscopes, barometers, hygrometers, thermometers, infrared sensors, etc., which can also be configured in mobile phones, I will not here Go into details.

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 electrical signal converted from the received audio data to the speaker 361, and the speaker 361 converts it into a sound signal for output; on the other hand, the microphone 362 converts the collected sound signal into an electrical signal, which is then output by the audio circuit 360. After being received, it is converted into audio data, and then processed by the audio data output processor 380, and sent to, for example, another mobile phone via the RF circuit 310, or the audio data is output to the memory 320 for further processing.

WiFi is a short-distance 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. Although FIG. 3 shows the WiFi module 370, it is understandable that it is not a necessary component of the mobile phone, and can be omitted as needed without changing the essence of the invention.

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. It executes by running or executing software programs and/or modules stored in the memory 320, and calling data stored in the memory 320. Various functions and processing data of the mobile phone can be used to monitor 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, where the application processor mainly processes the operating system, user interface, application programs, etc. , The modem processor mainly deals with wireless communication. It can be understood that the foregoing modem processor may not be integrated into the processor 380.

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

Although not shown, the mobile phone may also include a camera. Optionally, the position of the camera on the mobile phone may be front-mounted or rear-mounted, which is not limited in the embodiment of the present application.

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

For example, a mobile phone may include three cameras, of which one is a main camera, one is a wide-angle camera, and one is a telephoto camera.

Optionally, when the mobile phone includes multiple cameras, the multiple cameras may be all front-mounted, or all rear-mounted, or partly front-mounted and another part rear-mounted, which is not limited in the embodiment of the present application.

In addition, although not shown, the mobile phone may also include a Bluetooth module, etc., which will not be repeated here.

Fig. 4 is a schematic diagram of the software structure of a mobile phone according to an embodiment of the present application. Taking the Android system as the mobile phone operating 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. Through the software interface communication between.

As shown in Figure 4, the application layer can be a series of application packages, which can include applications such as short message, calendar, camera, video, navigation, gallery, and call.

The application framework layer provides an application programming interface (application programming interface, API) and a programming framework for applications in the application layer. The application framework layer may include some predefined functions, such as functions for receiving events sent by the application framework layer.

As shown in Figure 4, the application framework layer can include a window manager, a resource manager, and a notification manager.

The window manager is used to manage window programs. The window manager can obtain the size of the display screen, determine whether there is a status bar, lock the screen, take a screenshot, etc. The content provider is used to store and retrieve data and make these data accessible to applications. The data may include videos, images, audios, phone calls made and received, browsing history and bookmarks, phone book, etc.

The resource manager provides various resources for the application, such as localized strings, icons, pictures, layout files, video files, and so on.

The notification manager enables the application to display notification information in the status bar, which can be used to convey notification-type messages, and it can automatically disappear 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 status bar at the top of the system in the form of a chart or scroll bar text, such as a notification of an application running in the background, or a notification that appears on the screen in the form of a dialog window. For example, text messages are prompted in the status bar, prompt sounds, electronic devices vibrate, and indicator lights flash.

The application framework layer can also include:

A view system, which includes visual controls, such as controls that display text, controls that display pictures, and so on. 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 that includes a short message notification icon may include a view that displays text and a view that displays pictures.

The phone manager is used to provide the communication function of the mobile phone. For example, the management of the call status (including connecting, hanging up, etc.).

The system layer can include multiple functional modules. For example: sensor service module, physical state recognition module, 3D graphics processing library (for example: OpenGL ES), etc.

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

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

The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, synthesis, and layer processing.

The system layer can also include:

The surface manager is used to manage the display subsystem and provides a combination of 2D and 3D layers for multiple applications.

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

The hardware abstraction layer is the layer between hardware and software. The hardware abstraction layer can include display drivers, camera drivers, sensor drivers, etc., used to drive related hardware at the hardware layer, such as display screens, cameras, sensors, and so on.

[Embodiment One]

The integrity verification method provided by the first embodiment can be implemented on a mobile phone with the above hardware structure/software structure to verify the integrity of the downloaded file of the mobile phone, that is, after the mobile phone downloads the file from the file server, it can be used in the application The integrity of the file was previously verified by the integrity verification method provided in this embodiment to ensure that the file downloaded by the mobile phone is a file that has not been tampered with, has a legal version, and has a traceable source. The integrity verification method provided in this embodiment will be described in detail below in conjunction with the integrity verification system shown in FIG. 1.

As shown in FIG. 5, the integrity verification method provided in this embodiment may include:

S501. Obtain a file to be verified sent by a file server and integrity verification information of the file to be verified, where the integrity verification information includes signing the target root node of the target hash tree using the first signature private key. The root node signature information of the target hash tree, 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 based on the The hash tree constructed by all the files in the file server;

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

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 send the root node signature information obtained by the signature The signature public key corresponding to the signature is returned to the file server to achieve the purpose of generating the target root node and separating the signature, and reduce the risk of the root node signature information being attacked.

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

For example, the signature key may be the signature key corresponding to the 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), then the target root The root node signature information of the node H_root may be sign(H_root)=(H_root) ^d mod n.

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

In a possible implementation manner, the target hash tree may be a ternary hash tree, so as to reduce the level of the hash tree through the ternary hash tree, and reduce the integrity check information required for the integrity check. Reduce bandwidth usage.

As an example and not a limitation, the leaf node of the target hash tree may be the file name of any file in the file server and the hash value of the file metadata of the file, and other nodes except the leaf node may be It is the hash value of all child nodes of this node.

For example, Figure 5a shows an example diagram of a three-layer target hash tree constructed by the file server. The leaf node H_leaf _i of one layer in the three-layer target hash tree can be H(f_i||matadata _i ), The child node H_father _{j of the} second layer 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 are the child nodes of H_father _j , the third layer The target root node H_root can be H(H_father ₁ ||H_father ₂ ||H_father ₃ ). Here, f_i is the file name, matadata _i is the metadata, || is the connector, and H is the hash function. It should be understood that the hash function may be a secure hash function (for example, SHA-256), or any other type of hash function, which is not limited in this embodiment.

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 for a certain file to the mobile phone, and the mobile phone confirms the file update according to the file update instruction , The file server can send the file to the mobile phone, and can send the integrity check 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.

It is understandable that the integrity verification information may include signature information of the root node of the target hash tree corresponding to the file to be verified, child nodes in the target hash tree that are related to the file to be verified, and the first A signature public key. Wherein, the root node signature information is information obtained by the file server or the verification server using the first signature private key to sign the root node of the target hash tree, and the first signature public key and the The first signature private key corresponds. The child nodes related to the file to be verified in the target hash tree may include _{leaf nodes in the target hash tree that belong to the same parent node H_father j} as the file to be verified, and from the parent node H_father _j to the target root node. The child nodes on the full hash path and the target root node.

Specifically, the child nodes on the complete hash path from the _{parent node H_father j} _{to the target root node refer to all child nodes required by the parent node H_father j to} start generating the target root node of the target hash tree.

For example, in the application scenario shown in Figure 5a, when _{the file f_6 corresponding to H_leaf 6} is the file to be verified sent by the file server to the mobile phone, then the parent node H_father ₂ _{corresponding to H_leaf 6} to the target root node H_root is complete The child nodes on the hash path may include H_father ₁ and H_father ₃ , that is, the child nodes related to the file to be verified f_6 in the target hash tree may include leaf nodes H_leaf ₄ , leaf nodes H_leaf ₅ , and child nodes H_father ₁ , Child node H_father ₃ and root node H_root.

For example, in the application scenario shown in Figure 5b, when _{the file f_6 corresponding to H_leaf 6} is the file to be verified sent by the file server to the mobile phone, then the parent node H_ffather ₂ _{corresponding to H_leaf 6} to the target root node H_root is complete The child nodes on the hash path may include H_ffather ₁ , H_ffather ₃ , H_sfather ₁ , H_sfather ₃ , H_tfather ₂ and H_tfather ₃ , that is, the child nodes related to the file to be verified f_6 in the target hash tree may include leaf nodes H_leaf _4. Leaf node H_leaf ₅ , child node H_ffather ₁ , child node H_ffather ₃ , child node H_sfather ₁ , child node H_sfather ₃ , child node H_tfather ₂ and child node H_tfather _3, and root node H_root.

S502. Use the first signature public key to verify the signature information of the root node.

It should be understood that the integrity check information obtained by the mobile phone may include the root node signature information and the original information corresponding to the root node signature information (that is, the target root node H_root).

Here, after the mobile phone obtains the file to be verified and the integrity verification information corresponding to the file to be verified, the first signature public key in the integrity verification information can be used to verify the root node signature information , To determine whether the integrity check information is a valid and traceable source, so as to determine whether the to-be-verified file is a valid and traceable source.

For example, in an application scenario where 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 mod n, the mobile phone can use the The first signature public key (e, n) verifies the sign (H_root), and obtains the verification information H'_root=(sign(H_root)) ^e mod n, which is based on the verification information H'_root and the The target root node H_root is used to determine whether the integrity check information is the check information whose source is legal and traceable.

Wherein, when the 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 The verification information whose source is legal and traceable can be used for the integrity verification of the document to be verified to determine the integrity of the document to be verified and to determine whether the document to be verified is of a legitimate source and can be verified. Traceable documents. When the verification information H'_root and the target root node H_root are not the same, a verification result that the root node signature information verification fails can be obtained, wherein the verification failure indicates the integrity check The information is not verified information whose source is legal and traceable, so that it can be directly determined that the document to be verified is a document whose source is illegal.

It should be noted that when the verification result is the verification result that the root node signature information verification fails, the mobile phone can verify the file to be verified as having an illegal source in the verification log of the mobile phone. The results are recorded to facilitate the subsequent review of the verification results. At the same time, the mobile phone can also display the verification results on the display screen of the mobile phone in real time, reminding the user where the mobile phone is located that the file currently obtained may be of an illegal source File to inform users of the current file download risk.

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;

It should be understood that when the root node signature information is verified, that is, when the integrity verification information is verification information whose source is legal and traceable, the mobile phone can use the file to be verified and the integrity verification information. The child nodes in the verification information construct the current root node corresponding to the target hash tree.

For example, when the file to be verified is the file f_6 _{corresponding to H_leaf 6} shown in Figure 5a, the mobile phone can first calculate the file to be verified according to the file name f_6 of the file f_6 and the component metadata matadata _{6 '} The leaf node H'_leaf ₆ = H(f_6||matadata ₆ '); then, according to H'_leaf ₆ and the integrity check information, _{the leaf nodes H'_leaf 6} belonging to the same parent node H_leaf ₄ and H'_leaf 6 The leaf node H_leaf ₅ calculates the child node H'_father ₂ = H(H(f_4||matadata ₄ )||H(f_5||matadata ₅ )||H'(f_6||matadata ₆ )); finally, it can be based on _{The child nodes H_father 1} and H_father ₃ on the complete hash path from H'_father ₂ and H'_father ₂ to the target root node H_root are calculated to obtain the current root node H'_root = H(H_father ₁ | |H'_father ₂ ||H_father ₃ ).

Here, the mobile phone may also restore and construct the target hash tree according to 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 of the target hash tree Node, that is, the mobile phone can first calculate the file name of the file to be verified and the hash value of the file metadata, and can determine the calculated hash value as the leaf node corresponding to the file to be verified, and then can be based on the The leaf node and the child nodes in the integrity check information restore and construct the target hash tree.

It should be noted that the position of each node in the target hash tree constructed by the restoration is the same as the position of each node in the original target hash tree, so as to avoid the error of the node position and the calculation error of the hash value, thereby reducing the integrity The accuracy of the calibration. That is, the integrity check information may also include the position information of the leaf node corresponding to the file to be checked in the target hash tree and the position information of each of the child nodes in the target hash tree. Therefore, when the mobile phone restores and constructs the target hash tree according to the file to be verified and each child node in the integrity check information, it can combine the location information of the file to be verified with each child node. The location information of the node is restored to construct the target hash tree. For example, when the file to be verified is the file f_6 _{corresponding to H_leaf 6} shown in FIG. 5a, the mobile phone can construct the child node according to the file to be verified and the integrity check information as shown in FIG. 5c. The target hash tree shown.

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

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 may be Compare 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, the verification result of the integrity verification of the file to be verified can be obtained, and the integrity verification refers to the file to be verified. It is a file whose content obtained from the file server is complete and has not been tampered with, and whose source is legal and traceable; when the current root node is not the same as the target root node, the information of the file to be verified can be obtained The result of the verification that the integrity check fails, which means that the file to be verified is a file whose integrity has been damaged, that is, it can indicate that the file to be verified is a file whose content has been tampered with.

It should be noted that when the mobile phone obtains the verification result that the integrity check of the file to be verified fails, the mobile phone can verify the integrity of the file to be verified in the verification log of the mobile phone. The failed verification results are recorded to facilitate the subsequent review of verification results. At the same time, the mobile phone can also display the verification results on the display screen of the mobile phone in real time, reminding the user where the mobile phone is located about the files currently obtained It may be a file whose content has been tampered with, and inform the user of the current file download risk.

In this embodiment, the integrity check is performed on the downloaded file of the mobile phone by using the hash tree and the way of signing the root node of the hash tree, so that the integrity check can be completed by signing the root node only, without the need Signing each file greatly reduces the amount of signature calculation and eases the calculation burden.

In the integrity verification, when the document to be verified has a historical version, if the document to be verified in the historical version is used to replace the document to be verified in the current version and sent to the mobile phone, the mobile phone is checking the received document to be verified. When performing integrity verification, you can also get the verification result of the integrity verification of the file to be verified, but the file to be verified obtained by the mobile phone at this time is not the file requested by the mobile phone or is not expected by the file server A file sent to a mobile phone, but it may be a file reposted by an attacker. Therefore, in order to resist replay attacks using historical version files, after verifying the integrity of the file to be verified according to the current root node and the target root node, when the obtained verification result is the to-be-verified file When verifying the verification result that the integrity of the file is verified, the mobile phone can also obtain the verification information of the target version of the file to be verified, and can be based on the current file version of the file to be verified and the target version The verification information verifies the validity of the version of the file to be verified, wherein the target version verification information may be version verification information generated according to the target file version of the file to be verified.

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 real-time according to the target of the file to be verified. The file version generates target version verification information of the file to be verified, 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.

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 may also send the target file of the file to be verified in real time. The version is sent to the verification server, and the verification server may generate the target version verification information of the file to be verified according to the target file version, and may verify the target version based on the version verification information acquisition request sent by the mobile phone. The verification information is sent to the mobile phone to perform risk sharing by generating verification information by the verification server, thereby reducing the risk of the target version verification information being attacked.

For example, the file server or the verification server may use a signature key corresponding to any signature algorithm to sign the target file version, and may use the version signature information corresponding to the target file version obtained by the signature as the all Describe the target version verification information.

Here, after the mobile phone obtains the verification result that the integrity verification of the file to be verified is passed, it may send a version verification request to the file server or the verification server to determine the verification of the file to be verified through the version verification. Check whether the file is a replacement file, etc. 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 use the received signature public key to verify the The version signature information is verified, and the verified target file version can be compared 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 legal version, that is, the file to be verified of the current file version can be considered as a legal file sent by the file server; if the two are not the same, then It can be determined that the file to be verified of the current file version is 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 by the file server to the mobile phone may have been processed by the attacker File replacement, etc.

In a possible implementation manner, the file server or the verification server may sign the target file version using the chameleon signature algorithm, that is, the target version verification information may be based on the target file version and the The chameleon signature information generated by the device identifier of the terminal device uses the non-repudiation, non-interactivity, and non-transmission characteristics of the chameleon signature to ensure the unique legitimacy of the version information and reduce the risk of leakage.

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 may also use the chameleon signature algorithm to generate the information of the sent file to be verified in real time. The target file version and the chameleon signature information of the device identification (such as the device ID or device number of the mobile phone, etc.) of the mobile phone receiving the file to be verified.

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 may also send the target file of the file to be verified in real time. The version and the device identification of the mobile phone receiving the file to be verified are sent to the verification server, and the verification server may use the chameleon signature algorithm to generate the target file version and the chameleon signature information corresponding to the device identification to pass the verification server Perform the chameleon signature operation to share the risk, thereby reducing the risk of the target version verification information being attacked.

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

First, the key management server can randomly select two large prime numbers p and q, so that p=kq+1, and select an element of order q

Then you can randomly select the device private key corresponding to the device ID req_ID through the key management server

Calculate the device public key y=g ^x mod p corresponding to the device private key x, and send the device private key x to the mobile phone corresponding to the device identification req_ID. At the same time, it can also send the related information of the device public key (req_ID, y, g, p) Send to the verification server.

After the verification server receives the target file version vers_f_req and the device identification req_ID sent by the file server, it may first generate a signature key corresponding to the verification server, for example, may generate a signature private key d corresponding to the verification server The signature public key (e, n) corresponding to the verification server; then a chameleon random number can be selected

And can use the chameleon random number r and the related information of the device public key sent by the key management server to calculate the chameleon hash value of the target file version vers_f_req h_req_ID = g ^vers_f_req g ^rx mod p; finally, the signature corresponding to the verification server can be used The private key signs the calculated chameleon hash value h_req_ID sign(h_req_ID)=(h_req_ID) ^d mod n, so as to obtain the chameleon signature information corresponding to the target file version vers_f_req (req_ID, vers_f_req, r, sign(h_req_ID), ( e, n), g, p), and can 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 mobile phone version verification information acquisition request .

It should be understood that the process of the file server using the chameleon signature algorithm to generate the chameleon signature information is similar to the process of the verification server using the chameleon signature algorithm to generate the chameleon signature information, and the basic principles are the same. For the sake of brevity, it will not be repeated here.

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 corresponding file to be verified. The first chameleon hash value of the current file version vers_f_req'h_req_ID' = g ^vers_f_req' g ^rx mod p; then the signature public key (e, n) in the chameleon signature information can be used to calculate the corresponding chameleon signature information The second chameleon hash value H'=(sign(h_req_ID)) ^e mod n; finally, 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' legality. 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, the file to be verified can be considered as the The 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 not the same, 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 version of the file to be verified is illegal. The file to be verified may be a file that has been replaced or reposted.

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 that the file version of the file to be verified is illegal in the verification log of the mobile phone. , In order to facilitate the subsequent review of the verification results. At the same time, the mobile phone can also display the verification results on the display screen of the mobile phone in real time, reminding the user where the mobile phone is located that the file currently obtained may be replaced or renewed. The illegal files that are posted inform users of the current file download risk.

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.

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 may also be based on the target file version of the file to be verified in real time. And the target file versions of all other files in the file server generate a version hash tree, and the root node of the version hash tree can be signed to generate target version verification information corresponding to the file to be verified. Or the file server may send the root node of the version hash tree to the verification server, so that the root node of the version hash tree is signed by the verification server to generate the corresponding file to be verified. The target version verification information. When receiving the version verification information acquisition request sent by the mobile phone, the file server or the verification server may send the target version verification information (including the root node signature information of the version hash tree, the signature public key, and The relevant child node in the version hash tree) is sent 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.

The process of verifying the current file version of the file to be verified based on the version hash tree by the mobile phone is similar to the process of verifying the integrity of the file to be verified based on the target hash tree by the mobile phone. The basic principle is The same, for the sake of brevity, I will not repeat them here.

[Embodiment 2]

The integrity check method provided in the second embodiment can be implemented in the verification server of the integrity check system as shown in FIG. 2 to perform integrity check on each terminal device, that is, the integrity provided by this embodiment can be used The verification method performs integrity verification on the application files in each terminal device to ensure that the application files in each terminal device are files that have not been tampered with and have a legal version. The integrity verification method provided in this embodiment will be described in detail below in conjunction with the integrity verification system shown in FIG. 2.

As shown in FIG. 6, the integrity verification method provided by this embodiment may include:

S601. Obtain integrity check information of each terminal device, where the integrity check information includes the initial root node signature information obtained by signing the initial root node of the initial hash tree with the first signature private key, and the signature information associated with the first The first signature public key corresponding to the signature private key;

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. Wherein, 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 each aggregation A hash tree constructed by the first-level initial hash tree of each terminal device corresponding to the gateway.

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

Take the terminal device as a mobile phone as an example. When the integrity of each mobile phone needs to be verified, 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 construct the corresponding mobile phone. The first-level initial hash tree. Among them, the target files in each mobile phone are 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 file name of the target file f_req, The hash value of the file metadata matadata_f_req and the file version vers_f_req, 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).

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 a corresponding target file of the mobile phone according to the sorted target files. Each leaf node of the initial hash tree. Here, the first preset sorting method may be a sorting method in ascending order (a→z) according to the first letter of the file name f_req, or may be a sorting method in descending order (z→a) according to the first letter of the file name f_req.

As shown in Figure 6a, the mobile phone ID1 can construct the first-level initial hash tree corresponding to the mobile phone ID1 according to the target files in the mobile phone ID1 (f1_req_ID1 to f3_req_ID1), and the mobile phone ID2 can construct the mobile phone according to the target files in the mobile phone ID2 (f1_req_ID2 to f9_req_ID2) The first-level initial hash tree corresponding to ID2, the mobile phone ID3 can construct the first-level initial hash tree corresponding to the mobile phone ID3 according to the target files (f1_req_ID3 to f3_req_ID3) in the mobile phone ID3. Among them, f1_req_ID1 is the first target file sorted according to the aforementioned first preset sorting method in the mobile phone ID1, f3_req_ID1 is the third target file sorted according to the aforementioned first preset sorting method in the mobile phone ID1, and other expressions are the same as this similar.

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_IDi mod n to obtain the first-level initial root node signature information, and the initial integrity check information that contains the first-level initial root node signature information Info_IDi={Hash_IDi, sign(Hash_IDi), (e_IDi, n )} is sent to the aggregation gateway corresponding to the mobile phone, where d_IDi is the signature private key corresponding to the mobile phone IDi, and (e_IDi, n) is the signature public key corresponding to the mobile phone IDi.

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

It should be understood that after the aggregation gateway receives the initial integrity verification information Info_Dii sent by each mobile phone to which it corresponds, it can use the signature public key corresponding to each mobile phone to perform the first level of the initial integrity verification information Info_IDi sent by each mobile phone. The initial root node signature information sign(Hash_IDi) is verified. When the first-level initial root node signature information sign(Hash_IDi) corresponding to the aggregation gateway is verified, the aggregation gateway can construct the first-level initial root node according to the received initial integrity check information Info_IDi. The secondary initial hash tree corresponding to the aggregation gateway. Here, the process of verifying the first-level initial root node signature information sign (Hash_IDi) in the initial integrity check information Info_IDi is similar to the process of verifying the root node signature information of the target root node in the first embodiment, and the basic principle is The same, for the sake of brevity, I will not repeat them here.

When constructing the second-level 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 according to the first-level initial hash tree of the first-level initial hash tree corresponding to the sorted mobile phones. The root node constructs the secondary initial hash tree corresponding to the aggregation gateway. Here, the second preset sorting method may be a sorting method from small to large according to the device identification of the mobile phone (such as a mobile phone ID number), or may be a sorting method according to the device identification of the mobile phone (such as a mobile phone ID number) from large to small. The sorting method.

As shown in Figure 6a, the aggregation gateway Agg1 can construct the second-level initial root nodes Hash_ID1, Hash_ID2, and Hash_ID3 of the first-level initial hash tree sent by its corresponding mobile phone ID1, mobile phone ID2, and mobile phone ID3. Level initial hash tree. Among them, mobile phone ID1 is the first mobile phone sorted according to the above second preset sorting method, mobile phone ID2 is the second mobile phone sorted according to the above second preset sorting method, and mobile phone ID3 is sorted according to the above second preset sorting method The third mobile phone is ranked after sorting by way.

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 can use the signature private key corresponding to the aggregation gateway (that is, the first Sign(Hash_Aggi)=(Hash_Aggi) ^d_Aggi mod n to obtain the signature information of the second-level initial root node, and can include the second-level initial root node The integrity verification information Info_Aggi={Hash_Aggi, sign(Hash_Aggi), (e_Aggi, n)} of the node signature information is sent to the verification server. Among them, 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.

For example, it is possible to sign the secondary initial root node of each secondary initial hash tree by obtaining the first signature private key corresponding to each aggregation gateway from the key management server.

S602. Use the first signature public key to verify the initial root node signature information.

Here, after the verification server receives the integrity check information Info_Aggi sent by each aggregation gateway, it can use the first signature public key corresponding to each aggregation gateway to check the integrity check information Info_Aggi sent by each aggregation gateway. The signature information of the secondary initial root node is verified.

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, and the first signature public key corresponding to the aggregation gateway Agg2 can be used. The key B verifies 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 integrity verification information sent by the aggregation gateway Agg1 The signature information of the secondary initial root node in Info_Agg3 is verified.

It should be understood that the process of verifying the secondary initial root node signature information in the integrity check information Info_Aggi is similar to the process of verifying the root node signature information of the target root node in the first embodiment, and the basic principles are the same, for the sake of brevity , I won’t repeat it here.

S603: When the initial root node signature information is verified, construct a target hash tree according to the initial root node;

It should be understood that when the signature information of each secondary initial root node is verified, the verification server can construct the target hash tree according to the secondary initial root node in each integrity verification information Info_Aggi it receives. Wherein, the target hash tree may also be a ternary hash tree, so as to reduce the level of the hash tree through the ternary hash tree, reduce the amount of signature calculation, and at the same time facilitate the subsequent rapid location of the terminal device whose integrity has been compromised.

Specifically, the verification server may first sort the aggregation gateways according to a third preset sorting manner, and then may construct the target hash according to the secondary initial root node of the secondary initial hash tree corresponding to the sorted aggregation gateway. tree. Here, the third preset sorting manner may be a sorting manner from small to large according to the gateway identification of the aggregation gateway (for example, the gateway ID number), or may be according to the gateway identification of the aggregation gateway (for example, the gateway ID number) Sort from largest to smallest.

S604. Obtain the local root node of the local hash tree and the target root node of the target hash tree.

It should be noted that after the mobile phone obtains the file from the file server, the file server may also send the requested files (including file name, file version, file metadata, etc.) requested by each mobile phone to the verification in real time or periodically. Server, the verification server can construct a first-level local hash tree corresponding to each mobile phone according to the request file. For example, the first-level local hash tree corresponding to mobile phone A can be constructed according to the request files a, b, c, d, e, f, g, h, and i corresponding to mobile phone A, and the request files j, k corresponding to mobile phone B can be constructed. And l construct the first-level local hash tree 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 brevity, it will not be repeated here.

It should be understood that when the verification server constructs the first-level local hash tree corresponding to the mobile phone, it can perform the request file corresponding to the mobile phone according to the first preset sorting method used in the construction of the first-level initial hash tree described above. Perform sorting, and construct a first-level local hash tree corresponding to the mobile phone according to the sorted request file.

For example, when the first preset sorting method used in the construction of the first-level initial hash tree described above is the sorting method in ascending order (a→z) according to the initials of the file name f_req, the verification server then The requested files can be sorted according to the sorting method of the first letter of the file name f_req in ascending order (a→z).

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 compare the aggregation gateway according to the aggregation gateway. The first-level local root nodes are grouped, 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 corresponding first-level local root nodes of each aggregation gateway can be constructed according to the first-level local root node corresponding to each aggregation gateway. The secondary local hash tree.

It should be understood that when the verification server constructs the second-level local hash tree corresponding to the aggregation gateway, the verification server may determine the corresponding second-level hash tree of the aggregation gateway according to the second preset ordering method used in the construction of the second-level initial hash tree. Each mobile phone is sorted, 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 mobile phone.

For example, when the second preset sorting method used in the construction of the aforementioned secondary initial hash tree is sorting according to the mobile phone ID number from small to large, the verification server can then use the mobile phone ID number Sort the mobile phones in a descending order.

Here, after the verification server obtains the second-level local hash tree corresponding to each aggregation gateway, it can obtain the second-level local root node of each second-level local hash tree, and can also obtain the second-level local root node corresponding to each second-level local hash tree. The local root node constructs the local hash tree.

It should be understood that when the verification server constructs the local hash tree, the aggregation gateways may be sorted according to the third preset sorting method used in the construction of the target hash tree, and may be sorted according to the sorting method. The second-level local root node of the second-level local hash tree corresponding to the subsequent aggregation gateway constructs the local hash tree.

In this embodiment, during the construction of 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 sorts, thereby affecting the integrity Result of sexual verification.

S605: Check the integrity of each terminal device according to the local root node and the target root node.

Specifically, if the local root node is the same as the target root node, the verification server may determine that the integrity check of the terminal device passes, that is, the application files in all terminal devices have not been tampered with or replaced, etc. 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 fails, that is, the integrity of one or more terminal devices is damaged, In other words, the application files stored in one or more terminal devices have been tampered with or replaced.

For example, when the verification result that the integrity check of the terminal device fails, the verification server may compare the local hash tree with the target hash tree to locate the integrity failure. The damaged target terminal device can determine the target terminal device whose integrity has been damaged according to the comparison result of the local hash tree and the target hash tree.

This embodiment uses a hash tree and signs the root node of the hash tree to verify the integrity of the terminal device, so that both the terminal device and the aggregation gateway only need to sign the root node of the relevant hash tree. Each file needs to be signed, which greatly reduces the calculation amount of terminal devices and aggregation gateways, and eases the calculation burden of terminal devices and aggregation gateways. At the same time, by transferring most of the signature verification process to the aggregation gateway, the calculation amount of the verification server can be reduced and the calculation burden of the verification server can be alleviated.

It should be understood that the size of the sequence number of each step in the foregoing embodiment does not mean the order of execution, and the execution sequence of each process should be determined by its function and internal logic, and should not constitute any limitation to the implementation process of the embodiment of the present application.

Corresponding to the integrity check method described in the above embodiment, FIG. 7 and FIG. 8 show the structural block diagram of the integrity check device provided by the embodiment of the present application. Example related parts.

As shown in FIG. 7, an embodiment of the present application provides an integrity verification device, which is applied to a terminal device, and the integrity verification device may include:

The file obtaining module 701 is configured to obtain the file to be verified sent by the file server and the integrity check information of the file to be verified. The integrity check information includes the information about the target hash tree using the first signature private key. The root node signature information obtained by the signature of the target root node, 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, the target has Xishu is a hash tree constructed based on all files in the file server;

The signature information verification module 702 is configured to use the first signature public key to verify the root node signature information;

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

The integrity check module 704 is configured to check the integrity of the file to be checked according to the current root node and the target root node.

Optionally, the integrity verification device may further include:

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

Correspondingly, the version legality verification module may include:

For example, the integrity verification device may further include:

Specifically, the target hash tree is a trigeminal hash tree.

As shown in FIG. 8, an embodiment of the present application provides an integrity verification device, which is applied to a verification server, and the integrity verification device may include:

The integrity information acquisition module 801 is configured to acquire the integrity verification information of each terminal device, the integrity verification information including the initial root node signature obtained by signing the initial root node of the initial hash tree with the first signature private key Information and the first signature public key corresponding to the first signature private key;

The signature information verification module 802 is configured to use the first signature public key to verify the initial root node signature information;

A hash tree construction module 803, configured to construct a target hash tree according to the initial root node when the initial root node signature information is verified;

The root node obtaining module 804 is configured to obtain the local root node of the local hash tree and the target root node of the target hash tree;

The integrity check module 805 is configured to check the integrity of each terminal device according to the local root node and the target root node.

Specifically, the aggregation gateway may include:

In a possible implementation manner, the integrity verification device may further include:

Optionally, the integrity check module may include:

It should be noted that the information interaction and execution process between the above-mentioned devices/units are based on the same concept as the method embodiment of this application, and its specific functions and technical effects can be found in the method embodiment section for details. I won't repeat it here.

Those skilled in the art can clearly understand that, for the convenience and conciseness of description, only the division of the above functional units and modules is used as an example. In practical applications, the above functions can be allocated to different functional units and modules as needed. Module completion, that is, the internal structure of the device is divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist alone physically, or two or more units can be integrated into one unit. The above-mentioned integrated units can be hardware-based Formal realization can also be realized in the form of a software functional unit. 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 protection scope of the present application. For the specific working process of the units and modules in the foregoing system, reference may be made to the corresponding process in the foregoing method embodiment, which will not be repeated here.

FIG. 9 is a schematic structural diagram of a verification server provided by an embodiment of the application. As shown in FIG. 9, the verification server 9 of this embodiment includes: at least one processor 90 (only one is shown in FIG. 9), a processor, a memory 91, and a processor that is stored in the memory 91 and can be processed in the at least one processor. The computer program 92 running on the processor 90, when the processor 90 executes the computer program 92, implements the steps in any of the integrity verification method embodiments in the second embodiment.

The verification server 9 may be a computing device such as a desktop computer, a notebook, a palmtop computer, and a cloud server. The verification server may include, but is not limited to, a processor 90 and a memory 91. Those skilled in the art can understand that FIG. 9 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 less components than shown in the figure, or a combination of certain components, or different components. , For example, can also include input and output devices, network access devices, and so on.

The processor 90 may be a central processing unit (Central Processing Unit, CPU), and the processor 90 may also be other general-purpose processors, digital signal processors (Digital Signal Processors, DSPs), and application specific integrated circuits (Application Specific Integrated Circuits). , ASIC), Field-Programmable Gate Array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor or the like.

The memory 91 may be an internal storage unit of the verification server 9 in some embodiments, 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 equipped on the verification server 9, a smart media card (SMC), a secure digital (Secure Digital, SD) card, flash card (Flash Card), etc. Further, the storage 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. The memory 91 can also be used to temporarily store data that has been output or will be output.

Similarly, the terminal device also includes at least one processor, a memory, and a computer program that is stored in the memory and can run on the at least one processor. The processor implements the foregoing when the computer program is executed. Steps in any of the integrity verification method embodiments in the first embodiment. Here, the principles of the processor and the memory are the same as those of the processor 90 and the memory 91 described above. For the sake of brevity, the details are not repeated here.

The embodiments of the present application also provide a computer-readable storage medium, where the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in the foregoing method embodiments can be implemented.

The embodiments of the present application provide a computer program product. When the computer program product runs on a terminal device, the terminal device can implement the steps in the first embodiment of the method when executed by the terminal device.

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 the verification server is executed.

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 implementation of all or part of the processes in the above-mentioned embodiment methods in the present application can be accomplished by instructing relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium. The computer program can be stored in a computer-readable storage medium. When executed by the processor, the steps of the foregoing method embodiments can be implemented. Wherein, the computer program includes computer program code, and the computer program code may be in the form of source code, object code, executable file, or some intermediate forms. The computer-readable storage medium may at least include: any entity or device capable of carrying computer program code to the device/terminal device, recording medium, computer memory, read-only memory (ROM, Read-Only Memory), and random access memory (RAM, Random Access Memory), electric carrier signal, telecommunications signal and software distribution medium. For example, U disk, mobile hard disk, floppy disk or CD-ROM, etc. In some jurisdictions, in accordance with legislation and patent practices, computer-readable storage media cannot be electrical carrier signals and telecommunication signals.

In the above-mentioned embodiments, the description of each embodiment has its own focus. For parts that are not described in detail or recorded in an embodiment, reference may be made to related descriptions of other embodiments.

A person of ordinary skill in the art may realize that the units and algorithm steps of the examples described in combination with the embodiments disclosed herein can be implemented by electronic hardware or a combination of computer software and electronic hardware. Whether these functions are executed by hardware or software depends on the specific application and design constraint conditions of the technical solution. Professionals and technicians can use different methods for each specific application to implement the described functions, but such implementation should not be considered beyond the scope of this application.

In the embodiments provided in this 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 only illustrative. For example, the division of the modules or units is only a logical function division, and there may be other divisions in actual implementation, such as Multiple units or components can be combined or integrated into another system, or some features can be omitted or not implemented. In addition, the displayed or discussed mutual coupling or direct coupling or communication connection may be indirect coupling or communication connection through some interfaces, devices or units, and may be in electrical, mechanical or other forms.

The units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the objectives of the solutions of the embodiments.

The above-mentioned embodiments are only used to illustrate the technical solutions of the present application, not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still implement the foregoing The technical solutions recorded in the examples are modified, or some of the technical features are equivalently replaced; these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the application, and should be included in Within the scope of protection of this application.

Claims

An integrity verification method, characterized in that it is applied to a terminal device, and the integrity verification method includes:

Obtain the file to be verified sent by the file server and the integrity check information of the file to be verified, where the integrity check information includes the root obtained by signing the target root node of the target hash tree with the first signature private key Node signature information, 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 based on the file Hash tree constructed by all files in the server;

Verifying the signature information of the root node by using the first signature public key;

When the root node signature information is verified, construct the current root node corresponding to the target hash tree according to the file to be verified and the child nodes;

The integrity of the file to be verified is verified according to the current root node and the target root node.
5. The integrity verification method of claim 1, wherein after the verification of the integrity of the file to be verified according to the current root node and the target root node, the method comprises:

Acquiring target version verification information of the file to be verified, where the target version verification information is version verification information generated according to the target file version of the file to be verified;

The validity of the version 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.
3. The integrity verification method of claim 2, wherein the target version verification information is chameleon signature information generated according to the target file version and the device identification of the terminal device;

The verifying the version legality 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:

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;

Calculating the second chameleon hash value corresponding to the chameleon signature information by using the second signature public key in the chameleon signature information;

Verifying the legality of the version of the file to be verified according to the hash value of the first chameleon and the hash value of the second chameleon.
The integrity verification method of claim 3, wherein the first step of the current file version is calculated according to the device private key corresponding to the terminal device and the chameleon random number in the chameleon signature information. Before the Chameleon hash value, it includes:

Acquire the device private key corresponding to the terminal device according to the device identifier.
3. The integrity verification method of claim 2, wherein said obtaining the target version verification information of the file to be verified comprises:

Obtain the target version verification information of the file to be verified sent by the verification server, where the target version verification information is the target file version of the file to be verified sent by the file server and the receiving station according to the verification server The version verification information generated by the device identifier of the terminal device of the file to be verified.
The integrity verification method according to any one of claims 1 to 5, wherein the target hash tree is a trigeminal hash tree.
An integrity verification method, characterized in that it is applied to a verification server, and the integrity verification method includes:

Obtain the integrity check information of each terminal device, the integrity check information includes the initial root node signature information obtained by signing the initial root node of the initial hash tree with the first signature private key, and the private signature information with the first signature. The first signature public key corresponding to the key;

Verifying the initial root node signature information by using the first signature public key;

When the initial root node signature information is verified, construct a target hash tree according to the initial root node;

Acquiring the local root node of the local hash tree and the target root node of the target hash tree;

The integrity of each terminal device is verified according to the local root node and the target root node.
The integrity verification method of claim 7, wherein the initial hash tree comprises a primary initial hash tree and a secondary initial hash tree, and the initial root node is the secondary initial hash tree. The root node of Xishu;

The first-level initial hash tree is a hash tree constructed by each terminal device according to each target file in each terminal device;

The second-level initial hash tree is a hash tree constructed by each aggregation gateway according to each first-level initial hash tree corresponding to each aggregation gateway.
8. The integrity verification method of claim 8, wherein the process of constructing the secondary initial hash tree by the aggregation gateway comprises:

Acquiring the second signature public key sent by each of the terminal devices;

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

When the signature information of each first-level root node is verified, the second-level initial hash tree is constructed according to the first-level initial root node of each first-level initial hash tree.
8. The integrity verification method according to claim 8, characterized in that, before said obtaining the local root node of the local hash tree, it comprises:

Acquiring a request file sent by the file server, where the request file is a file requested by each terminal device from the file server;

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

Constructing a second-level local hash tree corresponding to each of the aggregation gateways according to each of the first-level local root nodes, and obtaining the second-level local root node of each of the second-level local hash trees;

The local hash tree is constructed according to each of the second-level local root nodes.
8. The integrity verification method according to claim 7, wherein the verifying the integrity of each terminal device 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 that the integrity verification of the terminal device passes is obtained;

If the local root node and the target root node are not the same, obtain a verification result that the integrity check of the terminal device fails, and compare the local hash tree with the target hash tree;

According to the comparison result of the local hash tree and the target hash tree, a target terminal device that fails the integrity check is determined.
The integrity verification method according to any one of claims 7 to 11, wherein the local hash tree and the target hash tree are both trigeminal hash trees.
An integrity verification device, which is characterized in that it is applied to a terminal device, and the integrity verification device includes:

The file obtaining module is used to obtain the file to be verified sent by the file server and the integrity check information of the file to be verified, and the integrity check information includes the target of the target hash tree using the first signature private key The root node signature information obtained by the root node signature, 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, the target hash The tree is a hash tree constructed based on all files in the file server;

A signature information verification module, configured to use the first signature public key to verify the root node signature information;

The current root node construction module is configured to construct the current root node corresponding to the target hash tree according to the file to be verified and the child nodes when the root node signature information is verified;

The integrity check module is used to check the integrity of the file to be checked according to the current root node and the target root node.
The integrity verification device of claim 13, wherein the integrity verification device further comprises:

A version verification information acquisition module, configured to acquire target version verification information of the file to be verified, where the target version verification information is version verification information generated according to the target file version of the file to be verified;

The version legitimacy verification module is configured to verify 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.
The integrity verification device of claim 14, wherein the target version verification information is chameleon signature information generated according to the target file version and the device identifier of the terminal device;

The version legality check module includes:

The first hash value calculation unit is configured to calculate 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;

The second hash value calculation unit is configured to use the second signature public key in the chameleon signature information to calculate the second chameleon hash value corresponding to the chameleon signature information;

The version legitimacy verification unit is configured to verify the version legitimacy of the file to be verified according to the first chameleon hash value and the second chameleon hash value.
15. The integrity verification device of claim 15, wherein the integrity verification device further comprises:

The device private key obtaining module is configured to obtain the device private key corresponding to the terminal device according to the device identifier.
The integrity verification device of claim 14, wherein the version verification information acquisition module is specifically configured to acquire the target version verification information of the file to be verified sent by the verification server, and the target The 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 that receives the file to be verified.
The integrity verification device according to any one of claims 13 to 17, wherein the target hash tree is a trigeminal hash tree.
An integrity verification device, characterized in that it is applied to a verification server, and the integrity verification device includes:

The integrity information obtaining module is used to obtain the integrity check information of each terminal device. The integrity check information includes initial root node signature information obtained by signing the initial root node of the initial hash tree with the first signature private key And a first signature public key corresponding to the first signature private key;

A signature information verification module, configured to verify the initial root node signature information by using the first signature public key;

A hash tree construction module, configured to construct a target hash tree according to the initial root node when the initial root node signature information is verified;

A root node obtaining module, configured to obtain the local root node of the local hash tree and the target root node of the target hash tree;

The integrity check module is used to check the integrity of each terminal device according to the local root node and the target root node.
The integrity check device according to claim 19, wherein the initial hash tree comprises a first-level initial hash tree and a second-level initial hash tree, and the initial root node is the second-level initial hash tree. The root node of Xishu;

The first-level initial hash tree is a hash tree constructed by each terminal device according to each target file in each terminal device;

The second-level initial hash tree is a hash tree constructed by each aggregation gateway according to each first-level initial hash tree corresponding to each aggregation gateway.
21. The integrity verification device of claim 20, wherein the aggregation gateway comprises:

A signature public key acquisition unit, configured to acquire a second signature public key sent by each of the terminal devices;

The signature information verification unit is configured to use each of the second signature public keys to verify the first-level root node signature information sent by each of the terminal devices;

The hash tree construction unit is configured to construct the second-level initial hash tree according to the first-level initial root node of each first-level initial hash tree when the signature information of each of the first-level root nodes is verified.
22. The integrity verification device of claim 20, wherein the integrity verification device further comprises:

A request file obtaining module, configured to obtain a request file sent by the file server, where the request file is a file requested by each terminal device from the file server;

A first-level local hash tree construction module, configured to construct a first-level local hash tree corresponding to each terminal device according to the request file, and obtain the first-level local root node of each first-level local hash tree;

The second-level local hash tree building module is used to construct the second-level local hash tree corresponding to each of the aggregation gateways according to each of the first-level local root nodes, and obtain the second-level local hash tree of each of the second-level local hash trees. Root node

The local hash tree construction module is used to construct the local hash tree according to each of the second-level local root nodes.
The integrity check device of claim 19, wherein the integrity check module comprises:

A verification result obtaining unit, configured to obtain a verification result that the integrity verification of the terminal device passes if the local root node is the same as the target root node;

A hash tree comparison unit, configured to obtain a verification result 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 and the target hash tree;

The target terminal device determining unit is configured to determine the target terminal device that fails the integrity check according to the comparison result of the local hash tree and the target hash tree.
The integrity verification device according to any one of claims 19 to 23, wherein the local hash tree and the target hash tree are both trigeminal hash trees.
A terminal device, comprising a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program as claimed in claims 1 to 6. The integrity verification method of any one of the above.
A verification server, comprising a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program as claimed in claims 7 to 12. The integrity verification method described in any one of items.
A computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, the integrity check according to any one of claims 1 to 12 is implemented method.