WO2023216077A1

WO2023216077A1 - Attestation method, apparatus and system

Info

Publication number: WO2023216077A1
Application number: PCT/CN2022/091803
Authority: WO
Inventors: 王辰昱; 吴永铮; 魏卓
Original assignee: 华为技术有限公司
Priority date: 2022-05-09
Filing date: 2022-05-09
Publication date: 2023-11-16

Abstract

An attestation method, apparatus and system, which relate to the technical field of security. The method comprises: a proof node acquiring a target address sequence, wherein the target address sequence points to target data to be attested; the proof node obtaining a proof result according to the target data; and the proof node providing the proof result to an attestation node, wherein the proof result is associated with a first moment, and the proof result and the first moment are used for credibility attestation of the target data. The method helps to improve security in a system architecture of a software-based attestation technique.

Description

A verification method, device and system

Technical field

This application relates to the field of security technology, and in particular to a verification method, device and system.

Background technique

Authentication (attestation) technology is one of the key technologies in trusted computing and is used to verify whether the data to be verified on the side of the verified device is in a trusted state.

Currently commonly used verification technologies include software-based attestation technology and hardware-based attestation technology. Among them, based on software verification technology, the proving program and the data to be verified run in the same execution environment (such as a regular execution environment (rich execution environment, REE)) with potential malicious programs without any difference, and the proving program and the data to be verified may can be tampered with by malicious programs. In hardware-based verification technology, the proving program and data to be verified are isolated from potential malicious programs based on hardware. The proving program and data to be verified run in a trusted execution environment (TEE), and potential malicious programs run in REE. , the certification program and the data to be verified running on the TEE cannot be tampered with by potential malicious programs in the REE. The security based on hardware verification technology is higher than the security based on software verification technology.

However, in some practical application scenarios (such as smart car scenarios), system architecture based on hardware verification technology is often not used due to actual performance considerations. Moreover, in a scenario based on hardware isolation, the running context needs to frequently switch between REE and TEE, which will bring huge performance overhead. If applications with high real-time requirements (such as smart car control) are placed in TEE, it will Will bring huge performance loss. Therefore, in order to ensure performance, it is more suitable to apply software-based verification technology.

There is an urgent need to improve security in system architectures based on software verification technology.

Contents of the invention

Embodiments of the present application provide a verification method, device and system, which help improve security in a system architecture based on software verification technology.

In the first aspect, embodiments of the present application provide a verification method that can be executed by the certification node of the first device. The certification node can run the certification program preset in the first device and calculate based on the target data to be verified. The verification result to be verified is provided to the verification node of the second device, so that the verification node performs credibility verification on the target data.

Wherein, the method may include: the certification node obtains a target address sequence, wherein the target address sequence points to the target data to be verified; the certification node obtains the certification result according to the target data; the certification node provides the verification node with the The certification result is provided, wherein the certification result is associated with a first moment, and the certification result and the first moment are used for credibility verification of the target data.

Through the above method, the proof node and the verification node can be configured to: when verifying the credibility of the target data, in addition to the proof results from the proof node, information from other check dimensions can also be added at the same time, such as proof result correlation. the first moment. Furthermore, the certification node can provide information of at least one checking dimension, such as certification results, to the verification node, so that the verification node can combine information of at least two checking dimensions (for example, including but not limited to the certification results from the certification node, the certification results The first moment of association, etc.) jointly verify the credibility of the target data, thereby improving security in the system architecture based on software verification technology. At the same time, the communication volume between the proving node and the verification node is small, and it will not bring too much performance overhead, nor will it have a great impact on other services (such as security services) of the first device to which the proving node belongs. This solution can balance security and performance.

In conjunction with the first aspect, in a possible implementation manner, the certification node obtains a target address sequence, including: the certification node obtains a target parameter; the certification node generates the target address sequence according to the target parameter and a target function. , wherein the target parameter includes a random number, and the target function includes a pseudo-random generator function.

Through the above method, in an optional implementation, the objective function can be configured at the proof node. After the proving node starts running the proving program, the target function can be run in response to the target parameters to generate the target address sequence. The proof node can read the target data to perform calculations based on the target address sequence. Among them, the target parameter includes a random number, and a pseudo-random generator function is used to generate the target address sequence, which can add randomness to the calculation process based on the target data, thereby improving security.

In conjunction with the first aspect, in a possible implementation manner, the certification node obtains the target parameters, including: the certification node obtains the target parameters from the challenge node or the real-time operating system RTOS of the first device to which the certification node belongs, Wherein, the challenge node is a node that triggers verification of the credibility of the target data.

Through the above method, the challenge node or the RTOS of the first device can trigger the certification node to run the certification program through the target parameter to perform the reading and calculation process of the target data, so that the verification method of the embodiment of the present application can be implemented. More flexible.

In conjunction with the first aspect, in a possible implementation manner, the certification node obtains the target address sequence, including: the certification node obtains the target address sequence from the RTOS of the first device to which the certification node belongs, wherein, The target address sequence is generated by the RTOS based on target parameters and target functions.

Through the above method, in another optional implementation, the objective function can be configured in the RTOS of the first device to which the proving node belongs. After the proving node starts running the proving program, the objective function located in the RTOS can run in response to the target parameters. , to generate the target address sequence. Prove that the node can obtain the target address sequence from the RTOS in order to read the target data based on the target address sequence for calculation. The target parameter may include a random number, and the target function may include a pseudo-random generator function. Using the pseudo-random generator function to generate a target address sequence can add randomness to the entire calculation process and improve security.

In connection with the first aspect, in a possible implementation manner, the certification node runs on at least one first resource unit, and the at least one first resource unit is a resource unit included in the first device to which the certification node belongs, so The resource unit described above is used at least to run the program. For example, the at least one first resource unit runs programs other than key programs of the first device, where the key programs at least include programs that perform security tasks and/or programs that perform scheduling tasks. For example, the resource unit may be a processor core of the first device.

Through the above method, the first device to which the certification node belongs can include multiple resource units, and the first device can schedule at least one first resource unit for the certification node, so that the certification program of the certification node can run on at least one first resource unit, This allows the running of the certification program to occupy less resource units occupied by key programs, thereby reducing the impact of the certification process on other services on the first device side.

In conjunction with the first aspect, in a possible implementation, the target address sequence includes at least two addresses, the at least two addresses point to at least two data blocks included in the target data, and the certification node is based on the Obtaining a certification result for the target data includes: the certification node uses a target algorithm to calculate at least two data blocks contained in the target data in a first order to obtain the certification result. The target algorithm may adopt a serial calculation structure, and the target algorithm may include a hash algorithm.

Through the above method, the proof node can use a serial calculation structure to calculate at least two data blocks contained in the target data in sequence until the proof result is obtained. In the case where the first device includes multiple resource units, this serial calculation method can effectively prevent an attacker from using the multi-resource unit characteristic of the first device to construct an algorithm to execute the verification algorithm in parallel, thereby reducing the execution time.

In conjunction with the first aspect, in a possible implementation, the target address sequence includes the at least two addresses, the at least two addresses point to at least two data blocks included in the target data, and further includes: in the When the length of the data block pointed to by the first address among the at least two addresses is greater than the data length threshold, the data block pointed by the first address is segmented.

Through the above method, the data length threshold may be a data length threshold preset for the target algorithm. When calculating the data blocks contained in the target data, it is proved that the node can segment the data blocks whose data length exceeds the data length threshold according to the data characteristics of different data blocks contained in the target data and obtain the corresponding of data sub-blocks. Furthermore, the proof node can perform calculations based on data blocks that do not require data segmentation and data sub-blocks obtained after segmentation, thereby ensuring that all data in different data blocks pointed to by addresses in the target address sequence can be calculated.

In conjunction with the first aspect, in a possible implementation, the method further includes: the proving node obtains a base address; the proving node obtains a base address according to the values of at least two addresses in the base address and the target address sequence. , calculate the original value pointing to the address of the target data, and the original value is used to read the target data.

Through the above method, considering that when the first device runs the program for the first time, the operating system of the first device will randomize the base address of the program when loading the program, and the base address will not change after running. In order to reduce the impact of base address randomization on generating the target address sequence, the proof node can obtain the base address and subtract the base address from the value of each address in the target address sequence to obtain the original value of the address pointing to the target data. , to use the original value to read the target data and try to avoid the address being tampered with by the attacker.

In conjunction with the first aspect, in a possible implementation, the method further includes: the certification node determines tag information based on the original value; the certification node provides the tag information to the verification node, and the tag The information is used to derive the original value in reverse.

Through the above method, the proving node can provide the tag information corresponding to the original value of the address pointing to the target data to the verification node, so that the verification node can reversely deduce the original value based on the tag information, thereby performing the same calculation process on the verification node side. , the mirror data can be read and calculated based on the original value obtained by reverse derivation, and a credible certification result can be obtained, which can be used to verify the credibility of the target data. It should be noted that in this embodiment of the present application, during a verification process, the target address sequence generated according to the target parameters may include at least two addresses. Correspondingly, the certification node may convert the original addresses pointing to at least two addresses of the target data. The tag information corresponding to the value is provided to the verification node. This method does not require the transmission of complete pointer data and can reduce the communication volume between the proving node and the verification node.

In conjunction with the first aspect, in a possible implementation, the target data includes data in memory space allocated for at least one of the following programs: a key program or a certification program run by the certification node. The key programs at least include programs that perform security tasks and/or programs that perform scheduling tasks.

Through the above method, the key programs of the first device to which the proving node belongs that need to be securely protected and the data in the program memory space of the proving program need to be verified. The target function of the first device can be configured as: in the generated target address sequence The address should at least point to the data in the program memory space of the key program and the certification program to reduce the possibility of these data being tampered with by an attacker. In conjunction with the first aspect, in a possible implementation, the first device to which the certification node belongs and the second device to which the verification node belongs are located in the same system-on-chip SoC, wherein the first device is located in the SoC untrusted hardware, the second device is located in the trusted hardware of the SoC; or the first device and the second device are different devices, wherein the first device is an untrusted device, The second device is a trusted device.

Through the above method, the first device to which the certification node belongs and the second device to which the verification node belongs can include multiple product forms. Among them, it is only necessary to ensure that the second device is located on trusted hardware or is a trusted device, and the first device can be located on untrusted hardware or is an untrusted device. Through the verification method of the embodiment of the present application, although the proof node is running on In a non-trusted environment, the verification results from the certification node can be verified by the verification node running in the trusted environment to determine the credibility of the target data on the first device side, with little impact on the first device side. Under the condition of performance and other business execution, the security of target data can still be guaranteed.

In conjunction with the first aspect, in a possible implementation, when the target data satisfies a preset trust condition, the trustworthiness verification of the target data passes; wherein the trust condition includes: the proof The proof result provided by the node is the same as the proof result obtained by the verification node according to the target parameter, and the first time interval associated with the first moment is within the time range allowed by the verification node.

Through the above method, trust conditions can be set based on the information of at least two inspection dimensions, so that during the verification process, the target data can be verified by judging whether the obtained information of the at least two inspection dimensions meets the preset trust conditions. Credibility. It should be noted that this is only an illustration of the trustworthy conditions in the embodiments of the present application without any limitation. In other embodiments, when the check dimensions are changed or other check dimension information is added, the trustworthy conditions can be modified accordingly. , the embodiment of the present application does not limit this.

The first time interval associated with the first moment may be the execution time of the calculation process on the proving node side. When the challenge node issues a challenge to the proving node at the second moment, it can simultaneously instruct the verification node, and the verification node can learn the revelation moment of the challenge. When the verification node receives the certification result from the certification node at the first moment, the verification node can learn the end moment of the challenge. The first time interval can be the time difference between the first moment and the second moment and the time obtained by the allowed time error. interval. If the first time interval is within the allowed time error range, it means that the algorithm has not been tampered with in the execution time dimension, and the target data is credible at least in the algorithm execution time dimension. If the first time interval is not within the allowed time error range, it means that the algorithm may have been tampered with in the execution time dimension, and the target data is not trustworthy at least in the algorithm execution time dimension.

In the second aspect, embodiments of the present application provide a verification method, which can be executed by a verification node on the second device side. The verification node can run a verification program preset in the second device, and perform verification according to the verification result to be verified. (for example, the first certification result from the certification node), verifying the credibility of the target data on the first device side.

Wherein, the method includes: the verification node obtains a target parameter, the target parameter includes a random number; the verification node obtains a first certification result from the certification node, wherein the first certification result is the certification node according to the to-be-verified The target data is obtained, and the first certification result is associated with the first time; the verification node verifies the credibility of the target data based on the target parameters, the first certification result and the first time.

Through the above method, the verification node and the certification node can be configured such that, in addition to the first certification result from the certification node, when verifying the credibility of the target data, information from other checking dimensions can also be added at the same time, such as The first moment of proof of the correlation of the results. Furthermore, the verification node can jointly verify the credibility of the target data based on the information to be verified obtained from the certification node (such as the first certification result from the certification node) and other information (such as the first moment associated with the first certification result), This improves security in system architectures based on software verification technology. At the same time, the communication volume between the verification node and the proving node is small, and it will not bring too much performance overhead, nor will it have a great impact on other services (such as security services) of the first device to which the proving node belongs. This solution can balance security and performance.

In conjunction with the second aspect, in a possible implementation manner, the verification node obtains the target parameters, including: the verification node obtains the target parameters from the challenge node or the RTOS of the second device to which the verification node belongs, wherein, The challenge node is a node that triggers verification of the credibility of the target data.

Through the above method, the RTOS of the challenge node or the second device can trigger the certification node to run the verification program through the target parameters to perform the credibility verification process of the target data, making the implementation of the verification method of the embodiment of the present application more flexible.

In conjunction with the second aspect, in a possible implementation, the verification node verifies the credibility of the target data based on the target parameters, the first certification result and the first moment, including: The verification node obtains a second certification result based on the target parameters; the verification node verifies the credibility of the target data based on the second certification result, the first certification result and the first time.

Through the above method, the verification node can obtain the second certification result according to the target parameters. The second certification result is credible and can be used to verify whether the first certification result from the certification node is credible, thereby verifying the target on the first device side. Credibility of data.

It should be noted that in the embodiment of the present application, the verification result can obtain the second verification result according to the target parameters in at least one way.

Example 1, the verification node and the proof node can use the same method to calculate and obtain the corresponding proof results. The verification node obtains the second certification result according to the target parameter, which may include: the verification node obtains a target address sequence according to the target parameter, wherein the target address sequence points to the mirror data of the target data; The verification node obtains the second certification result based on the mirror data. Similarly, the verification node obtains the target address sequence based on the target parameters, which may include: the verification node generates the target address sequence based on the target parameters and the target function; or, the verification node generates the target address sequence based on the target parameters. , obtaining the target address sequence from the RTOS of the second device to which the verification node belongs, wherein the target address sequence is generated by the RTOS according to the target parameters and the target function. The objective function may include a pseudo-random generation function. For implementation details of similar methods, please refer to the relevant description of the first aspect above and will not be described again here.

In a possible implementation of Example 1, the target address sequence includes at least two addresses, and the at least two addresses point to at least two data blocks contained in the mirror data, and the verification node performs the verification according to the Obtaining the second certification result from the mirror data includes: the verification node adopts a target algorithm to calculate at least two data blocks contained in the mirror data in a first order to obtain the second certification result. For example, the target algorithm may adopt a serial calculation structure, and the target algorithm may include a hash algorithm.

In a possible implementation of Example 1, the target address sequence includes the at least two addresses, the at least two addresses point to at least two data blocks included in the mirror data, and further includes: in the When the length of the data block pointed to by the first address among the at least two addresses is greater than the data length threshold, the data block pointed by the first address is segmented.

In a possible implementation of Example 1, the method further includes: the verification node obtains tag information from the certification node; the verification node determines, based on the tag information and the target address sequence, the direction to the The original value of the address of the mirror data, which is used to read the mirror data.

Example 2: The verification node does not need to perform the same calculation steps as the proof node, but can obtain the second proof result by looking up the table. For example, the verification node obtains the second certification result according to the target parameter, which may include: the verification node uses the target parameter as an index to obtain the second certification result from a first list, wherein the first The list includes a plurality of parameters, including the target parameter, and a proof result associated with each parameter.

In a possible implementation of Example 2, the method may further include: the verification node obtaining tag information from the certification node; the verification node using the target parameter as an index, from the first list Obtaining the second certification result includes: the verification node using the target parameter and the tag information as an index to obtain the second certification result from the first list. It should be understood that this tag information is an example of information for the interaction between the proving node and the verification node. The transmission and use of the tag information depends on the specific algorithm adopted by the proving node side. When the proving node uses a pointer to the target data in order to eliminate the impact of base address randomization, The original value of the address, the proving node can determine the tag information based on the original value, and transfer the tag information to the verification node in association with the first proof result, for the verification node to reversely deduce the original value, or search for the corresponding tag information in combination with the original value The proof results are not limited by the embodiments of this application.

In conjunction with the second aspect, in a possible implementation manner, the first device to which the certification node belongs and the second device to which the verification node belongs are located in the same system-on-chip SoC, wherein the first device is located in the SoC untrusted hardware, the second device is located in the trusted hardware of the SoC; or the first device and the second device are different devices, wherein the first device is an untrusted device, The second device is a trusted device.

In conjunction with the second aspect, in a possible implementation, the second device further includes a challenge node, which is a node that triggers verification of the credibility of the target data; or, the second device and the The third device to which the challenge node belongs is a different device, and the third device and the first device are different devices.

In conjunction with the second aspect, in a possible implementation, the verification node verifies the credibility of the target data based on the target parameters, the first certification result and the first moment, including: The verification node determines whether the target data satisfies the preset trust conditions according to the target parameters, the first certification result and the first moment, so as to verify the credibility of the target data; wherein, the The credible conditions include: the first certification result is the same as the second certification result obtained by the verification node according to the target parameter, and the first time interval associated with the first moment is within the time range allowed by the verification node. Inside.

In the third aspect, embodiments of the present application provide a device for proving a node, including: an acquisition unit, configured to acquire a target address sequence, wherein the target address sequence points to target data to be verified; and a processing unit, configured to Obtain a proof result according to the target data; a transceiver unit configured to provide the proof result to a verification node, wherein the proof result is associated with a first time, and the proof result and the first time are used for the target data credibility verification.

In conjunction with the third aspect, in a possible implementation, the acquisition unit is configured to: acquire target parameters; generate the target address sequence according to the target parameters and the target function; wherein the target parameters include random numbers, so The objective function includes a pseudo-random generation function.

In conjunction with the third aspect, in a possible implementation, the acquisition unit is configured to: acquire the target parameter from a challenge node or a real-time operating system RTOS of the first device to which the certification node belongs, wherein the challenge node is Trigger nodes that verify the authenticity of the target data.

Combined with the third aspect, in a possible implementation, the acquisition unit is configured to: acquire the target address sequence from the RTOS of the first device to which the certification node belongs, wherein the target address sequence is the target address sequence according to the RTOS. Target parameters and objective functions are generated.

In conjunction with the third aspect, in a possible implementation, the certification node runs on at least one first resource unit, and the at least one first resource unit is a resource unit included in the first device to which the certification node belongs, so The resource unit described above is used at least to run the program.

In conjunction with the third aspect, in a possible implementation, the at least one first resource unit runs programs other than key programs of the first device, where the key programs at least include programs that perform security tasks and/or A program that performs scheduled tasks.

In conjunction with the third aspect, in a possible implementation, the target address sequence includes at least two addresses, the at least two addresses point to at least two data blocks included in the target data, and the processing unit is configured to: A target algorithm is used to calculate at least two data blocks contained in the target data in a first order to obtain the proof result.

Combined with the third aspect, in a possible implementation manner, the target algorithm adopts a serial computing structure, and the target algorithm includes a hash algorithm.

Combined with the third aspect, in a possible implementation, the target address sequence includes the at least two addresses, the at least two addresses point to at least two data blocks included in the target data, and further includes: in the When the length of the data block pointed to by the first address among the at least two addresses is greater than the data length threshold, the data block pointed by the first address is segmented.

In conjunction with the third aspect, in a possible implementation, the processing unit further includes: obtaining a base address; and calculating data pointing to the target based on the values of the base address and at least two addresses in the target address sequence. The original value of the address, which is used to read the target data.

Combined with the third aspect, in a possible implementation, the processing unit is further configured to: determine tag information according to the original value; the certification node provides the tag information to the verification node, and the tag information is Derive the original value in reverse.

Combined with the third aspect, in a possible implementation, the target data includes data in the memory space allocated for at least one of the following programs: a key program or a certification program run by the certification node, and the key program at least includes : Programs that perform security tasks and/or programs that perform scheduling tasks.

In conjunction with the third aspect, in a possible implementation manner, the first device to which the certification node belongs and the second device to which the verification node belongs are located in the same system-on-chip SoC, wherein the first device is located in the SoC untrusted hardware, the second device is located in the trusted hardware of the SoC; or the first device and the second device are different devices, wherein the first device is an untrusted device, The second device is a trusted device.

In conjunction with the third aspect, in a possible implementation manner, when the target data satisfies a preset trust condition, the trustworthiness verification of the target data passes; wherein the trust condition includes: the proof The result is the same as the certification result obtained by the verification node, and the first time interval associated with the first moment is within the time range allowed by the verification node.

In the fourth aspect, embodiments of the present application disclose a device for verifying a node, including: an acquisition unit for obtaining target parameters, where the target parameters include random numbers; and obtaining the first certification result from the certification node, wherein, The first proof result is obtained by the proof node based on the target data to be verified, and the first proof result is associated with the first moment; the determination unit is used to determine the target parameter, the first proof result and the At the first moment, the credibility of the target data is verified.

In conjunction with the fourth aspect, in a possible implementation manner, the acquisition unit is configured to: acquire the target parameter from a challenge node or an RTOS of a second device to which the verification node belongs, wherein the challenge node is the one that triggers the verification. A node that describes the credibility of the target data.

In conjunction with the fourth aspect, in a possible implementation, the determination unit is configured to: obtain a second certification result according to the target parameter; and the verification node obtains a second certification result according to the second certification result, the first certification result and At the first moment, the credibility of the target data is verified.

In conjunction with the fourth aspect, in a possible implementation, the acquisition unit is configured to: acquire a target address sequence according to the target parameter, wherein the target address sequence points to mirror data of the target data; the device further A processing unit is included for obtaining the second proof result based on the mirror data.

Combined with the fourth aspect, in a possible implementation manner, the acquisition unit is configured to generate the target address sequence according to the target parameter and the target function. Alternatively, the acquisition unit is configured to: acquire the target address sequence from the RTOS of the second device to which the verification node belongs based on the target parameter, where the target address sequence is generated by the RTOS based on the target parameter and the target function. . Wherein, the objective function includes a pseudo-random generation function.

In conjunction with the fourth aspect, in a possible implementation, the target address sequence includes at least two addresses, the at least two addresses point to at least two data blocks included in the mirror data, and the processing unit is configured to: The verification node uses a target algorithm to calculate at least two data blocks contained in the mirror data in a first order to obtain the second certification result.

Combined with the fourth aspect, in a possible implementation manner, the target algorithm adopts a serial computing structure, and the target algorithm includes a hash algorithm.

In conjunction with the fourth aspect, in a possible implementation, the target address sequence includes the at least two addresses, the at least two addresses point to at least two data blocks included in the mirror data, and further includes: in the When the length of the data block pointed to by the first address among the at least two addresses is greater than the data length threshold, the data block pointed by the first address is segmented.

In conjunction with the fourth aspect, in a possible implementation, the obtaining unit is further configured to: obtain tag information from the certification node; the determining unit is further configured to determine the pointing direction based on the tag information and the target address sequence. The original value of the address of the mirror data, the original value is used to read the mirror data.

Combined with the fourth aspect, in a possible implementation, the acquisition unit is configured to: use the target parameter as an index to acquire the second proof result from a first list, where the first list is used to indicate A plurality of parameters and a proof result associated with each parameter, the plurality of parameters including the target parameter.

Combined with the fourth aspect, in a possible implementation, the acquisition unit is also used to acquire tag information from the certification node; use the target parameter as an index to obtain the second certification result from the first list, It includes: the verification node uses the target parameter and the mark information as an index to obtain the second certification result from the first list.

In connection with the fourth aspect, in a possible implementation manner, the first device to which the certification node belongs and the second device to which the verification node belongs are located in the same system-on-chip SoC, wherein the first device is located in the SoC untrusted hardware, the second device is located in the trusted hardware of the SoC; or the first device and the second device are different devices, wherein the first device is an untrusted device, The second device is a trusted device.

In conjunction with the fourth aspect, in a possible implementation, the second device further includes a challenge node, which is a node that triggers verification of the credibility of the target data; or, the second device and the The third device to which the challenge node belongs is a different device, and the third device and the first device are different devices.

In conjunction with the fourth aspect, in a possible implementation manner, the verification node verifies the credibility of the target data based on the target parameter, the first certification result and the first moment, including: The verification node determines whether the target data satisfies the preset trust conditions according to the target parameters, the first certification result and the first moment, so as to verify the credibility of the target data; wherein, the The credible conditions include: the first certification result is the same as the second certification result obtained by the verification node according to the target parameter, and the first time interval associated with the first moment is within the time range allowed by the verification node. Inside.

In a fifth aspect, embodiments of the present application provide a communication system, including a device for implementing the above first aspect and the method described in any possible implementation of the first aspect, and a device for implementing the above second aspect and the second aspect. Any possible device for implementing the method described in this aspect.

In a sixth aspect, embodiments of the present application provide a chip system, including at least one processor and an interface circuit. The processor is configured to execute instructions and/or data interaction through the interface circuit, so that the chip system executes the above-mentioned The method described in the first aspect and any possible implementation of the first aspect, or the method described in the above second aspect and any possible implementation of the second aspect is performed.

In a seventh aspect, embodiments of the present application provide a terminal, including the device described in the above third aspect and any possible implementation of the third aspect, or the chip system described in the above fifth aspect, and/or the above fourth aspect. The device described in any possible implementation manner of the aspect and the fourth aspect, or the chip system described in the fifth aspect, or includes the communication system described in the fifth aspect. For example, the terminal equipment includes but is not limited to: intelligent transportation equipment (such as cars, ships, drones, trains, trucks, etc.), intelligent manufacturing equipment (such as robots, industrial equipment, intelligent logistics, smart factories, etc.), intelligent terminals (Mobile phones, computers, tablets, PDAs, desktops, headphones, speakers, wearable devices, vehicle-mounted devices, etc.).

In an eighth aspect, embodiments of the present application provide a vehicle that can be used to implement the method described in the above first aspect and any possible implementation of the first aspect, and/or to implement the method described in the above second aspect and any possible implementation manner of the first aspect. The method described in any of the two possible implementation methods.

In a ninth aspect, embodiments of the present application provide a vehicle, which may include the device described in the above third aspect and any possible implementation of the third aspect, and/or include the device that implements any of the above fourth aspect and any possible implementation of the fourth aspect. The device described in one possible implementation manner, or includes the communication system described in the fifth aspect.

In a tenth aspect, embodiments of the present application provide a computer-readable storage medium, including a program or instructions. When the program or instructions are executed, the method described in the first aspect and any possible implementation of the first aspect is performed. is executed, or the method described in the above second aspect and any possible implementation manner of the second aspect is executed.

In an eleventh aspect, embodiments of the present application provide a computer program product, which when a computer reads and executes the computer program product, causes the computer to execute the method described in the above-mentioned first aspect and any possible implementation of the first aspect, Alternatively, perform the method described in the above second aspect and any possible implementation manner of the second aspect.

Based on the implementations provided by the above aspects, the embodiments of the present application can be further combined to provide more implementations.

The technical effects that can be achieved by any possible implementation method in any of the above-mentioned second to eleventh aspects can be described with reference to the technical effects that can be achieved by any possible implementation method in any of the above-mentioned first aspects. , duplication will not be discussed.

Description of the drawings

Figure 1 shows a schematic diagram of the principle of the verification technology according to the embodiment of the present application;

Figure 2 shows a schematic diagram of the data section in the program memory space according to the embodiment of the present application;

Figure 3 shows the software-based verification architecture of the embodiment of the present application;

Figure 4 shows the hardware-based verification structure of the embodiment of the present application;

Figure 5 shows a schematic diagram of the system structure of an example of the embodiment of the present application;

Figure 6 shows a schematic diagram of a verification framework according to an embodiment of the present application;

Figure 7 shows a schematic diagram of another verification framework according to the embodiment of the present application;

Figure 8 shows a schematic diagram of the verification principle based on a dual-core system according to the embodiment of the present application;

Figure 9 shows the calculation process in an example attack scenario according to the embodiment of the present application;

Figure 10 shows an example of the certification result information table according to the embodiment of the present application;

Figure 11 shows the calculation process in another example of an attack scenario according to the embodiment of the present application;

Figure 12 shows the calculation process in another example of an attack scenario according to the embodiment of the present application;

Figure 13 shows the calculation process in another example of an attack scenario according to the embodiment of the present application;

Figure 14 shows a schematic diagram of the verification principle based on a multi-core system according to the embodiment of the present application;

Figure 15 shows a schematic flow chart of the verification method according to the embodiment of the present application;

Figure 16 shows a schematic diagram of a device to be verified according to an embodiment of the present application;

Figure 17 shows a schematic diagram of the verification device according to the embodiment of the present application;

Figure 18 shows a schematic diagram of a communication device according to an embodiment of the present application.

Detailed ways

Some terms involved in the embodiments of this application are first explained below to facilitate understanding by those skilled in the art.

1. Attestation technology:

Verification technology is one of the key technologies in trusted computing and is used to verify whether the device being verified is in a trusted state. For example, whether the code, data status, etc. are as expected.

As shown in Figure 1, verification technology mainly involves the following three parties:

(1) Challenger: The party that poses a security challenge to the prover during the verification process.

The challenger will send a challenge (e.g. denoted as c) to the prover. This challenge (c) is also sent to the validator. Among them, the purpose of the challenger sending the challenge is to add more randomness to the verification process and prevent attackers from forging responses.

(2) Prover: The party whose trustworthy status is checked during the verification process.

The prover can run a preset proof program based on the challenge sent by the challenger, calculate the target data to be verified, calculate the corresponding reply to challenge (c) (for example, represented as r), and provide it to the verifier, in order to Provide the verifier with proof results of whether the prover is in a trustworthy state.

(3) Verifier: During the verification process, the party that verifies and responds to the challenge of the prover.

The verifier can receive the challenge (c) issued by the challenger and the reply (r) issued by the prover for verification, and return the verification result (for example, expressed as V(c, r)) to the challenger. The challenger can know the credibility of the target data on the prover's side based on the verification results.

Among them, depending on the actual verification scenario, the challenger and the verifier can be the same user, such as the same person or the same company. Alternatively, the challenger and the verifier may be different users. For example, the challenger may be a device user and the verifier may be a device manufacturer. This is not limited in the embodiments of this application.

In the following embodiments, for ease of distinction, the challenger may be called a challenge node, the prover may be called a certification node, and the verifier may be called a verification node. The device to which the proving node belongs may be called the first device, the device to which the verification node belongs may be called the second device, and the device to which the challenge node belongs may be called the third device. The proof result obtained by the proof node executing the proof calculation process is called the first proof result. The verification node can obtain a credible proof result (for example, expressed as a second proof result) through the verification method in the embodiment of the present application, and use the second proof As a result, the first certification result from the certification node is verified, and the verification result is obtained.

2. Certification procedure:

The program that the proof node runs when performing the proof calculation process.

In the embodiment of this application, the proof program can be preset in the first device to which the proof node belongs. After receiving the challenge from the challenge node, the first device to which the proof node belongs can run the proof program to perform the proof calculation process to obtain The first proves the result. Among them, the proof program may include but is not limited to subroutines that perform the following calculation processing:

(1) Generate a target address sequence based on the target parameters that trigger the challenge;

(2) Read at least two data blocks contained in the target data according to at least two addresses in the target address sequence;

(3) Process the different data blocks read according to the data characteristics, such as segmentation processing;

(4) Calculate the processed data block according to the target algorithm to obtain the first proof result.

It should be noted that the above subroutine is only an example of the certification program in the embodiment of the present application and does not limit it in any way. In other embodiments, the certification program run by the certification node may include but is not limited to the above subroutine, which will not be discussed here. Repeat.

3. Verification procedure:

The program run by the verification node when performing the verification calculation process.

In the embodiment of this application, the verification program can be preset on the second device to which the verification node belongs. After receiving the challenge from the challenge node, the second device to which the verification node belongs can run the verification program to perform the verification calculation process, and obtain Validation results. Among them, the verification program may include but is not limited to subroutines that perform the following calculation processing:

(1) Obtain the second proof result based on the target parameters that trigger the challenge;

(2) Obtain the first proof result from the proof node;

(3) Verify the credibility of the target data based on the first certification result, the second certification result and other inspection information.

In an optional example of the embodiment of this application, when running the verification program, the method of obtaining the second certification result according to the target parameters may be similar to the method of obtaining the first certification result on the certification node side. For example, the verification program may include but not Limited to subroutines that perform the following calculation processing:

(1.1) Generate a target address sequence based on the target parameters that trigger the challenge;

(1.2) Read at least two data blocks contained in the mirror data of the target data according to at least two addresses in the target address sequence;

(1.3) Process the different data blocks read according to the data characteristics, such as segmentation processing;

(1.4) Calculate the processed data block according to the target algorithm to obtain the second proof result.

In another optional example of the embodiment of this application, the verification program may include a table lookup program. When the verification program is run, the locally stored trusted information can be obtained through table lookup based on the target parameters from the challenge node, and used The trusted information serves as the second certification result to verify the first certification result from the certification node to verify the credibility of the target data of the first device to which the certification node belongs.

It should be noted that the above subroutines are only examples of the verification program in the embodiment of the present application and are not limiting in any way. In other embodiments, the verification program run by the verification node may include but is not limited to the above subroutines, which will not be discussed here. Repeat.

4. Program memory space (or memory segment):

In computers, it generally refers to the main memory space (physical address space) or the memory space allocated by the system for a user program, which is called program memory space.

In this embodiment of the present application, the user program may include any program in the computer, such as the above-mentioned certification program or verification program, as well as the key programs mentioned below. During the running of the program, the data in the program memory space can be divided into different data segments (segments) according to the usage, such as code segment (code segment), read-only data segment (read-only data segment) and general data segment (normal data segment), as shown in Figure 2. Among them, different data sections represent different access rights to the data in the section. For example, the data in the code segment is executable but cannot be read and written; the data in the read-only data segment is not executable and can only be read; the data in the general data segment is not executable but can be read and written. Usually, the program runs in the code segment, and the data block contained in the target data to be verified may be located in the code segment, may be located in the read-only data segment, or may be located in the normal data segment.

In the field of verification technology, for different data sections of the program memory space, the following attack scenarios mainly exist in the industry:

(1)Code injection attack scenario:

Code injection attacks refer to attackers (or attack nodes) modifying code segment data to change the operations performed by the code during execution, thereby performing malicious operations and endangering security.

(2) Key data tampering attack scenarios:

Key data tampering attacks refer to attackers modifying key data (such as static data) in different data sections, such as access permission data, machine configuration data, etc., to indirectly change the operations performed during the execution process, thereby executing malicious operation, endangering safety.

(3) Code pointer (code pointer, CP)/data pointer (data pointer, DP) tampering attack scenario:

Code pointer/data pointer tampering attack means that the attacker indirectly changes the operations performed during the execution process by modifying the code pointer pointing to the code address or the data pointer pointing to the data address, thereby performing malicious operations and endangering security.

Among them, the pointer is the memory address, and the pointer variable is the variable used to store the memory address. Under the same CPU architecture, the length of the storage unit occupied by different types of pointer variables is the same, and the variables that store data are different depending on the type of data. , the length of storage space occupied is also different.

The verification method in the embodiment of this application can ensure the security of the target data at least in the above three attack scenarios.

5. Software based attestation (SWAT) technology:

During the proof calculation process, when the proof program and the verified target data are not protected by hardware (running in the same execution environment as the untrusted program), it is called software-based verification technology.

As shown in Figure 3, the operating environment includes a rich execution environment (REE). The application (APP) running in REE is a program that can be attacked by attackers and is a potentially malicious program. Prove that the program and target data run in the same execution environment as the REE APP, such as the REE operating system (OS). In this case, the certification program runs in an untrusted environment, and the certification program and the data to be verified may be tampered with by malicious programs, and security cannot be guaranteed.

6. Hardware based attestation technology:

During the proof calculation process, when the proof program and the verified target data are protected by hardware (running in a different execution environment from the infeasible program), it is called hardware-based verification.

As shown in Figure 4, the operating environment based on hardware isolation can include REE and trusted execution environment (TEE). REE OS and multiple REE APPs can be run in REE. TEE OS, multiple TEE APPs and certification programs can be run in TEE. Among them, REE OS and multiple REE APPs are located on untrusted hardware and can be attacked by attackers, which are potentially malicious programs. Due to hardware isolation, the proving program and the verified target data are located in the trusted environment of TEE and cannot be tampered with by potential malicious programs in the REE, so that the proving program and the target data are protected. Therefore, from a security perspective, the security of technology based on hardware verification is higher than that of technology based on software verification.

However, due to hardware-based isolation, the running context needs to be frequently switched between REE and TEE, which will bring huge performance overhead. Therefore, if applications with high real-time requirements (such as smart car control) are placed in a TEE, huge performance losses will occur when verifying the trusted status of the device. In some practical application scenarios (such as smart cars), hardware-based verification architecture is often not used due to actual performance considerations. Therefore, in these scenarios with high performance requirements, software verification-based technology needs to be used to verify whether the device is in a trusted state. In verification scenarios based on software verification technology, how to ensure security is still an important issue that needs to be solved.

7. System-on-a-chip (SoC) (or system-on-a-chip):

SoC refers to the technology that integrates a complete system on a single chip and groups all or part of the necessary electronic circuits.

The system generally includes a central processing unit (CPU), memory, and peripheral circuits. In different application scenarios, the specific modules integrated on the SoC can be different and more complex. For example, the system-on-chip of a sound detection device provides all users with an audio receiver, an analog-to-digital converter (ADC), a microprocessor, necessary memory, and input and output logic control on a single chip. equipment.

The SoC applicable to the embodiments of this application may include two parts, such as a CPU part and a hardware security module (HSM) part. The CPU part is untrusted hardware and may include at least two CPU cores (examples of resource units, at least used for running programs). The HSM part is trusted hardware based on hardware isolation. When applied to SoC, in an optional embodiment, the proof node in the embodiment of this application can be located in the CPU part, and the verification node and challenge node can be located in the HSM part.

8. Key tasks, key procedures, key modules, and key data:

In the embodiment of this application, the key tasks are tasks of the first device that need to be securely protected, such as applications with high real-time requirements in smart car scenarios, password verification tasks, visual recognition tasks, etc.

Key programs and key modules are code segment data that implement key tasks. Among them, key programs can include code that runs complete logic, such as code for visual recognition programs. A key module is a piece of code for the key functions of the program, such as the machine learning operation logic code of the visual recognition program, the scheduling logic code in the operating system, etc.

Key data is data to achieve key tasks. This data can include data located in different data sections in the program memory space, such as code section key data, read-only data section key data, general data section key data, etc.

9. Program interruption mode:

A method of message notification in computers. Program interrupt means that when the computer is executing the current program, some abnormal situations and special requests that urgently need to be handled occur. The CPU temporarily terminates the current program and switches to the execution of the interrupt service routine to handle more urgent events that occur randomly. After the interrupt is processed, the CPU will automatically return to the original program to continue execution. Program interrupts are not only suitable for input and output operations of external devices, but also for processing random events that occur in the outside world.

In the embodiment of the present application, the first device to which the proving node belongs, the second device to which the verification node belongs, and the third device to which the challenge node belongs can all be configured to use program interruption to trigger the execution of corresponding sub-processes included in the verification process. When the challenge node needs to initiate a challenge, it can use the interrupt service program of the third device to send the target parameter that triggers the challenge to the first device to which the certification node belongs. After the first device to which the proof node belongs receives the target parameter, the interrupt service program is activated and executed, triggering the running of the preset proof program to perform the proof calculation process on the target data to be verified by the first device, and obtain the first proof. As a result, the first certification result can be provided to the second device to which the verification node belongs. When initiating a challenge, the interrupt service routine of the third device may also send the target parameters of the challenge to the second device to which the verification node belongs. After the second device belonging to the verification node receives the target parameter, the interrupt service program is activated and executed, triggering the running of the preset verification program to obtain the first certification result from the certification node, and combined with the first certification result, verify Credibility of the target data of the first device.

Wherein, the first device may include at least two resource units. In order to ensure that the execution of the proof calculation process does not affect the running process of other programs on the first device side and the implementation of related services, at least one of the at least two resource units The first resource unit and the at least one second resource unit may be respectively bound and used to run different programs of the first device. For example, the at least one first resource unit is used to run programs other than critical programs of the first device (such as certification program), at least one second resource unit is used to run a key program of the first device, the key program at least includes a program for executing safety tasks and/or a program for executing scheduling tasks. For example, the first device may be a dual-core or multi-core device, and the resource unit of the first device may be, for example, a CPU core of the first device. The first device may include at least two CPU cores that are bound to run critical tasks. The CPU core of a program may be called the second core, and the CPU core bound to run programs other than critical programs may be called the first core.

It should be noted that the program interruption method is only an example of the communication method between the respective devices of the challenge node, the proving node and the verification node in the embodiment of the present application, and does not limit it in any way. In other embodiments, the devices to which each node belongs Any suitable communication method (such as network communication, software and hardware communication, etc.) can also be used between devices to implement information interaction to initiate the verification process, which is not limited in the embodiments of the present application.

It should be noted that in the embodiments of this application, "at least one" refers to one or more, and "multiple" refers to two or more. "And/or" describes the association of associated objects, indicating that there can be three relationships, for example, A and/or B, which can mean: A exists alone, A and B exist simultaneously, and B exists alone, where A, B can be singular or plural. The character "/" generally indicates that the related objects are in an "or" relationship. "At least one of the following" or similar expressions thereof refers to any combination of these items, including any combination of a single item (items) or a plurality of items (items). For example, at least one of a, b, or c can represent: a, b, c, a and b, a and c, b and c, or a and b and c, where a, b, c can be single or multiple.

And, unless otherwise specified, the ordinal numbers such as “first”, “second” and “third” mentioned in the embodiments of this application are used to distinguish multiple objects and are not used to limit the priority or priority of multiple objects. Importance. For example, the first device, the second device, and the third device are only used to distinguish different devices, but do not indicate differences in priority or importance of the three devices.

The embodiments of the present application provide a verification method, device and system, which help to improve security in a system architecture based on software verification technology. Among them, the method and the device are based on the same technical concept. Since the principles of the method and the device to solve the problem are similar, the implementation of the device and the method can be referred to each other, and the repeated points will not be repeated.

For ease of understanding, the following takes the smart car scenario as an example to introduce the verification scheme of the embodiment of the present application. It should be understood that the verification solution of the embodiment of the present application can also be applied to other scenarios that have higher performance requirements and need to ensure data security based on software verification technology. The embodiment of the present application does not limit this.

Figure 5 shows a schematic diagram of the system architecture of an example of the embodiment of the present application.

As shown in Figure 5, the system architecture may include multiple modules located on the same SoC, such as at least one electronic control unit (ECU) deployed on the same system on a chip or system on a chip (SoC) connected to the vehicle. electrical control unit, ECU) CPU (for example, represented as ECU CPU), and the hardware security module HSM.

Among them, the SoC can adopt a hardware isolation mechanism and be divided into REE and TEE. The ECU CPU can belong to REE, and the HSM can belong to TEE.

ECU CPU includes at least two CPU cores (Core), a real-time operating system (RTOS) running on the at least two CPU cores (for ease of differentiation, for example, expressed as RTOS1) and all application programs ( For example APP1 and APP2).

The HSM may include an HSM core, an RTOS (e.g., represented as RTOS2) running on the HSM core, and an application for implementing a secure service. The security service may include, but is not limited to, cryptographic accelerators such as advanced encryption. Standard (advanced encryption standard, AES), RSA (rivest-shamir-adleman) encryption algorithms; secure file storage; over-the-air technology (OTA) upgrade; password storage; anomaly detection, etc.

The SOC contains two pieces of memory. Among these two pieces of memory, a main memory with a larger storage capacity can be used by the CPU core, and a memory with a smaller capacity is used as a private memory (private memory) for the exclusive use of the HSM core. The communication between the CPU core and the HSM core can exchange information through a shared memory. When the CPU core transmits data to the HSM core, the following steps are included:

S1: The CPU core writes data to the shared memory that needs to be transmitted to the HSM core.

S2: The CPU core sends an interrupt request to the HSM core.

S3: After the corresponding interrupt service routine on the HSM core is activated, the data stored in the shared memory is read. As a result, the CPU core completes the data transmission to the HSM core.

Similarly, when the HSM core transmits data to the CPU core, the HSM core can write the data that needs to be transmitted to the CPU core into the shared memory through steps similar to S1-S3 above, in order to serve the activated interrupt on the CPU core. program reads. In the following, unless otherwise specified, information interaction between the CPU core and the HSM core on the same SoC can be achieved through steps similar to S1-S3 above, and will not be described again below.

Based on the system architecture shown in Figure 5, a conventional verification framework is shown in Figure 6. The challenge node, proof node and verification node run together in the HSM. The target data to be verified itself is stored and run in the main memory, and the CPU core passes The shared memory transmits the target data to be verified to the HSM for the proof node and the verification node to perform subsequent proof calculation processes and verification calculation processes to verify the credibility of the target data.

Among them, similar to the verification process implemented by the verification framework based on hardware isolation in Figure 4, in the verification process implemented based on the verification framework in Figure 6, the proving node can continuously read the target data to be verified from the shared memory. data block, and after calculating the corresponding proof result based on the data block contained in the target data, the proof result is sent to the verification node. However, the difference from the hardware-based verification framework in Figure 4 is that based on the verification framework in Figure 6, the target data to be verified itself runs in the main memory. There is a possibility that the attacking node may take advantage of this difference. Before the proof node reads the target data from the shared memory, the tampered data in the target data is restored to the original data. In this way, the proof node still performs calculations based on the original data, and the obtained proof results may still indicate that the data is credible, and cannot detect whether the data has been tampered with and restored, thus failing to ensure security.

At the same time, the verification framework shown in Figure 6 requires a large amount of communication bandwidth between the CPU core and the HSM core. Specifically: limited by the size of the input and output cache inside the HSM core, the amount of data that the HSM core can read from the shared memory at one time is limited. When the amount of target data to be verified is very large, the proving node needs to interact with the shared memory multiple times through the HSM core and continuously read the data blocks contained in the target data. This method will occupy the time of the HSM core to respond to other security requests.

For example, when a network communication application running on the CPU core needs to encrypt a data packet, it will write the data packet into the shared memory and request the HSM core to encrypt the data packet through an interrupt request. If it turns out that the node is continuing to read data from the shared memory, the HSM core will be delayed in responding to the request for packet encryption.

Therefore, the verification framework shown in Figure 6 cannot balance security and performance overhead.

In response to this, the embodiment of this application proposes a verification framework, as shown in Figure 7. Based on the system architecture shown in Figure 5, the verification node can be run on the target CPU core on the ECU CPU side (the two in Figure 7 on any one of the CPU cores), while the challenge node and verification node run on the HSM core. The target data to be verified is stored in the main memory accessible by the target CPU core, and the mirror data of the target data is stored in the main memory accessible by the HSM core. Private memory. It should be understood that the challenge node may also be located in a different device from the verification node. For example, the challenge node may be located in a device other than the ECU, CPU and HSM not shown in Figure 7 .

Taking the challenge node and the verification node located in the same device as an example, in Figure 7, when the challenge node needs to securely verify the target data to be verified on the ECU CPU side, for example, it can pass the HSM core to the target used to initiate the challenge. Parameters are written to shared memory and an interrupt request is sent to the CPU core. The corresponding interrupt service routine on the CPU side can be activated in response to the interrupt request and read the target parameter from the shared memory. At the same time, the interrupt service program can instruct the certification node to run the preset certification program based on the obtained target parameters to calculate the target data to be verified, obtain the first certification result, and send the first certification to the verification node through the shared memory. result. The verification node can run a preset verification program in response to the target parameters from the challenge node, based on the target parameters and the first certification result from the certification node, while adding information from other checking dimensions in the embodiment of the present application (such as the certification node's Prove the execution time information of the calculation process) to verify the credibility of the target data.

Among them, the verification framework shown in Figure 7, on the one hand, can use the existing hardware security modules in the smart car scenario to construct the verification framework. It does not require additional hardware modifications, has small changes to the system architecture, and has high compatibility. On the other hand, running the proof node and the target data to be verified in the regular execution environment of the ECU CPU and performing the complete proof calculation process without switching the running context can greatly reduce the communication volume between the ECU CPU and the HSM. Reduce performance overhead and ensure that the implementation of the current business of the ECU CPU or HSM is not affected by the verification process. On the other hand, the verification node can combine information from at least two inspection dimensions to jointly verify the credibility of the verified target data of the ECU CPU, which can effectively prevent attacks and ensure security.

It should be noted that the system architecture shown in Figures 5 to 7 above is only an SoC as an example, and is not intended to be any limitation to the applicable scenarios of the verification solution in the embodiment of the present application. In other embodiments, the verification scheme can also separate the ECU CPU and HSM in Figure 7, and use the HSM in other devices to implement the verification scheme of the embodiment of the present application. For example, the HSM in Figure 7 is applied to the vehicle integrated unit (VIU) to protect the security of programs and data running in the CPU on the VIU. Alternatively, the board device (or device) including the HSM in Figure 7 can also be applied to the security verification scenario of an external device that is locally connected to the board device. The external device may generally include a device that does not have trusted hardware or HSM due to cost reasons. For example, the board device may include but is not limited to a mobile data center (MDC), a vehicle dynamics control system (VDC), etc. When the above ECU CPU and HSM are located in different devices, at least it is necessary to ensure that the HSM where the verification node is located is a trusted device, and the verification node can run in an untrusted device. The trusted device and the untrusted device can communicate and interact through messages or other methods to implement the verification method in the embodiment of the present application. This communication method is not limited in the embodiment of the present application.

In order to facilitate understanding, the verification scheme of the embodiment of the present application is applied in the SoC scenario below, with the ECU CPU to which the certification node belongs as the first device, and the HSM to which the challenge node and verification node belong as the second device (i.e., the second device and the third device). (the device is the same device)) as an example, combined with the verification framework shown in Figure 7, the implementation principle of the verification solution in the embodiment of the present application is introduced, as shown in Figure 8. Among them, the information interaction process between the ECU, CPU and HSM and the memory is not shown in Figure 8. For detailed implementation details, please refer to the relevant descriptions in Figures 5 to 7, which will not be described again here.

As shown in Figure 8, taking a dual-core system (including two CPU cores) as an example, the verification solution can include the following steps:

S810: At time point 1, the challenge node sends a challenge to the ECU CPU to which the proving node belongs.

For example, taking the program interrupt method as an example, the HSM to which the challenge node belongs can be considered as an example of a peripheral of the ECU CPU. When the challenge node needs to initiate a verification process for the target data of the ECU CPU, it can activate the interrupt of the HSM. Service program, which runs in RTOS2, can send an interrupt request to the ECU CPU to which the proving node belongs to initiate a challenge.

Referring to the previous description combined with Figure 5 and Figure 7, in the SoC scenario, the HSM core can write the target parameters of the challenge to the shared memory for reading by the corresponding interrupt service program activated on the ECU CPU side. For example, the target parameter may include a random number, represented as N, for example.

S820: In response to the interrupt request from the HSM, the corresponding interrupt service program on the ECU CPU side can be activated. The interrupt service program can run in RTOS1 and instruct the proof node to run the preset proof program to execute the proof calculation process. Among them, the proof calculation process includes the following steps:

S821: The proving node runs the preset proving program on the target CPU core allocated by the task scheduler.

In the embodiment of this application, the task scheduler running on RTOS1 is an example of a key module of the ECU CPU and is used to execute scheduling tasks. For example, a CPU core is an example of a resource unit of a first device in which the task scheduler can assign one of the two CPU cores of the ECU CPU to A core (for example, CPU core 1) is bound to a key program that performs a critical task, and the other CPU core (for example, CPU core 2) is bound as a target core to a program other than the key program, such as a certification program. The proof node can run the preset proof program on the target core according to the scheduling information of the task scheduler, thereby executing the proof calculation process and obtaining the first proof result.

It should be noted that in the embodiment of the present application, the task scheduler may schedule in advance. When the proving node triggers running the proving program, the proving program can be run directly on the target core assigned by the task scheduler. Alternatively, the task scheduler can use the running information of all current CPU cores of the ECU CPU in real time (such as running programs, load information, etc.) to prove that the node schedules the CPU core that is not running the key program as the target core. The embodiment of this application is for task scheduling. The scheduling timing of the server is not limited. Through task scheduling, the proof node will not seize the running resources of key programs during the entire process of proof calculation, which helps ensure the realization of high real-time services on the ECU CPU side.

S822: During the running of the certification program, the certification node can obtain the target address sequence generated by the target function, and calculate the first certification result based on the target address sequence.

In the embodiment of this application, the target address sequence can be generated based on the target parameters of the challenge and the target function preset in the ECU CPU. The target address sequence can point to the target data to be verified. During the proof calculation process, the proof node The target data can be read and calculated according to the target address sequence to obtain the first proof result.

In specific implementation, in the first possible implementation manner, RTOS1 can be pre-configured to run the program corresponding to the target function after the interrupt service routine is activated. After the ECU CPU receives the challenge target parameters from the challenge node, the interrupt service program activated on the ECU CPU side can trigger (or notify) RTOS1 to run the program corresponding to the target function to generate the target address sequence and convert the The target address sequence is provided to the certification node, and the certification node performs the subsequent certification calculation process based on the target address sequence. Among them, the interrupt service program can call the program corresponding to the target function running on RTOS1 according to the target parameter to trigger the running of the program corresponding to the target function and the process of generating the target address sequence. In a second possible implementation, the proof node can be pre-configured to run the program corresponding to the target function after the interrupt service routine is activated. After the ECU CPU receives the target parameters of the challenge from the challenge node, the interrupt service program activated on the ECU CPU side can trigger the process of the proof node calling the program corresponding to the target function by sending the target parameters that trigger the challenge to the proof node. The proof node can call the program corresponding to the target function to generate the target address sequence, and perform the subsequent proof calculation process based on the target address sequence.

By way of example, the objective function may include a pseudo-random number generator function. In the first possible implementation method and the second possible implementation method mentioned above, when the program corresponding to the target function is running, the target parameter that triggers the challenge can be used as a seed, and a pseudo-random number generator can be used to generate the target address sequence. The target address sequence may include at least two addresses, and the at least two addresses may point to at least two data blocks contained in the target data. The length of the target address sequence may be L, which represents the number of the at least two addresses, and L is an integer greater than or equal to 2. In an optional implementation, the target address sequence can be associated with time point 2, which can be used as one of the time information used to verify the credibility of the target data and provided in association with the calculated first proof result. The verification node will be described in detail in the embodiment below and will not be described again here.

It should be noted that S822 in Figure 8 is only used to schematically illustrate that a target address sequence can be generated by running a program corresponding to the target function, and does not limit the method of generating the target address sequence. Moreover, the program corresponding to the task scheduler and the program not shown in the figure for executing key tasks may be an example of the key program in the embodiment of the present application, and the program corresponding to the objective function may be a subroutine included in the proving program. , the proof program may also include other subroutines not shown. For details, please refer to the relevant introduction above and will not be repeated here.

It proves that after the node obtains the target address sequence, it can read the data block contained in the target data according to the address contained in the target address sequence, and use the target algorithm to calculate the data blocks contained in the target data in the first order to obtain the first Prove the results.

Among them, the target data to be verified on the ECU CPU side can include any data on the first device side that needs to be verified for credibility. For example, the target data can be data in the memory space allocated by any of the following programs: key programs or proofs Programs, key programs may at least include programs that perform safety tasks and/or programs that perform scheduling tasks. Among them, the safety task and scheduling task are an example of critical tasks. Safety tasks include tasks that need to be safely protected on the ECU CPU side, such as tasks running artificial intelligence (artificial intelligence, AI) recognition algorithms. Scheduling tasks may include tasks performed by the task scheduler, such as scheduling target cores for attestation nodes. The proof program includes all programs preset in the ECU CPU for the proof node to implement the proof calculation process. It should be understood that this is only an example of the target data to be verified and is not a limitation. In practical applications, the target data to be verified may not be limited to the above examples, and will not be described again here.

In an optional implementation, the target algorithm may adopt a serial computing structure. For example, the serial calculation structure may include M function blocks (for example, represented as F) for serial calculations. Each function block is configured to perform calculations using a target algorithm and may be used to perform calculations on input addresses or data contents. Calculate until the proven result is obtained, M≥L, M is an integer. According to this serial calculation structure, parallel calculations cannot be performed. When performing proof calculations based on this structure, you must wait until the calculation of the previous function block is completed to obtain the corresponding calculation results before proceeding to the next address or next step based on the next function block. Calculation of part of the data content. In this way, the attacker will not be able to utilize the characteristics of the multi-resource unit of the first device to construct an algorithm to execute the verification algorithm in parallel, thereby compressing the execution time. For example, the serial computing structure may be a Merkle–Damgard structure. The above-mentioned target algorithm may include a hash algorithm, including but not limited to MD5, SHA1 and other hash algorithms, and the first proof result obtained may be a hash value, for example.

For example, as shown in Figure 9, taking the target address sequence including five addresses (L=5) as an example, the five addresses can be represented as A1, A2, A3, A4, and A5. The target data read based on A1-A5 can contain five data blocks, represented as V1, V2, V3, V4, V5. The data types and sizes of V1-V5 can be different. For example, some data blocks can be code segment data, some data blocks can be read-only data segment data, some data blocks can be 4 bytes, and some data blocks can be It is 8 bytes or longer (for example, 32 bytes), so I won’t go into details here. It is proved that when the node uses the target algorithm and the first order to construct the serial computing structure, it can start from the initialization vector (initial nector, IV) and construct five function blocks, represented as F1, F2, F3, F4, and F5. The data blocks V1-V5 can be used as the input content of the function blocks F1-F5 respectively, and are input to the function blocks F1-F5 for calculation in sequence. After the final calculation is completed (finalize), the first proof result is obtained.

It should be noted that Figure 9 is only an illustration of the correspondence between the addresses in the target address sequence, the data blocks contained in the target data, and the function blocks of the serial calculation structure, and is not limited to each function block of the serial calculation structure. input content. In other embodiments, depending on the specific implementation of the target algorithm used, for example, the values of at least two addresses in the target address sequence can also be used as the input content of each function block of the serial calculation structure, so that each function block can The corresponding data block is read according to the address and calculated until the first proof result is obtained. The embodiment of the present application does not limit the specific implementation of this calculation.

S830: The certification node provides the first certification result to the verification node.

For example, at time point 3, the certification node may send the first certification result to the second device to which the verification node belongs. Accordingly, the verification node may receive the first certification result from the certification node at time point 3. Furthermore, when the verification node runs a preset verification program, it can verify the credibility of the target data based on information from at least two inspection dimensions including the first verification result.

For example, the information of the at least two checking dimensions may include the first proof result itself, and the execution time information of the proof calculation process of the proof node. The execution time information may be determined by the time point 1 (for example, called the second moment) that triggers the challenge. ) and the time point 3 (for example, called the first moment) at which the proof calculation process ends are determined, for example, the time difference between time point 1 and time point 3. The verification node can simultaneously determine whether the target data of the first device to which the certification node belongs satisfies a preset credibility condition based on the first certification result and the time difference to determine the credibility of the target data.

For example, the trustworthy condition may include: the first certification result provided by the certification node is the same as the second certification result obtained by the verification node according to the target parameter, and the first time interval associated with the first moment is within the time allowed by the verification node. within the range.

Among them, when conducting credibility verification based on the above execution time information, the verification node can determine whether the total time taken by the certification node to execute the above certification calculation process meets the credibility condition based on the time difference between time point 3 and time point 1, that is, Whether the time difference between time point 3 and time point 1 is used as the first time interval is within a credible time range (the time error caused by communication interaction has been estimated in advance and is covered within the allowed time range). If the time difference is too long or too short and does not fall within the credible time range, the certification node may be attacked, indicating that the first certification result from the certification node is untrustworthy. If the time difference is within the credible time interval, it at least means that the certification node is credible in the execution time dimension.

When conducting credibility verification based on the above-mentioned first certification result, the verification node can obtain a credible second certification result based on the target parameters, and use whether the second certification result is the same as the first certification result to verify the credibility of the target data. Credibility. If they are the same, it means that the first certification result on the node side is credible, and it proves that the target data of the first device to which the node belongs has not been tampered with. If they are not the same, it means that the first certification result on the certification node side is not credible, and the target data of the first device to which the certification node belongs may have been illegally tampered with.

Only when the execution time information is within the allowed time range and the first verification result and the second verification result are the same, the verification node can determine the credibility of the target data on the certification node side. If any of the above conditions are not met, the target data on the proof node side is considered to be untrustworthy, and the first device to which the proof node belongs may have been illegally attacked.

It should be noted that in the embodiment of the present application, on the verification node side, the second certification result may be obtained by the verification node performing the same calculation process as that on the certification node side. For example, after receiving the target parameters sent by the challenge node through the interrupt service routine, the verification node can run the preset verification program in the HSM core, perform the same calculation process as the above S822, and store the target data to be verified in the private memory. Perform calculations on the mirror data in the node to obtain the second proof result. For detailed implementation details, please refer to the calculation process described above in conjunction with the proof node (for example, replacing the target data with mirror data), which will not be described again here.

However, since the same calculation process as S822 is performed on the verification node side, the mirror data needs to be stored in the private memory of the HSM. Although the additional stored mirror data will not affect the final calculation results, it will occupy a large amount of storage space in the HSM. When the private memory is insufficient to store the mirror data of all target data, it will affect the implementation of the verification scheme of the embodiment of this application.

Therefore, an optional implementation method is to not store the mirror data of the target data to be verified in the private memory space of the HSM, but to maintain a list in advance, such as a certification result information table or a first list. A list can be used to store multiple parameters and the credible proof results associated with each parameter. The multiple parameters can include target parameters. After receiving the target parameter from the challenge node and the first proof result from the proof node, the verification node can use the target parameter as an index to obtain the expected proof result from the saved first list by looking up the table, expressed as The second proves the result. Therefore, the certification node can simultaneously verify the credibility of the target data based on the received first certification result, the second certification result obtained by looking up the table, and the time point 3 at which the first certification result was received.

The multiple parameters in the first list are random numbers, and the challenging node can select target parameters from the multiple parameters included in the first list to initiate a challenge. The verification node can use the same pseudo-random number generator function as the proving node to generate the target address sequence, and the result of the target address sequence is often determined by the input random number N. Therefore, for the verification node, for any random number N, the target address sequence generated on the proving node side is certain and predictable. Based on this, the verification node can generate the proof result corresponding to each random number in advance according to the target algorithm and store it in the private memory of the HSM. Due to the credibility of the private memory, the second certification result obtained by the verification node through table lookup is credible and can be used to verify the credibility of the first certification result.

Assume that the parameters recorded in the first list are random numbers, the target algorithm used by the verification node is the hash algorithm, and the proof result calculated based on each parameter is the hash value. The first list maintained by the verification node is A list of verified hash values, as shown in Figure 10. The first list may at least include a plurality of random numbers (for example, represented as N1, N2, N3, N4, N5, etc.) and a hash paired with each random number. value (e.g. expressed as hash value 1, hash value 2, hash value 3, hash value 4, hash value 5).

When the challenge node randomly selects a random number (such as N1) from the parameters stored in the first list as the target parameter and sends it to the proof node and verification node to trigger the challenge. The proof node can execute the above S820-S830 to obtain the first proof result and provide it to the verification node. The verification node does not need to perform the same calculation steps, but only needs to access the private memory through table lookup, according to the trigger obtained from the challenge node. The target parameter N1 of the challenge and the saved first list are used to query the corresponding hash value 1 through N1 as the second proof result. When performing trustworthiness verification, the verification node needs to determine whether the hash value 1 is the same as the first proof result from the proof node. For example, if the first proof result is also hash value 1, then the proof results obtained by both parties are the same, which means that the first proof result from the proof node is credible and the target data has not been tampered with. If the first proof result is any one of hash value 2, hash value 3, hash value 4, hash value 5, or other hash values, and the proof results obtained by both parties are different, it means that the third proof from the proof node Once the proof result is unreliable, the target data may have been illegally tampered with.

It should be understood that Figure 10 is only an illustration of the first list in the embodiment of the present application and is not limiting. In practical applications, the length of the first list is not limited to 5 pairs of data, and the length of the first list can be appropriately increased as needed. , for example, 1000 pairs of data, making it difficult for an attacker to obtain all the information of the first list, or to obtain all the information of the first list within a limited time (for example, within 10 minutes), thereby improving security. In an optional implementation, the content contained in the first list may not be limited to multiple parameters and multiple proof results. For example, it may also include the value of an address contained in a target address sequence that can be predicted based on multiple parameters and the target function, as follows. It will be introduced with reference to the embodiment and will not be described in detail here.

It should be noted that the processing method shown in Figure 9 can be applied to perform proof calculations on the target data located in the code section shown in Figure 2. In the (1) code injection attack scenario mentioned above, by combining the calculation method shown in Figure 9 to obtain the corresponding first proof result and completing the verification at the verification node, and the verification result indicates that the first proof result is credible, you can Effectively prevent attackers from tampering with code segment data.

In addition, in the (2) key data tampering attack scenario mentioned above, the attacker can attack by modifying key data in each data section of the program. The key data can include, for example, file access permission data, machine Configuration data, etc. Therefore, the target data to be verified is not limited to the code segment data, but may also include data located in the read-only data segment shown in Figure 2 or data in the general data segment, collectively referred to as target data of the data segment. Different data blocks read based on different addresses in the target address sequence may correspond to different types and different data lengths. For example, the length of some data read from the code segment is no more than 64 bytes. For another example, the data length of the AI model to be verified ranges from tens of megabytes (MB, 1MB = 1024KB) to hundreds of megabytes. For another example, the length of some configuration files to be verified is about 10 kilobytes (kbytes, KB, 1KB=1024bite). For another example, the length of some passwords to be verified is approximately 128 bits. In some algorithms, the maximum data length of the input algorithm function is limited. For example, some hash algorithms limit the length of data input in a hash constructor (F) to a maximum of 64 bytes.

In this (2) key data tampering attack scenario, in order to ensure the execution of the proof calculation process, an optional implementation method is to preset a data length threshold for each address in the target address sequence according to the target algorithm. The data length threshold is used to indicate the maximum data length entered in the function block corresponding to the address. If the data block contained in the target data is read based on the value of the address in the target address sequence, it can be based on a certain address or certain addresses (for example, represented as a first address, and the number of the first addresses is not limited to one). When the length of the data block exceeds the data length threshold, the data block is segmented, and then a serial calculation structure is constructed based on the data blocks that do not need to be segmented and the data blocks obtained after segmentation processing, and calculation is performed.

As shown in Figure 11, taking the target address sequence including three addresses (L=3) as an example, the three addresses can be represented as A1, A2, and A3. The data blocks read based on A1-A3 are represented as V1, V2, and V3. Assume that the target algorithm is a hash algorithm, and the data length threshold specified by the hash algorithm is 64 bytes. The data length thresholds corresponding to A1, A2, and A3 are all 64 bytes. The data lengths of V1, V2, and V3 are 60 bytes respectively. Bytes, 70 bytes, and 90 bytes, then the data length of V1 is less than 64 bytes and does not need to be divided; the data length of V2 is greater than 64 bytes and less than 128 bytes, so V2 needs to be divided into two data blocks, for example Represented as V2-1 and V2-2. The data length of V3 is greater than 64 bytes and less than 128 bytes. V3 needs to be split into two data blocks, for example, represented as V3-1 and V3-2.

The target data obtained according to this segmentation method includes five data blocks, represented as V1, V2-1, V2-2, V3-1, and V3-2. The proof node will construct a serial computing structure using the target algorithm and first order based on a process similar to Figure 9. Specific example: starting from IV, construct five function blocks, represented as F1, F2, F3, F4, F5. The data blocks V1, V2-1, V2-2, V3-1, and V3-2 contained in the target data will be input to F1-F5 in the first order for calculation. After the final calculation is completed (finalize), the corresponding first One proves the result. Similarly, the verification node can perform the same calculation steps to obtain the corresponding second proof result according to the calculation processing method shown in Figure 11, or obtain the second proof result through table lookup.

Therefore, by combining the above calculation processing method shown in Figure 11, the data length of the address storage data corresponding to the target address sequence is increased during the verification process to ensure that all data in the data block pointed to by the address will be recorded in the hash value. In this case, even if the attacker has the opportunity to modify the data length information, as long as the attacker does not have time to modify the data content, the attacker cannot forge a credible proof result. Accordingly, when the first certification result from the certification node is obtained and the verification is completed at the verification node, and the verification result indicates that the first certification result is credible, attackers can be effectively prevented from tampering with key data statically stored in each data section.

It should be noted that in the above embodiment, the hash algorithm is used as an example to illustrate the data length threshold without limiting it. In other embodiments, for example, corresponding data length thresholds may be preset according to data types, and the preset data length thresholds for different addresses may be different. The data length threshold can be an empirical value or can be determined based on the algorithm parameters used. The embodiment of the present application does not limit the method of determining the data length threshold corresponding to each address in the target address sequence. Moreover, the number of splits for the data block pointed to by each address is not limited to once. For example, in Figure 11, if the data length of the data block V3 pointed to by A3 is 255 bytes, the data length threshold needs to be 64 bytes. This V3 is divided three times to obtain four data sub-blocks, represented as V3-1, V3-2, V3-3, and V3-4. Therefore, the same method as in Figure 11 can be used to construct the calculation structure and perform calculations. Combine V3-1, V3-2, V3-3, and V3-4 to perform calculations respectively until the corresponding calculation structure is obtained.

In addition, in the (3) code pointer/data pointer tampering attack scenario mentioned above, the attacker can attack by modifying the code pointer pointing to the code address or the data pointer pointing to the data address. Therefore, the target data to be verified is not limited to the above code segment data or statically stored key data, but may also include code pointers or data pointers. Among them, the storage areas of code pointers and data pointers in the data section include two types: static data area and dynamic data area. The pointer address stored in the static data area is fixed, and the pointer address stored in the dynamic data area is not fixed. Embodiments of the present application can protect pointers (including static code pointers and static data pointers) stored in the static data area.

Since the code address and data address of the program will be randomized during the running of the program, the values of the code pointer and data pointer will also be randomized accordingly. The randomization method is: when the CPU runs the program for the first time, when the operating system loads the program, it will randomize the base address (Base Address) of the program and randomly generate a base address. The base address remains unchanged after the program is run. . The code address/data address is the base address plus the original value of the code/data (physical space address). The original value is a fixed value, while the randomly generated base address remains unchanged during a run, and the base address changes after each restart of the CPU.

In the above S822, in the target address sequence generated by the target function, each address may store a code pointer or data pointer. The code pointer or data pointer is obtained based on the randomized base address and does not point to the original value of the code/data. Prove that the node can obtain the base address before reading the data block contained in the target data based on the value of the address contained in the target address sequence, and calculate the point to the target based on the base address and the value stored at at least two addresses in the target address sequence. The original value of the address of each data block of data, which is used to read each data block of the target data. Furthermore, the proof node (or verification node) can perform a calculation process similar to Figure 9 or Figure 11 based on the calculated original value, and read the target data and calculate based on the original value to obtain the corresponding proof result.

As shown in Figure 12, taking the target address sequence including three addresses (L=3) as an example, the three addresses can be represented as A1, A2, A3. The values stored in A1-A3 are the base addresses subject to randomization. The value of the affected static code pointer or the value of the static data pointer, for example, is expressed as CP1, DP3, DP1. The proving node can obtain the base address (e.g. represented as B) and determine the original value of the address pointing to the target data to be verified based on the value of the address contained in the target address sequence and this base address, e.g. using the respective addresses contained in the target address sequence. The value minus the base address is expressed as CP1-B, DP3-B, DP1-B. Furthermore, the proof node uses a method similar to Figure 9 or Figure 11 to construct a serial calculation structure, and performs serial calculations on the data blocks read based on these original values until the corresponding proof result is obtained. For the similarity calculation process, please refer to the relevant descriptions above in conjunction with Figures 9 and 11, and will not be described again here.

In addition, since the values of multiple pointers may be stored in one address: an address can only store one pointer at one point in time, but the pointers stored at different points in time can be different. In order to distinguish the address content during the current proof calculation, a possible implementation method is that the proof node can obtain the mark information based on the original value used in the above calculation, and the proof node can also provide the mark information to the verification node so that the verification node can verify Credibility of target data.

For example, the proving node may take the last M bits of the original value as a tag (Tag), where M is an integer greater than or equal to 1. In the embodiment of the present application, for example, the last significant bit (LSB) of the original value can be selected. Assuming M=8, the tag information corresponding to each original value can be expressed as LSB8. As shown in Figure 12, the original values CP1-B, DP3-B, and DP1-B correspond to mark 1, mark 2, and mark 3 respectively, which can be expressed as LSB8 (CP1-B), LSB8 (DP3-B), LSB8 ( DP1-B).

Finally, the proof node needs to send both the calculated first proof result and the detected mark information to the verification node, and the verification node combines the first proof result and the mark information to verify the credibility of the target data.

Among them, since the proving node and the verification node use the same multiple parameters and pseudo-random number generator functions, by performing program analysis in advance, the verification node can predict the multiple addresses randomly generated by the proving node and their associated The original pointer value is saved. For example, the verification node can maintain a reverse lookup table on the HSM side. After receiving the first proof result and marking information from the proving node, the verification node can deduct the proof node based on each marking information and the reverse lookup table. The original value used in the calculation, and based on the original value, the same calculation process as that on the proof node side is performed to obtain the expected second proof result. Therefore, the verification node can determine according to time point 3 whether the total time taken by the certification node to perform the above-mentioned certification calculation process meets the preset credibility conditions, and determine whether the first certification result and the second certification result are the same. If the total elapsed time is within the time range allowed by the verification node and the proof results obtained by both parties are the same, it means that the target data on the proof node side has not been tampered with by the attacker and is credible. If the total time elapsed is not within the time range allowed by the verification node and/or the certification results obtained by both parties are different, it indicates that the target data on the certification node side may have been illegally tampered with and is not trustworthy. It should be understood that the lookup table may belong to the first list mentioned above, or may be a second list independent of the first list, which is not limited in the embodiments of the present application.

Based on the calculation process implemented on the proving node side shown in Figure 12, as shown in Figure 13, on the verification node side, the pre-stored lookup table includes, for example, the three addresses (L=3) shown in Figure 12 And the pointer values associated with these three addresses. The three addresses can be represented as A1, A2, A3. Each address may store multiple code pointers or data pointers (raw pointers not randomized based on the base address), such as CP1*, CP2*, CP3*, CP4* stored in A1, expressed as CP1*@A1, CP2*@ A1, CP3*@A1, CP4*@A1; DP1*, DP2*, DP3* stored in A2, expressed as DP1*@A2, DP2*@A2, DP3*@A2; DP1*, DP2*, stored in A3 DP3*, expressed as DP1*@A3, DP2*@A3, DP3*@A3. After the verification node receives at least two mark information (such as mark 1, mark 2 and mark 3) from the proof node, it can reversely deduce the values of A1 and A2 used by the proof node when performing the proof calculation process through the inverse lookup table. , the original pointer value associated with A3, such as CP1*, DP3*, DP1*. Then, the verification node can perform the same calculation steps as the certification node side based on the original pointer value to perform hash calculation based on the data block of the mirror data read by the original pointer until the corresponding second certification result is obtained. Verification The node can compare the second certification result with the first certification result from the certification node to verify the credibility of the target data on the certification node side.

It should be noted that, theoretically, when the target data has not been tampered with by the attacker, CP1*=CP1-B, DP3*=DP3-B, DP1*=DP1-B. On the verification node side, based on CP1*, After DP3* and DP1* are calculated, the second proof result obtained is the same as the first proof result from the proof node, indicating that the target data is credible. In the case where the target data is tampered with by the attacker, the above equation may not hold. For example, at least one of the equations CP1*=CP1-B, DP3*=DP3-B, DP1*=DP1-B does not hold, so the verification node When calculating based on CP1*, DP3*, and DP1*, the second proof result finally obtained will be different from the first proof result from the proof node, indicating that the target data is not trustworthy.

So far, the dual-core system architecture applicable to the embodiments of the present application has been introduced based on the above in conjunction with Figures 8 to 13, as well as the detailed implementation process of the verification method implemented under this system architecture. Through the above verification architecture and verification method, the real-time characteristics of the dual-core system can be utilized to verify the credibility of the target data to be verified by the proof node by combining the calculation results from the proof node and other check dimension information (such as execution time information) , to verify the trusted status of the first device to which the proof node belongs, to ensure the security of the first device. At the same time, this solution can also randomly extract the code segments, configuration data (files), static code pointers, and static data pointers of the first device's key programs or proof program operations, and use different methods for verification, which can be used in many aspects. Protect target data and effectively prevent attacks. On the other hand, in this solution, the dual-core feature can be used for task scheduling, so that the running of the proof program will not seize the CPU cores used by key programs to ensure the operation requirements of high-real-time services and greatly reduce the number of CPU cores and HSM cores. The amount of communication between them reduces the impact of the verification process on the performance of the first device.

It can be understood that the verification scheme introduced above in conjunction with Figures 8 to 13 in the embodiment of the present application is also applicable to a multi-core system (for example, including three or more CPU cores). As shown in Figure 14, including CPU core 1 , CPU core 2, CPU core 3 and CPU core 4. The difference from the dual-core system is that in the multi-core system, the attacker may also use the multi-core concurrency characteristics to accelerate calculations. In the embodiment of the present application, in the multi-core system, the challenge node can be based on the first device that proves the node belongs. The total number of CPU cores (such as ECU CPU), the number of CPU cores allocated to key tasks, the number of target parameters that are adjusted to interact with the proof node or verification node, and the number of generated target address sequences, etc. On at least one CPU core occupied by critical tasks, try to fully run the proof program and verify the credibility of the target data to compensate for multi-core concurrency vulnerabilities.

For example, n represents the number of CPU cores of the first device, and n is an integer greater than or equal to 3. It is assumed that the task scheduler of the first device allocates k CPU cores to key programs that perform key tasks, and k is an integer greater than or equal to 1. Then, in S810, at time point 1, when the challenge node issues a challenge to the proving node and the verification node, it can send n-k random numbers as target parameters. In S821, RTOS1 can allocate n-k target CPU cores to n-k proof nodes through the task scheduler. In S822, the target function can generate n-k target address sequences based on n-k target parameters, and the certification node can calculate n-k certification results based on the n-k target address sequences. The n-k certification results are associated with n-k time points. In S830, the certification node sends n-k certification results to the second device to which the verification node belongs, and the verification node verifies the credibility of the target data of the first device to which the certification node belongs based on the n-k certification results and n-k time points. . The detailed implementation details are the same as the implementation of the above-mentioned dual-core system. Please refer to the relevant descriptions above in conjunction with Figures 8 to 13, and will not be described again here.

The embodiment of this application also provides a verification method, which can be implemented collaboratively by the above-mentioned certification node and verification node. As shown in Figure 15, the verification method can include the following steps:

S1510: The certification node obtains a target address sequence, where the target address sequence points to the target data to be verified.

S1520: The certification node obtains the first certification result based on the target data.

S1530: The certification node provides the first certification result to the verification node, wherein the first certification result is associated with a first time, and the first certification result and the first time are used for the credibility of the target data. verify.

S1540: The verification node verifies the credibility of the target data based on the target parameters, the first certification result and the first time.

Wherein, the certification node can run on at least one first resource unit, the at least one first resource unit is a resource unit included in the first device to which the certification node belongs, and the resource unit is at least used to run a program. The at least one first resource unit runs programs other than key programs of the first device, where the key programs at least include programs that perform security tasks and/or programs that perform scheduling tasks.

When implementing the above S1510, in an optional implementation manner, the proving node can obtain the target parameters and generate the target address sequence according to the target parameters and the target function. The proving node can be from the challenge node or the proving node to which the proving node belongs. The real-time operating system RTOS of the first device acquires the target parameter, and the challenge node is a node that triggers verification of the credibility of the target data. The target parameters include random numbers, and the target function includes a pseudo-random generation function. In another optional implementation, the proving node may obtain the target address sequence from the RTOS of the first device to which the proving node belongs, and the target address sequence is generated by the RTOS based on the target parameters and the target function. The target parameters include random numbers, and the target function includes a pseudo-random generation function. For the detailed implementation process, please refer to the relevant descriptions above in conjunction with Figures 8-13, and will not be described again here.

The target address sequence includes at least two addresses, and the at least two addresses point to at least two data blocks contained in different parts of the target data. When implementing S1520, the proving node can use the target algorithm to process the target in the first order. Calculation is performed on at least two data blocks containing different data to obtain the first proof result. When performing calculations, on the one hand, the proving node can also cut the data block pointed to by the first address among the at least two addresses when the length of the data block pointed to by the first address is greater than the data length threshold. Then, the certification node can obtain the first certification result using the data blocks that do not need to be segmented and the data blocks obtained after the segmentation process. On the other hand, the proving node can also obtain the base address, and calculate the original value of the address pointing to the target data based on the base address and the value of at least two addresses in the target address sequence, where the original value is to read the target data. For the detailed implementation process, please refer to the relevant descriptions above in conjunction with Figures 8-13, and will not be described again here. It should be noted that in the embodiment of the present application, when there is a first address in the target address sequence, the number of first addresses is not limited to one.

Before performing step 1540, the verification node may obtain the target parameter from a challenge node or an RTOS of the second device to which the verification node belongs, and the challenge node is a node that triggers verification of the credibility of the target data.

When implementing 1540, in one example, the verification node can adopt the same calculation method as the proving node side, obtain the second proof result according to the target parameters, and obtain the second proof result according to the second proof result, the first proof result from the proof node and the third proof result. The first moment to prove the correlation of results and verify the credibility of the target data. Wherein, the verification node obtaining the second certification result according to the target parameter may include: the verification node may obtain a target address sequence according to the target parameter, wherein the target address sequence points to the mirror data of the target data; the verification node The second proof result is obtained based on the mirror data. The verification node obtaining the target address sequence according to the target parameter may include: the verification node generates the target address sequence according to the target parameter and the target function; or, the verification node obtains the target address sequence from the second device to which the verification node belongs based on the target parameter. The RTOS obtains the target address sequence, wherein the target address sequence is generated by the RTOS according to the target parameters and the target function. The objective function includes a pseudo-random generation function. The target address sequence includes at least two addresses, and the at least two addresses point to at least two data blocks contained in the mirror data. The verification node obtaining the second certification result based on the mirror data may include: The verification node uses a target algorithm to calculate at least two data blocks contained in the mirror data in a first order to obtain the second certification result. In an optional implementation, the at least two addresses point to at least two data blocks contained in the mirror data, which may include: the length of the data block pointed to by the first address among the at least two addresses is greater than the data length. When the threshold is reached, the data block pointed to by the first address is segmented. For the detailed implementation process, please refer to the relevant descriptions above in conjunction with Figures 8-13, and will not be described again here.

When implementing 1540, in another example, the verification node obtains the second certification result according to the target parameter may include: the verification node uses the target parameter as an index to obtain the second certification result from the first list, wherein, The first list includes a plurality of parameters and a certification result associated with each parameter, and the plurality of parameters includes the target parameter. In an optional implementation, the verification node can obtain the tag information from the certification node; the verification node uses the target parameter as an index to obtain the second certification result from the first list, including: the verification node uses the Using the target parameters and the tag information as indexes, the second proof result is obtained from the first list. For the detailed implementation process, please refer to the relevant descriptions above in conjunction with Figures 8-13, and will not be described again here.

It should be noted that in this embodiment of the present application, the first device to which the certification node belongs and the second device to which the verification node belongs are located in the same system-on-chip SoC, where the first device is located in a non-accessible part of the SoC. Trust hardware, the second device is located in the trusted hardware of the SoC; or, the first device and the second device are different devices, wherein the first device is an untrusted device, and the third device The second device is a trusted device. In an optional example, the second device may further include a challenge node, which is a node that triggers verification of the credibility of the target data; or, the second device and the challenge node belong to the third node. The three devices are different devices, and the third device and the first device are different devices. In S1540, the verification node verifies the credibility of the target data according to the target parameter, the first certification result and the first moment, which may include: the verification node verifies the credibility of the target data according to the target parameter, the first certification result and the first moment. A certification result and the first moment, determining whether the target data satisfies preset credibility conditions to verify the credibility of the target data; wherein the credibility conditions include: the first certification result It is the same as the second proof result obtained by the verification node according to the target parameter, and the first time interval associated with the first moment is within the time range allowed by the verification node. For the detailed implementation process, please refer to the relevant descriptions above in conjunction with Figures 8-13, and will not be described again here.

The embodiment of the present application also provides a communication device for executing the method performed by the certification node or the verification node in the above method embodiment. Relevant features can be found in the above method embodiment and will not be described again here.

As shown in Figure 16, in one example, the device 1600 may correspond to a certification node, and the device 1600 may include: an acquisition unit 1601, used to acquire a target address sequence that points to the target data to be verified; a processing unit 1602, used to obtain the proof result according to the target data; the transceiver unit 1603, used to provide the proof result to the verification node, wherein the proof result is associated with the first time, and the proof result and the first time are used Verification of the credibility of the target data. For specific implementation methods, please refer to the detailed descriptions in the embodiments shown in Figures 1 to 15, which will not be described again here.

As shown in Figure 17, in another example, the device 1700 may correspond to a verification node, and the device 1700 may include: an acquisition unit 1701, configured to obtain a target parameter and obtain the first certification result from the certification node, the target parameter Including random numbers, the first proof result is obtained by the proof node based on the target data to be verified, and the first proof result is associated with the first moment; the determination unit 1702 is used to determine the first proof result based on the target parameters, the first proof As a result and the first moment, the credibility of the target data is verified. For specific implementation methods, please refer to the detailed descriptions in the embodiments shown in Figures 1 to 15, which will not be described again here.

It should be noted that the division of units in the embodiment of the present application is schematic and is only a logical function division. In actual implementation, there may be other division methods. Each functional unit in the embodiment of the present application can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above integrated units can be implemented in the form of hardware or software functional units.

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 technical solution of the present application is essentially or part of the contribution or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a number of instructions. It is used to cause a computer device (which may be a personal computer, a server, or a network device, etc.) or a processor to execute all or part of the steps of the methods described in various embodiments of this application. The aforementioned storage media include: U disk, mobile hard disk, read-only memory (ROM, read-only memory), random access memory (RAM, random access memory), magnetic disk or optical disk and other media that can store program code. .

In a possible implementation manner, embodiments of the present application provide a computer-readable storage medium. The computer-readable storage medium stores program code. When the program code is run on the computer, the computer Execute the above method embodiment.

In a possible implementation manner, the embodiment of the present application provides a computer program product, which when the computer program product is run on a computer, causes the computer to execute the above method embodiment.

In a simple embodiment, those skilled in the art can imagine that the communication devices in the above embodiments can adopt the form shown in FIG. 18 .

The device 1800 shown in Figure 18 includes at least one processor 1810 and a communication interface 1830. In an optional design, memory 1820 may also be included.

The specific connection medium between the processor 1810 and the memory 1820 is not limited in the embodiment of the present application.

In the device as shown in Figure 18, when communicating with other devices, the processor 1810 can transmit data through the communication interface 1830.

When the communication device adopts the form shown in Figure 18, the processor 1810 in Figure 18 can call the computer execution instructions stored in the memory 1820, so that the device 1800 can execute any of the above method embodiments.

Embodiments of the present application also relate to a chip system, which includes a processor for calling a computer program or computer instructions stored in a memory, so that the processor executes the method of any of the above embodiments.

In one possible implementation, the processor may be coupled to the memory through an interface.

In a possible implementation, the chip system may also directly include a memory, in which computer programs or computer instructions are stored.

By way of example, the memory may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Among them, non-volatile memory can be read-only memory (ROM), programmable ROM (PROM), erasable programmable read-only memory (erasable PROM, EPROM), electrically removable memory. Erase electrically programmable read-only memory (EPROM, EEPROM) or flash memory. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of illustration, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (synchronous DRAM, SDRAM), double data rate synchronous dynamic random access memory (double data rate SDRAM, DDR SDRAM), enhanced synchronous dynamic random access memory (enhanced SDRAM, ESDRAM), synchronous link dynamic random access memory (synchlink DRAM, SLDRAM) ) and direct memory bus random access memory (direct rambus RAM, DR RAM).

Embodiments of the present application also relate to a processor, which is configured to call a computer program or computer instructions stored in a memory, so that the processor executes the method described in any of the above embodiments.

For example, in the embodiment of the present application, the processor is an integrated circuit chip that has signal processing capabilities. For example, the processor can be a field programmable gate array (FPGA), a general-purpose processor, a digital signal processor (DSP), or an application specific integrated circuit (ASIC). Or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, system on chip (SoC), central processor unit (CPU), or network processing It can also be a network processor (NP), a microcontroller unit (MCU), a programmable logic device (PLD) or other integrated chips, which can implement or execute the embodiments of the present application. The disclosed methods, steps and logical block diagrams. A general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc. The steps of the method disclosed in conjunction with the embodiments of the present application can be directly implemented by a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software module can be located in random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, registers and other mature storage media in this field. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.

It should be understood that embodiments of the present application may be provided as methods, systems, or computer program products. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment that combines software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

These computer program instructions may also be stored in a computer-readable memory that causes a computer or other programmable data processing apparatus to operate in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction means, the instructions The device implements the functions specified in a process or processes of the flowchart and/or a block or blocks of the block diagram.

These computer program instructions may also be loaded onto a computer or other programmable data processing device, causing a series of operating steps to be performed on the computer or other programmable device to produce computer-implemented processing, thereby executing on the computer or other programmable device. Instructions provide steps for implementing the functions specified in a process or processes of a flowchart diagram and/or a block or blocks of a block diagram.

Obviously, those skilled in the art can make various changes and modifications to the embodiments of the present application without departing from the scope of the embodiments of the present application. In this way, if these modifications and variations of the embodiments of the present application fall within the scope of the claims of this application and equivalent technologies, then this application is also intended to include these modifications and variations.

Claims

A verification method, characterized by including:

The proving node obtains a target address sequence, wherein the target address sequence points to the target data to be verified;

The certification node obtains the certification result based on the target data;

The certification node provides the certification result to the verification node, wherein the certification result is associated with a first time, and the certification result and the first time are used for credibility verification of the target data.
The method according to claim 1, characterized in that the certification node obtains the target address sequence, including:

The proof node obtains the target parameters;

The certification node generates the target address sequence according to the target parameters and the target function;

Wherein, the target parameters include random numbers, and the target function includes a pseudo-random generation function.
The method according to claim 2, characterized in that the certification node obtains target parameters, including:

The certification node obtains the target parameter from a challenge node or a real-time operating system RTOS of the first device to which the certification node belongs, where the challenge node is a node that triggers verification of the credibility of the target data.
The method according to claim 1, characterized in that the certification node obtains the target address sequence, including:

The certification node obtains the target address sequence from the RTOS of the first device to which the certification node belongs, where the target address sequence is generated by the RTOS according to the target parameters and the target function.
The method according to any one of claims 1 to 4, characterized in that the certification node runs on at least one first resource unit, and the at least one first resource unit is the first device to which the certification node belongs. Includes resource units, which are at least used to run programs.
The method according to claim 5, characterized in that:

The at least one first resource unit runs programs other than key programs of the first device, where the key programs at least include programs that perform security tasks and/or programs that perform scheduling tasks.
The method according to any one of claims 1 to 6, characterized in that the target address sequence includes at least two addresses, and the at least two addresses point to at least two data blocks contained in the target data, so The proof node obtains proof results based on the target data, including:

The certification node uses a target algorithm to calculate at least two data blocks contained in the target data in a first order to obtain the certification result.
The method according to any one of claims 1 to 6, characterized in that the target address sequence includes at least two addresses, the at least two addresses point to at least two data blocks contained in the target data, and further include:

When the length of the data block pointed to by the first address among the at least two addresses is greater than the data length threshold, the data block pointed to by the first address is segmented.
The method according to any one of claims 1-8, characterized in that the method further includes:

The proving node obtains the base address;

The certification node calculates an original value of an address pointing to the target data based on the base address and the values of at least two addresses in the target address sequence, and the original value is used to read the target data.
The method according to any one of claims 1-9, characterized in that,

The first device to which the certification node belongs and the second device to which the verification node belongs are located in the same system-on-chip SoC, wherein the first device is located in the untrusted hardware of the SoC, and the second device is located in the SoC. Trusted hardware for the SoC; or,

The first device to which the certification node belongs and the second device to which the verification node belongs are located in different devices, wherein the first device is an untrusted device and the second device is a trusted device.
The method according to any one of claims 1 to 10, characterized in that when the target data satisfies preset trust conditions, the trustworthiness verification of the target data passes; wherein the trustworthiness The conditions include: the certification result provided by the certification node is the same as the certification result obtained by the verification node according to the target parameters, and the first time interval associated with the first moment is within the time range allowed by the verification node.
A verification method, characterized by including:

The verification node obtains target parameters, where the target parameters include random numbers;

The verification node obtains the first certification result from the certification node, wherein the first certification result is obtained by the certification node based on the target data to be verified, and the first certification result is associated with the first moment;

The verification node verifies the credibility of the target data based on the target parameter, the first certification result and the first moment.
The method according to claim 12, characterized in that the verification node obtains target parameters, including:

The verification node obtains the target parameters from a challenge node or an RTOS of the second device to which the verification node belongs, where the challenge node is a node that triggers verification of the credibility of the target data.
The method according to claim 12 or 13, characterized in that the verification node verifies the credibility of the target data based on the target parameter, the first certification result and the first moment, including:

The verification node obtains the second certification result according to the target parameter;

The verification node verifies the credibility of the target data based on the second certification result, the first certification result and the first time.
The method according to claim 14, characterized in that the verification node obtains the second certification result according to the target parameter, including:

The verification node obtains a target address sequence according to the target parameter, wherein the target address sequence points to the mirror data of the target data;

The verification node obtains the second certification result based on the mirror data.
The method according to claim 15, characterized in that the verification node obtains a target address sequence according to the target parameters, including:

The verification node generates the target address sequence according to the target parameters and target function; or,

The verification node obtains the target address sequence from the RTOS of the second device to which the verification node belongs based on the target parameters, and the target address sequence is generated by the RTOS based on the target parameters and the target function,

Wherein, the objective function includes a pseudo-random generation function.
The method according to claim 15 or 16, characterized in that the target address sequence includes at least two addresses, the at least two addresses point to at least two data blocks contained in the mirror data, and the verification node is based on The second proof result obtained from the mirror data includes:

The verification node uses a target algorithm to calculate at least two data blocks contained in the mirror data in a first order to obtain the second certification result.
The method according to claim 15 or 16, characterized in that the target address sequence includes at least two addresses, the at least two addresses point to at least two data blocks included in the mirror data, and further includes:

When the length of the data block pointed to by the first address among the at least two addresses is greater than the data length threshold, the data block pointed to by the first address is segmented.
The method according to claim 14, characterized in that the verification node obtains the second certification result according to the target parameter, including:

The verification node uses the target parameter as an index to obtain the second proof result from a first list, where the first list includes multiple parameters and a proof result associated with each parameter, and the multiple parameters include the target parameters.
The method of claim 19, further comprising:

The verification node obtains tag information from the certification node;

The verification node uses the target parameter as an index to obtain the second proof result from the first list, including:

The verification node uses the target parameter and the tag information as indexes to obtain the second certification result from the first list.
The method according to any one of claims 12-20, characterized in that,

The first device to which the certification node belongs and the second device to which the verification node belongs are located in the same system-on-chip SoC, wherein the first device is located in the untrusted hardware of the SoC, and the second device is located in the SoC. Trusted hardware for the SoC; or,

The first device and the second device are different devices, wherein the first device is an untrusted device and the second device is a trusted device.
The method according to claim 21, characterized in that:

The second device further includes a challenge node, which is a node that triggers verification of the credibility of the target data; or,

The second device and the third device to which the challenge node belongs are different devices, and the third device and the first device are different devices.
The method according to any one of claims 12-22, characterized in that the verification node verifies the credibility of the target data based on the target parameter, the first certification result and the first moment. sex, including:

The verification node determines whether the target data satisfies a preset trust condition according to the target parameter, the first certification result and the first moment to verify the credibility of the target data; wherein, The trustworthy conditions include: the first certification result is the same as the second certification result obtained by the verification node according to the target parameter, and the first time interval associated with the first moment is within the range allowed by the verification node. within the time frame.
A device for proving nodes, characterized by including:

An acquisition unit, configured to acquire a target address sequence, wherein the target address sequence points to the target data to be verified;

A processing unit, used to obtain proof results based on the target data;

A transceiver unit configured to provide the verification result to the verification node, wherein the verification result is associated with a first time, and the verification result and the first time are used for credibility verification of the target data.
A device for verifying nodes, characterized by including:

A transceiver unit, configured to obtain target parameters and obtain a first certification result from a certification node, where the target parameter includes a random number, the first certification result is obtained by the certification node based on the target data, and the first certification result is obtained by the certification node based on the target data. Prove that the results are related to the first moment;

A determining unit configured to verify the credibility of the target data based on the target parameter, the first certification result and the first moment.
A communication system, characterized by comprising a device for implementing the method according to any one of claims 1-11, and a device for implementing the method according to any one of claims 12-23.
A chip system, characterized in that it includes at least one processor and an interface circuit. The processor is used to execute instructions and/or data interaction through the interface circuit, so that the chip system executes any of claims 1-11. The method described in one of the claims 12-23, or the method described in any one of claims 12-23.
A vehicle, characterized by comprising the device according to claim 24 or the chip system according to claim 27, and/or the device according to claim 25 or the chip system according to claim 27, or , including the communication system as claimed in claim 26.
A computer-readable storage medium, characterized in that it includes a program or instructions. When the program or instructions are executed, the method as claimed in any one of claims 1-11 is executed, or as claimed in claim 12- The method described in any one of 23 is performed.
A computer program product, characterized in that, when a computer reads and executes the computer program product, it causes the computer to perform the method as described in any one of claims 1-11, or to perform the method as described in claims 12-23. any of the methods described.