Verification method, device and system

Abstract

A verification method, device and system relate to the technical field of security. The method comprises the steps that a proving node obtains a target address sequence, and the target address sequence points to target data to be verified; the certification node obtains a certification result according to the target data; the certification node provides the certification result to a verification node, 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. The method helps to improve security in a system architecture based on a software verification technology.

Description

Verification method, device and system Technical Field

[0001] The present application relates to the field of security technology, and in particular to a verification method, device and system. Background Art

[0002] Attestation technology is one of the key technologies in trusted computing, which is used to verify whether the data to be verified on the authenticated device side is in a trustworthy state.

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

[0004] However, in some real-world application scenarios (such as smart car scenarios), performance considerations often prevent the use of system architectures based on hardware verification technology. Furthermore, in hardware-isolated scenarios, the execution context needs to frequently switch between the REE and TEE, which incurs significant performance overhead. Placing applications with high real-time requirements (such as smart car control) in the TEE will result in significant performance losses. Therefore, to ensure performance, software-based verification technology is more suitable.

[0005] However, there is an urgent need to improve security in system architecture based on software verification technology.

[0006] Summary of the Invention

[0007] The embodiments of the present application provide a verification method, device, and system that help improve security in a system architecture based on software verification technology.

[0008] In the first aspect, an embodiment of the present application provides a verification method, which can be executed by a proof node of a first device. The proof node can run a proof program preset in the first device, and calculate the proof result to be verified based on the target data to be verified, so as to provide the verification result to the verification node of the second device, so that the verification node can verify the credibility of the target data.

[0009] The method may include: the proof node obtains a target address sequence, wherein the target address sequence points to the target data to be verified; the proof node obtains a proof result based on the target data; the proof node provides the proof result to the verification node, wherein the proof result is associated with a first moment, and the proof result and the first moment are used for credibility verification of the target data.

[0010] Through the above method, the proving node and the verification node can be configured to: when verifying the credibility of the target data, in addition to the proof result from the proving node, information of other inspection dimensions, such as the first moment associated with the proof result, can also be added at the same time. Furthermore, the proving node can provide the verification node with information of at least one inspection dimension, such as the proof result, so that the verification node can combine information of at least two inspection dimensions (for example, including but not limited to the proof result from the proving node, the first moment associated with the proof result, etc.) to 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 does not bring excessive performance overhead, nor does it have a significant impact on other services (such as security services) of the first device to which the proving node belongs. This solution can take into account both security and performance.

[0011] In combination with the first aspect, in a possible implementation, the proof node obtains the target address sequence, including: the proof node obtains a target parameter; the proof node generates the target address sequence based on 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.

[0012] In one optional implementation of the above method, a target function can be configured on a proof node. After the proof node starts running the proof program, the target function can be executed in response to target parameters to generate a target address sequence. The proof node can then read target data based on the target address sequence to perform calculations. The target parameters include random numbers, and the target address sequence is generated using a pseudo-random generator function. This can add randomness to the calculation process based on the target data, thereby improving security.

[0013] In combination with the first aspect, in a possible implementation method, the proof node obtains the target parameters, including: the proof node obtains the target parameters from the challenge node or the real-time operating system RTOS of the first device to which the proof node belongs, wherein the challenge node is the node that triggers the verification of the credibility of the target data.

[0014] Through the above method, the challenge node or the RTOS of the first device can trigger the proof node to run the proof program through the target parameters to perform the reading and calculation process of the target data, making the implementation of the verification method of the embodiment of the present application more flexible.

[0015] In combination with the first aspect, in a possible implementation, the proof node obtains the target address sequence, including: the proof node obtains the target address sequence from the RTOS of the first device to which the proof node belongs, wherein the target address sequence is generated by the RTOS according to target parameters and target functions.

[0016] In another optional implementation of the above method, the target 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 target function in the RTOS can be executed in response to the target parameters to generate a target address sequence. The proving node can obtain the target address sequence from the RTOS so as to read the target data according to 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. Generating the target address sequence using the pseudo-random generator function can add randomness to the entire calculation process and improve security.

[0017] In conjunction with the first aspect, in one possible implementation, the attestation node runs on at least one first resource unit, which is a resource unit included in a first device to which the attestation node belongs, and the resource unit is at least used to run programs. By way of example, the at least one first resource unit runs programs other than critical programs of the first device, wherein the critical programs include at least programs for executing security tasks and / or programs for executing scheduling tasks. By way of example, the resource unit may be a processor core of the first device.

[0018] Through the above method, the first device to which the proof node belongs can include multiple resource units, and the first device can schedule at least one first resource unit for the proof node so that the proof program of the proof node can run on at least one first resource unit, so that the running of the proof program does not occupy the resource units occupied by the key programs as much as possible, thereby reducing the impact of the verification process on other businesses on the first device side.

[0019] In conjunction with the first aspect, in one 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 proof node obtains a proof result based on the target data, including: the proof node uses a target algorithm to calculate the at least two data blocks included in the target data in a first order to obtain the proof result. The target algorithm may use a serial calculation structure and may include a hash algorithm.

[0020] Through the above method, the proving node can employ a serial computation structure, sequentially computing at least two data blocks contained in the target data until a proof result is obtained. If the first device includes multiple resource units, this serial computation approach can effectively prevent attackers from exploiting the multi-resource unit nature of the first device to construct an algorithm to execute the verification algorithm in parallel, thereby reducing execution time.

[0021] In combination with the first aspect, in a possible implementation, the target address sequence includes the at least two addresses, and the at least two addresses point to at least two data blocks contained in the target data, and also 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 split.

[0022] In the above method, the data length threshold can be a data length threshold preset for the target algorithm. When performing calculations on data blocks included in the target data, the proving node can, based on the data characteristics of the different data blocks included in the target data and in accordance with the data length threshold, segment the data blocks whose data length exceeds the data length threshold to obtain corresponding data sub-blocks. Furthermore, the proving node can perform calculations based on data blocks that do not require data segmentation and the data sub-blocks obtained after segmentation, thereby ensuring that all data in the different data blocks pointed to by the addresses in the target address sequence can be calculated.

[0023] In combination with the first aspect, in a possible implementation, the method further includes: the proof node obtaining a base address; the proof node calculating an original value of the 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.

[0024] The above method considers that when a program is first run on a first device, the operating system of the first device randomizes the base address of the program when loading the program, and this base address remains unchanged after the program is run. To reduce the impact of base address randomization on the generation of the target address sequence, the proving node can obtain the base address and subtract it from the value of each address in the target address sequence to obtain the original value of the address pointing to the target data. This original value can then be used to read the target data, minimizing the possibility of address tampering by an attacker.

[0025] In combination with the first aspect, in a possible implementation, the method further includes: the proving node determining tag information based on the original value; the proving node providing the tag information to the verification node, and the tag information is used to reversely deduce the original value.

[0026] 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. When the same calculation process is performed on the verification node side, the mirror data and calculation can be read based on the original value obtained by reverse deduction to obtain a credible proof result, which can be used to verify the credibility of the target data. It should be noted that in an embodiment of the present application, in a verification process, the target address sequence generated according to the target parameters may include at least two addresses. Accordingly, the proving node can provide the tag information corresponding to the original value of at least two addresses pointing to the target data to the verification node. This method does not require the transmission of complete pointer data, which can reduce the amount of communication between the proving node and the verification node.

[0027] In conjunction with the first aspect, in one possible implementation, the target data includes data in memory space allocated for at least one of the following programs: a critical program or an attestation program executed by the attestation node. The critical program includes at least a program that performs security tasks and / or a program that performs scheduling tasks.

[0028] Through the above method, the key programs that need to be securely protected and the data in the program memory space of the proof program of the first device to which the proof node belongs need to be verified, and the target function of the first device can be configured as follows: the addresses in the generated target address sequence at least point to the data in the program memory space of the key programs and the proof program, so as to reduce the possibility of these data being tampered with by attackers. In combination with the first aspect, in a possible implementation method, the first device to which the proof 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 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 second device is a trusted device.

[0029] 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 various 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 certification node runs in an untrusted environment, the certification result 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. The security of the target data can still be guaranteed without affecting the performance of the first device side and the execution of other services.

[0030] In combination with the first aspect, in one possible implementation method, when the target data meets a preset trust condition, the credibility verification of the target data is passed; wherein, the trust condition includes: the proof result provided by the proof node is the same as the proof result obtained by the verification node based on the target parameter, and the first time interval associated with the first moment is within the time range allowed by the verification node.

[0031] Through the above method, a trust condition can be set based on information from at least two inspection dimensions. During the verification process, the trustworthiness of the target data can be verified by determining whether the information obtained from at least two inspection dimensions satisfies the preset trust condition. It should be noted that this is merely an example of the trust condition in the embodiment of the present application and does not limit it in any way. In other embodiments, when the inspection dimension is changed or other inspection dimension information is added, the trust condition can be modified accordingly, and the embodiment of the present application does not limit this.

[0032] Among them, the first time interval associated with the first moment can be the execution time of the calculation process on the proof node side. When the challenge node initiates a challenge to the proof node at the second moment, it can synchronously instruct the verification node, and the verification node can know the revelation moment of the challenge. When the verification node receives the proof result from the proof node at the first moment, the verification node can know the end moment of the challenge, and the first time interval can be the time difference between the first moment and the second moment and the time interval obtained by the allowed time error. 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 trustworthy 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 be tampered with in the execution time dimension, and the target data is untrustworthy at least in the algorithm execution time dimension.

[0033] On the second aspect, an embodiment of the present application provides 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 verify the credibility of the target data on the first device side based on the verification result to be verified (for example, the first verification result from the verification node).

[0034] The method includes: the verification node obtains a target parameter, wherein the target parameter includes a random number; the verification node obtains a first proof result from the proof 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 a first moment; the verification node verifies the credibility of the target data based on the target parameter, the first proof result and the first moment.

[0035] Through the above method, the verification node and the proof node can be configured to: when verifying the credibility of the target data, in addition to the first proof result from the proof node, other information of the inspection dimension can also be added at the same time, such as the first moment associated with the first proof result. Furthermore, the verification node can jointly verify the credibility of the target data based on the information to be verified obtained from the proof node (such as the first proof result from the proof node) and other information (such as the first moment associated with the first proof result), thereby improving security in the system architecture based on software verification technology. At the same time, the communication volume between the verification node and the proof node is small, which does not bring excessive performance overhead, nor does it have a significant impact on other services of the first device to which the proof node belongs (such as security services). This solution can take into account both security and performance.

[0036] In combination with the second aspect, in a possible implementation method, 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 the node that triggers the verification of the credibility of the target data.

[0037] Through the above method, the RTOS of the challenge node or the second device can trigger the proof 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.

[0038] In combination with the second aspect, in a possible implementation method, the verification node verifies the credibility of the target data based on the target parameters, the first proof result and the first moment, including: the verification node obtains the second proof result based on the target parameters; the verification node verifies the credibility of the target data based on the second proof result, the first proof result and the first moment.

[0039] Through the above method, the verification node can obtain a second proof result based on the target parameters. The second proof result is credible and can be used to verify whether the first proof result from the proof node is credible, thereby verifying the credibility of the target data on the first device side.

[0040] It should be noted that, in the embodiment of the present application, the verification result can obtain a second proof result according to the target parameter in at least one manner.

[0041] 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 proof result according to the target parameter, which may include: the verification node obtains the 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 proof result according to the mirror data. Similarly, the verification node obtains the target address sequence according to the target parameter, which 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 RTOS of the second device to which the verification node belongs according to the target parameter, wherein the target address sequence is generated by the RTOS according to the target parameter and the target function. The target function may include a pseudo-random generation function. The implementation details of similar methods can be found in the relevant description of the first aspect above, which will not be repeated here.

[0042] In one possible implementation of Example 1, the target address sequence includes at least two addresses, the at least two addresses pointing to at least two data blocks included in the mirrored data, and the verification node obtains the second proof result based on the mirrored data, including: the verification node uses a target algorithm to calculate the at least two data blocks included in the mirrored data in a first order to obtain the second proof result. For example, the target algorithm may use a serial calculation structure and may include a hash algorithm.

[0043] In a possible implementation of this example 1, the target address sequence includes the at least two addresses, and the at least two addresses point to at least two data blocks contained 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 split.

[0044] In a possible implementation of this example 1, the method further includes: the verification node obtaining tag information from the proof node; the verification node determining the original value of the address pointing to the mirror data based on the tag information and the target address sequence, and the original value is used to read the mirror data.

[0045] In Example 2, the verification node does not need to perform the same computational steps as the proving node, but can instead obtain the second proof result by looking up a table. For example, obtaining the second proof result based on the target parameter by the verification node may include: using the target parameter as an index, the verification node obtains 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 parameter.

[0046] In a possible implementation of Example 2, the method may further include: the verification node obtains tag information from the proof node; the verification node obtains the second proof result from the first list using the target parameter as an index, including: the verification node obtains the second proof result from the first list using the target parameter and the tag information as an index. It should be understood that the tag information is an example of information interaction between the proof node and the verification node. The transmission and use of the tag information depends on the specific algorithm adopted by the proof node. When the proof node uses the original value of the address pointing to the target data to eliminate the influence of base address randomization, the proof node can determine the tag information based on the original value, and transmit the tag information to the verification node in association with the first proof result, so that the verification node can reversely deduce the original value, or search for the corresponding proof result in combination with the tag information. This embodiment of the present application does not limit this.

[0047] In combination with the second aspect, in one possible implementation, the first device to which the proof 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 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 second device is a trusted device.

[0048] In combination with the second aspect, in one possible implementation, the second device also 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.

[0049] In combination with the second aspect, in a possible implementation method, the verification node verifies the credibility of the target data based on the target parameters, the first proof result and the first moment, including: the verification node determines whether the target data meets the preset trust conditions based on the target parameters, the first proof result and the first moment to verify the credibility of the target data; wherein the trust conditions include: the first proof result is the same as the second proof result obtained by the verification node based on the target parameters, and the first time interval associated with the first moment is within the time range allowed by the verification node.

[0050] In a third aspect, an embodiment of the present application provides a device for proving a node, comprising: an acquisition unit for acquiring a target address sequence, wherein the target address sequence points to target data to be verified; a processing unit for obtaining a proof result based on the target data; and a transceiver unit for providing the proof result to the verification node, wherein the proof result is associated with a first moment, and the proof result and the first moment are used for credibility verification of the target data.

[0051] In combination with the third aspect, in a possible implementation, the acquisition unit is used 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, and the target function includes a pseudo-random generation function.

[0052] In combination with the third aspect, in one possible implementation method, the acquisition unit is used to: obtain the target parameters from the challenge node or the real-time operating system RTOS of the first device to which the proof node belongs, wherein the challenge node is the node that triggers the verification of the credibility of the target data.

[0053] In combination with the third aspect, in a possible implementation, the acquisition unit is used to: obtain the target address sequence from the RTOS of the first device to which the proof node belongs, wherein the target address sequence is generated by the RTOS according to target parameters and target functions.

[0054] In combination with the third aspect, in one possible implementation, the proof 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 proof node belongs, and the resource unit is at least used to run a program.

[0055] In combination with the third aspect, in one possible implementation, the at least one first resource unit runs programs other than the critical programs of the first device, and the critical programs include at least programs for executing security tasks and / or programs for executing scheduling tasks.

[0056] In combination with the third aspect, in one possible implementation, 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. The processing unit is used to: adopt a target algorithm to calculate the at least two data blocks contained in the target data in a first order to obtain the proof result.

[0057] In combination with the third aspect, in a possible implementation, the target algorithm adopts a serial computing structure, and the target algorithm includes a hash algorithm.

[0058] In combination with the third aspect, in a possible implementation, the target address sequence includes the at least two addresses, and the at least two addresses point to at least two data blocks contained in the target data, and also 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 split.

[0059] In combination with the third aspect, in a possible implementation, the processing unit further includes: obtaining a base address; calculating an original value of the 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.

[0060] In combination with the third aspect, in a possible implementation, the processing unit is further used to: determine the marking information based on the original value; the proof node provides the marking information to the verification node, and the marking information is used to reversely deduce the original value.

[0061] In combination with the third aspect, in one possible implementation, the target data includes data in the memory space allocated for at least one of the following programs: a critical program or a proof program run by the proof node, and the critical program includes at least: a program for performing security tasks and / or a program for performing scheduling tasks.

[0062] In combination with the third aspect, in one possible implementation, the first device to which the proof 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 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 second device is a trusted device.

[0063] In combination with the third aspect, in one possible implementation method, when the target data meets the preset trust conditions, the credibility verification of the target data is passed; wherein, the trust conditions include: the proof result is the same as the proof 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.

[0064] In a fourth aspect, an embodiment of the present application discloses a device for verifying a node, comprising: an acquisition unit for obtaining a target parameter, wherein the target parameter includes a random number; obtaining a first proof result from a proof 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 a first moment; a determination unit for verifying the credibility of the target data based on the target parameter, the first proof result and the first moment.

[0065] In combination with the fourth aspect, in a possible implementation, the acquisition unit is used to: obtain the target parameters from the RTOS of the challenging node or the second device to which the verification node belongs, wherein the challenging node is the node that triggers the verification of the credibility of the target data.

[0066] In combination with the fourth aspect, in a possible implementation method, the determination unit is used to: obtain a second proof result based on the target parameter; the verification node verifies the credibility of the target data based on the second proof result, the first proof result and the first moment.

[0067] In combination with the fourth aspect, in a possible implementation method, the acquisition unit is used to: 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 device also includes a processing unit for obtaining the second proof result based on the mirror data.

[0068] In conjunction with the fourth aspect, in one possible implementation, the acquisition unit is configured to generate the target address sequence based on the target parameters and a target function. Alternatively, the acquisition unit is configured to acquire the target address sequence from an RTOS of a second device to which the verification node belongs based on the target parameters, the target address sequence being generated by the RTOS based on the target parameters and a target function. The target function includes a pseudo-random generator function.

[0069] In combination with the fourth aspect, in one possible implementation, 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 processing unit is used to: the verification node adopts the target algorithm to calculate the at least two data blocks contained in the mirror data in a first order to obtain the second proof result.

[0070] In conjunction with the fourth aspect, in a possible implementation, the target algorithm adopts a serial computing structure, and the target algorithm includes a hash algorithm.

[0071] In combination with the fourth aspect, in a possible implementation, the target address sequence includes the at least two addresses, and the at least two addresses point to at least two data blocks contained 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 split.

[0072] In combination with the fourth aspect, in one possible implementation, the acquisition unit is further used to: obtain marking information from the proof node; the determination unit is further used to determine the original value of the address pointing to the mirror data based on the marking information and the target address sequence, and the original value is used to read the mirror data.

[0073] In combination with the fourth aspect, in one possible implementation method, the acquisition unit is used to: use the target parameter as an index to obtain the second proof result from a first list, wherein the first list is used to indicate multiple parameters and the proof results associated with each parameter, and the multiple parameters include the target parameter.

[0074] In combination with the fourth aspect, in a possible implementation method, the acquisition unit is also used to obtain marking information from the proof node; using the target parameter as an index, obtaining the second proof result from the first list, including: the verification node using the target parameter and the marking information as indexes, obtaining the second proof result from the first list.

[0075] In combination with the fourth aspect, in one possible implementation, the first device to which the proof 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 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 second device is a trusted device.

[0076] In combination with the fourth aspect, in one possible implementation, the second device also 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.

[0077] In combination with the fourth aspect, in a possible implementation method, the verification node verifies the credibility of the target data based on the target parameters, the first proof result and the first moment, including: the verification node determines whether the target data meets the preset trust conditions based on the target parameters, the first proof result and the first moment to verify the credibility of the target data; wherein the trust conditions include: the first proof result is the same as the second proof result obtained by the verification node based on the target parameters, and the first time interval associated with the first moment is within the time range allowed by the verification node.

[0078] In a fifth aspect, an embodiment of the present application provides a communication system, comprising an apparatus for implementing the method described in the first aspect and any possible implementation of the first aspect, and an apparatus for implementing the method described in the second aspect and any possible implementation of the second aspect.

[0079] In the sixth aspect, an embodiment of the present application provides a chip system comprising at least one processor and an interface circuit, wherein the processor is used to execute the interaction of instructions and / or data through the interface circuit, so that the chip system executes the method described in the above-mentioned first aspect and any possible implementation of the first aspect, or executes the method described in the above-mentioned second aspect and any possible implementation of the second aspect.

[0080] In the seventh aspect, an embodiment of the present application provides a terminal, comprising the apparatus as described in the third aspect and any possible implementation of the third aspect or the chip system as described in the fifth aspect, and / or the apparatus as described in the fourth aspect and any possible implementation of the fourth aspect or the chip system as described in the fifth aspect, or comprising the communication system as described in the fifth aspect. For example, the terminal device 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 equipment, etc.).

[0081] In an eighth aspect, an embodiment of the present application provides a vehicle, which can be used to implement the method described in the first aspect and any possible implementation of the first aspect, and / or to implement the method described in the second aspect and any possible implementation of the second aspect.

[0082] In the ninth aspect, an embodiment of the present application provides a vehicle, which may include the device described in the third aspect and any possible implementation of the third aspect, and / or include the device described in the fourth aspect and any possible implementation of the fourth aspect, or include the communication system described in the fifth aspect.

[0083] In the tenth aspect, an embodiment of the present application provides a computer-readable storage medium, including a program or instruction. When the program or instruction is executed, the method described in the first aspect and any possible implementation of the first aspect is executed, or the method described in the second aspect and any possible implementation of the second aspect is executed.

[0084] In the eleventh aspect, an embodiment of the present application provides a computer program product. When a computer reads and executes the computer program product, the computer executes the method described in the first aspect and any possible implementation of the first aspect, or executes the method described in the second aspect and any possible implementation of the second aspect.

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

[0086] The technical effects that can be achieved by any possible implementation method in any of the second to eleventh aspects mentioned above can be referred to the description of the technical effects that can be achieved by any possible implementation method in any of the first aspect mentioned above, and the repetitions will not be discussed. BRIEF DESCRIPTION OF THE DRAWINGS

[0087] FIG1 is a schematic diagram showing the principle of the verification technology of an embodiment of the present application;

[0088] FIG2 is a schematic diagram showing a data segment in a program memory space according to an embodiment of the present application;

[0089] FIG3 shows a software-based verification architecture according to an embodiment of the present application;

[0090] FIG4 shows a hardware-based verification structure according to an embodiment of the present application;

[0091] FIG5 is a schematic diagram showing a system structure of an example of an embodiment of the present application;

[0092] FIG6 shows a schematic diagram of a verification framework according to an embodiment of the present application;

[0093] FIG7 shows a schematic diagram of another verification framework according to an embodiment of the present application;

[0094] FIG8 shows a schematic diagram of a verification principle based on a dual-core system according to an embodiment of the present application;

[0095] FIG9 shows a calculation process in an example attack scenario of an embodiment of the present application;

[0096] FIG10 shows an example of a certification result information table of an embodiment of the present application;

[0097] FIG11 shows a calculation process in another example attack scenario of an embodiment of the present application;

[0098] FIG12 shows a calculation process in another example attack scenario of an embodiment of the present application;

[0099] FIG13 shows a calculation process in another example attack scenario of an embodiment of the present application;

[0100] FIG14 is a schematic diagram showing a verification principle based on a multi-core system according to an embodiment of the present application;

[0101] FIG15 is a schematic diagram showing a flow chart of a verification method according to an embodiment of the present application;

[0102] FIG16 shows a schematic diagram of a device to be verified according to an embodiment of the present application;

[0103] FIG17 shows a schematic diagram of a verification device according to an embodiment of the present application;

[0104] FIG18 shows a schematic diagram of a communication device according to an embodiment of the present application. DETAILED DESCRIPTION

[0105] The following first explains some of the terms involved in the embodiments of the present application so that those skilled in the art can understand them.

[0106] 1. Attestation technology:

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

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

[0109] (1) Challenger: The party that issues a security challenge to the prover during the verification process.

[0110] The challenger sends a challenge (e.g., c) to the prover. This challenge (c) is also sent to the verifier. The purpose of the challenger sending the challenge is to add more randomness to the verification process and prevent attackers from forging responses.

[0111] (2) Prover: The party whose trusted state is checked during the verification process.

[0112] The prover can run a pre-set proof program based on the challenge sent by the challenger, calculate the target data to be verified, calculate the corresponding response (for example, represented as r) to the challenge (c), and provide it to the verifier to provide the verifier with a proof result of whether the prover is in a trustworthy state.

[0113] (3) Verifier: During the verification process, the party that verifies the prover's challenge and responds.

[0114] The verifier receives the challenge (c) and the prover's response (r) and verifies them. The verifier returns the verification result (e.g., V(c, r)) to the challenger. The challenger can use this verification result to determine the credibility of the prover's target data.

[0115] 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 can be different users, such as the challenger being the device user and the verifier being the device manufacturer, etc. This embodiment of the application does not limit this.

[0116] In the following embodiments, for ease of distinction, the challenger may be referred to as a challenge node, the prover may be referred to as a proof node, and the verifier may be referred to as a verification node. The device to which the proof node belongs may be referred to as a first device, the device to which the verification node belongs may be referred to as a second device, and the device to which the challenge node belongs may be referred to as a third device. The proof result obtained by the proof node performing the proof calculation process is referred to as a first proof result. The verification node may obtain a credible proof result (for example, represented as a second proof result) through the verification method of the embodiment of the present application, and use the second proof result to verify the first proof result from the proof node to obtain a verification result.

[0117] 2. Certification procedure:

[0118] The program that a proving node runs when performing the proving computation process.

[0119] In an embodiment of the present application, a proof program may be pre-installed in a first device to which the proving node belongs. Upon receiving a challenge from a challenging node, the first device to which the proving node belongs may run the proof program to perform a proof calculation process and obtain a first proof result. The proof program may include, but is not limited to, subroutines that perform the following calculations:

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

[0121] (2) reading at least two data blocks included in the target data according to at least two addresses in the target address sequence;

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

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

[0124] It should be noted that the above subroutines are merely examples of the proof procedures of the embodiments of the present application and are not limitations of any kind. In other embodiments, the proof procedures run by the proof nodes may include but are not limited to the above subroutines, which will not be described in detail here.

[0125] 3. Verification Procedure:

[0126] The program that a verification node runs when performing the verification calculation process.

[0127] In an embodiment of the present application, a verification program may be pre-installed in a second device belonging to the verification node. Upon receiving a challenge from the challenging node, the second device belonging to the verification node may run the verification program to perform a verification calculation process and obtain a verification result. The verification program may include, but is not limited to, subroutines that perform the following calculations:

[0128] (1) Obtaining a second proof result according to the target parameter that triggers the challenge;

[0129] (2) obtaining a first certification result from a certification node;

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

[0131] In an optional example of the embodiment of the present application, when running the verification program, the method for obtaining the second proof result based on the target parameter may be similar to the method for obtaining the first proof result on the proof node side. Specifically, for example, the verification program may include but is not limited to a subroutine that performs the following calculation processing:

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

[0133] (1.2) reading at least two data blocks included in the mirror data of the target data according to at least two addresses in the target address sequence;

[0134] (1.3) Processing the different data blocks read according to data characteristics, such as segmentation;

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

[0136] In another optional example of an embodiment of the present application, the verification program may include a table lookup program. When the verification program is run, it can obtain locally stored trusted information by table lookup based on the target parameters from the challenge node, and use the trusted information as the second proof result to verify the first proof result from the proof node to verify the credibility of the target data of the first device to which the proof node belongs.

[0137] It should be noted that the above subroutines are merely examples of the verification procedures of the embodiments of the present application and are not limitations of any kind. In other embodiments, the verification procedures run by the verification nodes may include but are not limited to the above subroutines, which will not be described in detail here.

[0138] 4. Program memory space (or memory segment):

[0139] In a computer, 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.

[0140] In an 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, and the key program described below. During the program execution, the data in the program memory space can be divided into different data segments (segments) according to their use, such as a code segment, a read-only data segment, and a normal data segment, as shown in Figure 2. Among them, different data segments represent different access rights for the data in the segment. For example, the data in the code segment is executable but not readable or writable; the data in the read-only data segment is not executable and can only be read; the data in the normal 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.

[0141] In the field of verification technology, the following attack scenarios exist in the industry for different data segments of program memory space:

[0142] (1) Code injection attack scenario:

[0143] A code injection attack refers to an attacker (or attack node) modifying the code segment data to change the operations performed by the code during execution, thereby performing malicious operations and endangering security.

[0144] (2) Key data tampering attack scenario:

[0145] A critical data tampering attack refers to an attacker modifying critical data (such as static data) in different data segments, such as access permission data, machine configuration data, etc., to indirectly change the operations performed during the execution process, thereby performing malicious operations and endangering security.

[0146] (3) Code pointer (CP) / data pointer (DP) tampering attack scenario:

[0147] A code pointer / data pointer tampering attack refers to an attacker modifying the code pointer pointing to the code address or the data pointer pointing to the data address, indirectly changing the operations performed during the execution process, performing malicious operations and endangering security.

[0148] Among them, the pointer is the memory address, and the pointer variable is a variable used to store the memory address. Under the same CPU architecture, the storage unit length occupied by different types of pointer variables is the same, while the storage space length occupied by the variable storing data varies depending on the type of data.

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

[0150] 5. Software based attestation (SWAT) technology:

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

[0152] As shown in Figure 3, the operating environment includes a conventional execution environment (rich execution environment, REE). The application (APP) running in the REE is a program that can be attacked by attackers and is a potential malicious program. The certification 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 verified data may be tampered with by malicious programs, and security cannot be guaranteed.

[0153] 6. Hardware based attestation technology:

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

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

[0156] However, due to hardware-based isolation, the execution context needs to be frequently switched between the REE and TEE, which will incur a significant performance overhead. Therefore, if applications with high real-time requirements (such as intelligent vehicle control) are placed in the TEE, there will be a significant performance loss when verifying the device's trusted state. In some real-world application scenarios (such as smart cars), hardware-based verification architectures are often not used due to actual performance considerations. Therefore, in these scenarios with high performance requirements, software-based verification technologies are needed to verify whether the device is in a trusted state. However, in verification scenarios based on software-based verification technologies, how to ensure security remains a critical issue that needs to be addressed.

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

[0158] SoC refers to the technology of integrating a complete system on a single chip and packaging all or part of the necessary electronic circuits.

[0159] The system typically includes a central processing unit (CPU), memory, and peripheral circuits. The specific modules integrated into an SoC can vary and become more complex depending on the application scenario. For example, a system-on-chip (SoC) for a sound detection device provides all user devices, including an audio receiver, an analog-to-digital converter (ADC), a microprocessor, necessary memory, and input / output logic control, all on a single chip.

[0160] The SoC to which the embodiments of the present application are applicable may include two parts, such as a CPU part and a hardware security module (HSM) part. The CPU part is non-trusted hardware and may include at least two CPU cores (an example of a resource unit, at least for running a program), and the HSM part is trusted hardware based on hardware isolation. When applied to a SoC, in an optional embodiment, the proof node of the embodiment of the present application may be located in the CPU part, and the verification node and the challenge node may be located in the HSM part.

[0161] 8. Key tasks, key programs and modules, and key data:

[0162] In the embodiment of the present 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.

[0163] Key programs and key modules are code segments that implement key tasks. Key programs can include complete operational logic, such as the code for a visual recognition program. Key modules are sections of code that implement key program functions, such as the machine learning logic for a visual recognition program or the scheduling logic in an operating system.

[0164] Critical data is data for implementing critical tasks, and may include data located in different data segments in the program memory space, such as code segment critical data, read-only data segment critical data, normal data segment critical data, etc.

[0165] 9. Program interruption method:

[0166] A computer message notification method. A program interrupt occurs when a computer encounters an unexpected situation or special request that requires urgent attention during program execution. The CPU temporarily terminates the current program and switches to executing the interrupt service routine to handle the more urgent, random event. After the interrupt is handled, the CPU automatically returns to the original program and continues execution. Program interrupts are applicable not only to external device input and output operations, but also to handling random external events.

[0167] In an embodiment of the present application, the first device to which the proof 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 trigger the execution of corresponding sub-processes included in the verification process by using a program interrupt method. Wherein, 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 for triggering the challenge to the first device to which the proof 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 of the first device, and obtain the first proof result, which can be provided to the second device to which the verification node belongs. When initiating a challenge, the interrupt service program of the third device can also simultaneously send the target parameter for initiating the challenge to the second device to which the verification node belongs. After the second device to which the verification node belongs receives the target parameter, the interrupt service program is activated and executed, triggering the running of the preset verification program to obtain the first proof result from the proof node, and verifying the credibility of the target data of the first device in combination with the first proof result.

[0168] Among them, 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 first resource unit and at least one second resource unit of the at least two resource units can be respectively bound and used to run different programs of the first device. For example, at least one first resource unit is used to run programs other than critical programs of the first device (such as proof programs), and at least one second resource unit is used to run critical programs of the first device, which at least include programs for executing security tasks and / or programs for executing scheduling tasks. For example, the first device can be a dual-core or multi-core device, and the resource unit of the first device can be, for example, a CPU core of the first device. The first device can include at least two CPU cores. The CPU core bound to run critical programs can be called a second core, and the CPU core bound to run programs other than critical programs can be called a first core.

[0169] It should be noted that the program interruption method is only an example of the communication method between the devices to which the challenge node, the proof node and the verification node belong in the embodiment of the present application, and it is not any limitation. In other embodiments, the devices to which each node belongs can also adopt any suitable communication method (such as network communication, software and hardware communication, etc.) to realize information interaction to initiate the verification process. The embodiment of the present application does not limit this.

[0170] It should be noted that, in the embodiments of the present application, "at least one" refers to one or more, and "more" refers to two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent: the existence of A alone, the existence of A and B at the same time, and the existence of B alone, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following items" or similar expressions refers to any combination of these items, including any combination of single items or plural 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.

[0171] Furthermore, unless otherwise specified, ordinal numbers such as "first," "second," and "third" in the embodiments of this application are used to distinguish between multiple objects and are not used to define the priority or importance of multiple objects. For example, the first device, the second device, and the third device are only used to distinguish different devices, and do not indicate different priorities or importance of the three devices.

[0172] The embodiments of the present application provide a verification method, device, and system that help improve security in a system architecture based on software verification technology. The method and device are based on the same technical concept. Since the method and device solve similar problems, the implementation of the device and method can refer to each other, and the repeated parts will not be repeated.

[0173] For ease of understanding, the verification scheme of the present application embodiment is described below using the smart car scenario as an example. It should be understood that the verification scheme of the present application embodiment can also be applied to other scenarios with high performance requirements and the need to ensure data security based on software verification technology, and the present application embodiment does not limit this.

[0174] FIG5 shows a schematic diagram of a system architecture of an example of an embodiment of the present application.

[0175] As shown in FIG5 , the system architecture may include multiple modules located on the same SoC, such as a CPU (e.g., denoted as an ECU CPU) of at least one electronic control unit (ECU) connected to a vehicle, and a hardware security module (HSM) deployed on the same system on a chip (SoC).

[0176] 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.

[0177] The ECU CPU includes at least two CPU cores, a real-time operating system (RTOS) running on the at least two CPU cores (for ease of distinction, for example, represented as RTOS1 ), and all application programs (for example, APP1 and APP2 ).

[0178] The HSM may include an HSM core, an RTOS (e.g., RTOS2) running on the HSM core, and an application for implementing secure services. The secure services may include, but are not limited to: cryptographic acceleration programs, such as the Advanced Encryption Standard (AES) and RSA (Rivest-Shamir-Adleman) encryption algorithms; secure file storage; over-the-air technology (OTA) upgrades; password storage; anomaly detection, etc.

[0179] The SoC contains two memory blocks: a larger main memory for the CPU core and a smaller private memory for the HSM core. Communication between the CPU and HSM cores occurs via a shared memory block. When the CPU core transfers data to the HSM core, the following steps are involved:

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

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

[0182] S3: After the corresponding interrupt service routine on the HSM core is activated, the data stored in the shared memory is read. Thus, the CPU core completes the data transmission to the HSM core.

[0183] Similarly, when the HSM core transmits data to the CPU core, the HSM core can write the data to the shared memory through steps similar to S1-S3 above, allowing the activated interrupt service routine on the CPU core to read the data. Unless otherwise specified, information exchange 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 further described below.

[0184] 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 on the HSM. The target data to be verified is stored and run in the main memory. The CPU core transmits the target data to be verified to the HSM through shared memory for the proof node and verification node to perform subsequent proof calculation and verification calculation processes to verify the credibility of the target data.

[0185] Similar to the verification process implemented by the hardware-isolated verification framework in FIG4 , in the verification process implemented by the verification framework in FIG6 , the proving node can continuously read the data blocks contained in the target data to be verified from shared memory, calculate the corresponding proof results based on the data blocks contained in the target data, and then send the proof results to the verification node. However, unlike the hardware-based verification framework in FIG4 , the verification framework in FIG6 embodies the fact that the target data to be verified itself runs in main memory. This creates the possibility that an attacking node could exploit this difference and restore the tampered data in the target data to the original data before the proving node reads the target data from shared memory. In this way, the proving node still performs calculations based on the original data, and the resulting proof results may still indicate that the data is trustworthy, and it cannot detect whether the data has been tampered with or restored, thus failing to ensure security.

[0186] Furthermore, the verification framework shown in Figure 6 requires a significant amount of communication bandwidth between the CPU core and the HSM core. Specifically, due to the size of the HSM core's internal input and output buffers, the amount of data the HSM core can read from shared memory at one time is limited. When the target data to be verified is very large, the proving node must repeatedly interact with the shared memory through the HSM core to continuously read the data blocks containing the target data. This approach reduces the HSM core's time to respond to other security requests.

[0187] For example, when a network communication application running on a CPU core needs to encrypt a data packet, it writes the packet to shared memory and requests the HSM core to encrypt it via an interrupt request. If the attestation node is continuously reading data from shared memory at this time, the HSM core's response to the packet encryption request will be delayed.

[0188] Therefore, the verification framework shown in Figure 6 cannot take into account both security and performance overhead.

[0189] To address this issue, an embodiment of the present application proposes a verification framework. As shown in FIG7 , based on the system architecture shown in FIG5 , the proof node can be run on the target CPU core (either of the two CPU cores in FIG7 ) on the ECU CPU side, while the challenge node and verification node can be run on the HSM core. The target data to be verified is stored in the main memory accessible to the target CPU core, and the mirror data of the target data is stored in the private memory accessible to the HSM core. It should be understood that the challenge node can also be located in a different device from the verification node, for example, the challenge node can be located in a device other than the ECU CPU and HSM (not shown in FIG7 ).

[0190] Taking the challenge node and the verification node as an example, in Figure 7, when the challenge node needs to perform security verification on the target data to be verified on the ECU CPU side, it can, for example, write the target parameters for initiating the challenge into the shared memory through the HSM core and send an interrupt request to the CPU core. The corresponding interrupt service program on the CPU side can be activated in response to the interrupt request and read the target parameters from the shared memory. At the same time, the interrupt service program can instruct the proof node to run a preset proof program based on the obtained target parameters to calculate the target data to be verified, obtain a first proof result, and send the first proof result to the verification node through the shared memory. The verification node can run a preset verification program in response to the target parameters from the challenge node, and verify the credibility of the target data based on the target parameters and the first proof result from the proof node, while adding information of other inspection dimensions of the embodiment of the present application (such as the execution time information of the proof calculation process of the proof node).

[0191] The verification framework shown in Figure 7, on the one hand, can be constructed using existing hardware security modules in smart car scenarios, requiring no additional hardware modifications, resulting in minimal changes to the system architecture and high compatibility. On the other hand, by running the proof node and the target data to be verified in the ECU CPU's regular execution environment and performing the complete proof calculation process without switching execution contexts, the communication volume between the ECU CPU and the HSM can be greatly reduced, lowering performance overhead and ensuring that the implementation of the current business of the ECU CPU or HSM is not affected by the verification process. Furthermore, the verification node can combine information from at least two inspection dimensions to jointly verify the credibility of the ECU CPU's target data to be verified, effectively preventing attacks and ensuring security.

[0192] It should be noted that the system architecture shown in Figures 5-7 above is merely an example of an SoC and is intended to illustrate the applicable scenarios of the verification scheme of the embodiments of the present application, rather than to limit them in any way. 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 embodiments of the present application. For example, the HSM in Figure 7 can be applied to a 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) containing the HSM in Figure 7 can also be applied to the security verification scenario of an external device locally connected to the board device. The external device can typically include a device that does not have trusted hardware or an HSM due to cost reasons. For example, the board device can include, but is not limited to, a mobile data center (MDC), a vehicle dynamics control system (VDC), etc. When the ECU CPU and HSM are located in different devices, it is at least necessary to ensure that the HSM where the verification node is located is a trusted device, and the proof node can run in an untrusted device. The trusted device and the untrusted device can communicate and interact with each other through messages or other methods to implement the verification method of the embodiment of the present application. The embodiment of the present application does not limit this communication method.

[0193] For ease of understanding, the following describes the implementation principles of the verification scheme of the present invention in an SoC scenario, using the verification scheme of the ECU CPU of the proving node as the first device and the HSM of the challenge node and verification node as the second device (i.e., the second device and the third device are the same device) as an example. The verification framework shown in FIG7 is combined with FIG8 to describe the implementation principles of the verification scheme of the present invention. FIG8 does not illustrate the information exchange process between the ECU CPU and the HSM and the memory. Detailed implementation details can be found in the relevant descriptions of FIG5-FIG7 and are not repeated here.

[0194] As shown in FIG8 , taking a dual-core system (including two CPU cores) as an example, the verification solution may include the following steps:

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

[0196] 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 service program of the HSM. The interrupt service program runs on RTOS2 and can send an interrupt request to the ECU CPU to which the proving node belongs to initiate a challenge.

[0197] As described above in conjunction with Figures 5 and 7 , in the SoC scenario, the HSM core can write the target parameter of the challenge to shared memory, which is then read by the corresponding interrupt service routine activated on the ECU CPU. For example, the target parameter can include a random number, such as N.

[0198] S820: In response to the interrupt request from the HSM, the corresponding interrupt service routine on the ECU CPU side may be activated. This interrupt service routine may run on RTOS1 and instruct the attestation node to run a pre-set attestation program, thereby executing the attestation calculation process. The attestation calculation process may include the following steps:

[0199] S821: The proof node runs a preset proof program on the target CPU core allocated by the task scheduler.

[0200] In an embodiment of the present application, the task scheduler running on RTOS1 is an example of a key module of the ECU CPU, which is used to perform scheduling tasks. For example, the CPU core is an example of a resource unit of the first device. In the first device, the task scheduler can bind one of the two CPU cores of the ECU CPU (for example, CPU core 1) to a key program for performing a key task by setting (for example, affinity setting), and bind the other CPU core (for example, CPU core 2) as the target core to a program other than the key program, such as a proof program. The proof node can run a preset proof program on the target core according to the scheduling information of the task scheduler, thereby executing the proof calculation process and obtaining a first proof result.

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

[0202] S822: During the execution of the proof program, the proof node may obtain a target address sequence generated by the target function, and calculate based on the target address sequence to obtain a first proof result.

[0203] In an embodiment of the present 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 can read the target data according to the target address sequence and perform calculations to obtain the first proof result.

[0204] In a specific implementation, in a first possible implementation, 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 target parameters for initiating the challenge from the challenge node, the interrupt service routine 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 provide the target address sequence to the proof node, which then performs the subsequent proof calculation process based on the target address sequence. The interrupt service routine can call the program corresponding to the target function running on RTOS1 based on the target parameters to trigger the execution of the program corresponding to the target function and the generation of 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 for initiating the challenge from the challenge node, the interrupt service routine activated on the ECU CPU side can trigger the proof node to call the program corresponding to the target function by sending the target parameters for triggering 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.

[0205] For example, the target function may include a pseudo-random number generator function. In the first possible implementation and the second possible implementation described above, when the program corresponding to the target function is running, the target parameter that triggers the challenge can be used as a seed to generate the target address sequence using a pseudo-random number generator. 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, representing the number of the at least two addresses, and L is an integer greater than or equal to 2. In an optional embodiment, the target address sequence may be associated with time point 2, and the time point 2 may be provided to the verification node in association with the calculated first proof result as one of the time information for verifying the credibility of the target data. This will be described in detail in the embodiments below and will not be repeated here.

[0206] It should be noted that S822 in FIG8 is merely a schematic illustration of how a target address sequence can be generated by running the program corresponding to the target function, and does not limit the method for generating the target address sequence. Furthermore, the program corresponding to the task scheduler and the program for executing key tasks (not shown in the figure) may be examples of key programs in embodiments of the present application. The program corresponding to the target function may be a subroutine included in the proof program, which may also include other subroutines (not shown). For details, please refer to the relevant description above and will not be repeated here.

[0207] After obtaining the target address sequence, the proving node can read the data blocks contained in the target data according to the addresses contained in the target address sequence, and use the target algorithm to calculate the data blocks contained in the target data in a first order to obtain a first proof result.

[0208] Among them, the target data to be verified on the ECU CPU side may include any data on the first device side that needs to be verified for credibility. For example, the target data may be data in the memory space allocated to any of the following programs: critical programs or proof programs. Critical programs may at least include programs for executing security tasks and / or programs for executing scheduling tasks. Among them, the security task and scheduling task are an example of a critical task. The security task includes tasks that need to be securely protected on the ECU CPU side, such as tasks for running artificial intelligence (AI) recognition algorithms. Scheduling tasks may include tasks performed by a task scheduler, such as scheduling a target core for a proof node. The proof program includes all programs preset in the ECU CPU for the proof node for implementing the proof calculation process. It should be understood that this is only an example description of the target data to be verified and not a limitation. In actual applications, the target data to be verified may not be limited to the above examples and will not be repeated here.

[0209] In an optional embodiment, the target algorithm may adopt a serial calculation structure. For example, the serial calculation structure may include M function blocks (for example, represented as F) for serial calculation, each function block is configured to use the target algorithm for calculation, and can be used to calculate the input address or data content until a proof result is obtained, M≥L, M is an integer. According to the serial calculation structure, it is a structure that cannot perform parallel calculations. When performing proof calculations based on this structure, it is necessary to wait until the calculation of the previous function block is completed and the corresponding calculation result is obtained before the next address or the next part of the data content can be calculated based on the next function block. In this way, the attacker will not be able to use 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 calculation structure may be a Merkle–Damgard structure. The above-mentioned target algorithm may include a hash algorithm, including but not limited to hash algorithms such as MD5 and SHA1, and the first proof result obtained is, for example, a hash value.

[0210] For example, as shown in FIG9 , 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 include five data blocks, represented as V1, V2, V3, V4, and 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 8 bytes or longer (for example, 32 bytes). The details are not repeated here. When the proof node adopts the target algorithm and constructs the serial calculation structure in the first order, it can start from the initialization vector (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 into the function blocks F1-F5 for calculation in sequence. After the final calculation is completed (finalized), the first proof result is obtained.

[0211] It should be noted that FIG9 merely illustrates the correspondence between the addresses in the target address sequence, the data blocks included in the target data, and the function blocks of the serial computing structure, and does not limit the content input into each function block of the serial computing structure. In other embodiments, depending on the specific implementation of the target algorithm employed, for example, the values ​​of at least two addresses in the target address sequence may be used as input content for each function block of the serial computing structure, so that each function block can read the corresponding data block according to the address and perform calculations until the first proof result is obtained. The embodiments of this application do not limit the specific implementation of this calculation.

[0212] S830: The proving node provides the first proving result to the verifying node.

[0213] For example, at time point 3, the certifying 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 certifying node at time point 3. Furthermore, when the verification node runs a pre-configured verification program, it may verify the credibility of the target data based on information from at least two inspection dimensions, including the first certification result.

[0214] For example, the information of the at least two inspection dimensions may include the first proof result itself and execution time information of the proof calculation process of the proof node. The execution time information may be determined, for example, by time point 1 (e.g., referred to as the second moment) when the challenge is triggered and time point 3 (e.g., referred to as the first moment) when the proof calculation process ends, such as the time difference between time point 1 and time point 3. The verification node may simultaneously determine, based on the first proof result and the time difference, whether the target data of the first device to which the proof node belongs meets a preset trust condition, thereby determining the trustworthiness of the target data.

[0215] For example, the trust condition may include: the first proof result provided by the proof node 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.

[0216] Among them, when performing credibility verification based on the above-mentioned execution time information, the verification node can determine whether the total time consumed by the proof node to execute the above-mentioned proof 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 as the first time interval is within the credible time range (because the time error caused by communication interaction has been pre-estimated and included in the allowed time range). If the time difference is too long or too short and is not within the credible time range, the proof node may be attacked, indicating that the first proof result from the proof node is untrustworthy. If the time difference is within the credible time interval, it at least indicates that the proof node is credible in the execution time dimension.

[0217] When performing credibility verification based on the first attestation result, the verification node can obtain a trusted second attestation result based on the target parameters and verify the credibility of the target data by comparing the second attestation result with the first attestation result. If they are identical, the first attestation result on the verification node is trusted, proving that the target data of the first device belonging to the node has not been tampered with. If they are different, the first attestation result on the verification node is untrustworthy, proving that the target data of the first device belonging to the node may have been illegally tampered with.

[0218] The verification node can only determine the credibility of the target data on the certification node if the execution time information is within the permitted time range and the first verification result is the same as the second verification result. If any of the above conditions are not met, the target data on the certification node is considered untrustworthy, and the first device to which the certification node belongs may have been illegally attacked.

[0219] It should be noted that, in embodiments of the present application, on the verification node side, the second proof result may be obtained by executing the same computational process as that performed on the proving node side. For example, after receiving the target parameter sent by the challenge node via the interrupt service routine, the verification node may run a pre-installed verification program in the HSM core, execute the same computational process as described in S822 above, and calculate based on the mirror data of the target data to be verified stored in the private memory to obtain the second proof result. Detailed implementation details can be found in the computational process described above in conjunction with the proving node (e.g., replacing the target data with the mirror data), and will not be further elaborated here.

[0220] However, since the same calculation process as S822 is performed on the verification node side, it is necessary to store the mirror data in the private memory of the HSM. Although the additionally stored mirror data will not affect the final calculation result, it will occupy a large amount of storage space. When the private memory of the HSM is not sufficient to store the mirror data of all target data, it will affect the implementation of the verification scheme of the embodiment of the present application.

[0221] Therefore, an optional implementation approach is to not store the mirror data of the target data to be verified in the private memory space of the HSM, but to pre-maintain a list, such as a proof result information table or a first list. This first list can be used to store multiple parameters and the trusted proof results associated with each parameter, which may include the target parameter. After receiving the target parameter from the challenge node and the first proof result from the proving node, the verification node can use the target parameter as an index to retrieve the expected proof result from the stored first list through a table lookup, representing it as the second proof result. Thus, the proving node can simultaneously verify the credibility of the target data based on information such as the received first proof result, the second proof result obtained through table lookup, and the time point 3 at which the first proof result was received.

[0222] Among them, multiple parameters in the first list are random numbers, and the challenging node can select a target parameter from the multiple parameters contained in the first list to initiate a challenge. The verification node can use the same pseudo-random number generator function as the proof node to generate a 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 proof node side is certain and predictable. Based on this, the verification node can generate the proof result corresponding to each random number according to the target algorithm in advance, and store it in the private memory of the HSM. Due to the credibility of the private memory, the second proof result obtained by the verification node through table lookup is credible and can be used to verify the credibility of the first proof result.

[0223] Taking the example where the parameters recorded in the first list are random numbers, the target algorithm adopted by the verification node is a hash algorithm, and the proof result calculated based on each parameter is a hash value, the first list maintained by the verification node is a list of verification hash values, as shown in Figure 10. The first list can include at least multiple random numbers (for example, expressed as N1, N2, N3, N4, N5, etc.) and a hash value paired with each random number (for example, expressed as hash value 1, hash value 2, hash value 3, hash value 4, hash value 5).

[0224] When the challenge node randomly selects a random number (e.g., 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 by looking up the table. According to the target parameter N1 that triggers the challenge obtained from the challenge node and the saved first list, it queries the corresponding hash value 1 through N1 as the second proof result. When performing credibility 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, the proof results obtained by both parties are the same, indicating 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 or hash value 5 or other hash values, the proof results obtained by both parties are different, indicating that the first proof result from the proof node is untrustworthy and the target data may have been illegally tampered with.

[0225] It should be understood that FIG10 is only an example of the first list of the embodiment of the present application and is not limiting. In actual applications, the length of the first list is not limited to 5 pairs of data. The length of the first list can be appropriately increased as needed, for example, to 1000 pairs of data, so that it is difficult for an attacker to obtain all the information in the first list, or it is difficult to obtain all the information in 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 the address contained in the target address sequence that can be predicted based on multiple parameters and the target function. This will be described in conjunction with the embodiment below and will not be repeated here.

[0226] It should be noted that the processing method shown in FIG9 can be applied to perform proof calculation on the target data in the code segment shown in FIG2. In the code injection attack scenario (1) described above, by combining the calculation method shown in FIG9 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, it can effectively prevent the attacker from tampering with the code segment data.

[0227] In addition, in the (2) key data tampering attack scenario mentioned above, the attacker can attack by modifying the key data in each data segment of the program. The key data may include, for example, file access permission data, machine configuration data, etc. Therefore, the target data to be verified is not limited to code segment data, but may also include data in the read-only data segment shown in FIG2 or data in the normal 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 is between tens of megabytes (MB, 1MB = 1024KB) and hundreds of megabytes. For another example, the length of some configuration files to be verified is about 10 kilobytes (KB, 1KB = 1024 bits). For another example, the length of some passwords to be verified is about 128 bits (bite). Some algorithms limit the maximum data length of the input algorithm function. For example, some hash algorithms limit the length of data input into a hash constructor (F) to a maximum of 64 bytes.

[0228] In the (2) critical 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, and the data length threshold is used to indicate the maximum data length input in the function block corresponding to the address. If the data block contained in the target data is read according to the value of the address in the target address sequence, when the length of the data block pointed to by a certain address or certain addresses (for example, represented as a first address, the number of which is not limited to one) exceeds the data length threshold, the data block can be split, and then a serial calculation structure is constructed based on the data blocks that do not need to be split and the data blocks obtained after the splitting process, and the calculation is performed.

[0229] As shown in Figure 11, taking the target address sequence including three addresses (L=3) as an example, the three addresses can be expressed as A1, A2, and A3. The data blocks read based on A1-A3 are expressed as V1, V2, and V3. Assuming 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, and the data lengths of V1, V2, and V3 are 60 bytes, 70 bytes, and 90 bytes respectively, then the data length of V1 is less than 64 bytes and does not need to be split; the data length of V2 is greater than 64 bytes and less than 128 bytes, and V2 needs to be split into two data blocks, for example, expressed as V2-1 and V2-2. The data length of V3 is greater than 64 bytes and less than 128 bytes, and V3 needs to be split into two data blocks, for example, expressed as V3-1 and V3-2.

[0230] The target data obtained according to the 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 calculation structure based on a process similar to Figure 9 using the target algorithm and the first order. For example: starting from IV, five function blocks are constructed, represented as F1, F2, F3, F4, and F5. The data blocks V1, V2-1, V2-2, V3-1, and V3-2 contained in the target data will be input into F1-F5 in the first order for calculation, and after the final calculation is completed (finalize), the corresponding first proof result is obtained. Similarly, the verification node can perform the same calculation steps and obtain the corresponding second proof result according to the calculation processing method shown in Figure 11, or obtain the second proof result by looking up the table.

[0231] Therefore, by combining the calculation method shown in Figure 11, the data length of the data stored at the address corresponding to the target address sequence is increased during the verification process, ensuring that all data in the data block pointed to by the address is recorded in the hash value. In this case, even if an 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. Therefore, when the first proof result is obtained from the proving node and verified by the verification node, and the verification result indicates that the first proof result is credible, it can effectively prevent attackers from tampering with the critical data statically stored in each data segment.

[0232] It should be noted that the above embodiment uses the hash algorithm as an example to illustrate the data length threshold, but does not limit it. In other embodiments, for example, a corresponding data length threshold can be preset based on the data type, and the preset data length thresholds for different addresses can be different. The data length threshold can be an empirical value or determined based on the algorithm parameters used. The embodiment of the present application does not limit the method for determining the data length threshold corresponding to each address in the target address sequence. In addition, the number of times the data block pointed to by each address is split 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, then V3 needs to be split three times according to the data length threshold of 64 bytes to obtain four data sub-blocks, represented as V3-1, V3-2, V3-3, and V3-4. Therefore, the calculation structure and calculation can be constructed and performed using the same method as Figure 11, and calculations are performed on V3-1, V3-2, V3-3, and V3-4 respectively until the corresponding calculation structure is obtained.

[0233] 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-mentioned 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 segment 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. The embodiment of the present application can protect the pointers stored in the static data area (including static code pointers and static data pointers).

[0234] Because the code and data addresses of a program are randomized during execution, the values ​​of the code and data pointers are also randomized accordingly. This randomization method is as follows: when the CPU first runs a program, the operating system randomizes the base address of the program when loading the program, generating a random base address that remains unchanged after the program runs. The code / data address is the sum of the original value (physical space address) of the code / data plus this base address. This original value is a fixed value, while the randomly generated base address remains unchanged during a single run and changes after each CPU restart.

[0235] In S822 above, each address in the target address sequence generated by the target function may store a code pointer or data pointer. This code pointer or data pointer is obtained based on a randomized base address and does not point to the original value of the code / data. Before reading the data blocks contained in the target data based on the values ​​of the addresses contained in the target address sequence, the proving node can obtain the base address and, based on the base address and the values ​​stored in at least two addresses in the target address sequence, calculate the original values ​​of the addresses pointing to each data block of the target data. This original value is used to read each data block of the target data. Furthermore, the proving node (or verification node) can perform a calculation process similar to that of Figures 9 or 11 based on the calculated original values, reading the target data and calculating the corresponding proof result based on the original values.

[0236] As shown in FIG12 , taking the target address sequence including three addresses (L=3) as an example, these three addresses can be represented as A1, A2, and A3. The values ​​stored in A1-A3 are the values ​​of static code pointers or static data pointers affected by the randomized base address, represented as CP1, DP3, and DP1, for example. The proving node can obtain the base address (represented as B, for example) and determine the original value of the address pointing to the target data to be verified based on the values ​​of the addresses included in the target address sequence and the base address, for example, by subtracting the base address from the values ​​of each address included in the target address sequence, represented as CP1-B, DP3-B, and DP1-B. Furthermore, the proving node constructs a serial calculation structure using a method similar to FIG9 or FIG11 , and performs serial calculations on the data blocks read based on these original values ​​until the corresponding proof result is obtained. Similar calculation processes can be found in the relevant descriptions above in conjunction with FIG9 and FIG11 , and will not be repeated here.

[0237] Furthermore, a single address can store multiple pointer values: an address can only store one pointer at a given point in time, but the pointers stored at different points in time can be different. To distinguish the address content during the current proof calculation, one possible implementation is for the proving node to obtain tag information based on the original value used in the calculation. The proving node can also provide this tag information to the verification node so that the verification node can verify the credibility of the target data.

[0238] For example, the proof node can 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 an embodiment of the present application, for example, the last bit (least 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 tags 1, 2, and 3 corresponding to the original values ​​CP1-B, DP3-B, and DP1-B, respectively, can be expressed as LSB8(CP1-B), LSB8(DP3-B), and LSB8(DP1-B).

[0239] Ultimately, the proving node needs to send both the calculated first proof result and the detected marking information to the verification node, which then verifies the credibility of the target data based on the first proof result and the marking information.

[0240] Because the proving node and the verification node use the same multiple parameters and pseudo-random number generator function, the verification node can predict and store the multiple randomly generated addresses and their associated original pointer values ​​on the proving node through pre-program analysis. For example, the verification node can maintain a reverse lookup table on the HSM. After receiving the first proof result and tag information from the proving node, the verification node can use each tag information, combined with the reverse lookup table, to infer the original values ​​used by the proving node during the calculation. Based on these original values, the verification node can perform the same calculation process as the proving node to obtain the desired second proof result. Therefore, at time point 3, the verification node can determine whether the total time taken to execute the proof calculation process meets the preset trustworthiness criteria and whether the first and second proof results are identical. If the total time is within the time range allowed by the verification node and the proof results obtained by both parties are the same, the target data on the proving node has not been tampered with by an attacker and is trustworthy. If the total time is not within the time range allowed by the verification node and / or the proof results obtained by both parties are different, the target data on the proving node may have been illegally tampered with and is untrustworthy. It should be understood that the reverse lookup table may belong to the first list mentioned above, or may be a second list independent of the first list, and the embodiment of the present application does not limit this.

[0241] Based on the calculation process implemented on the proof node side shown in Figure 12, as shown in Figure 13, on the verification node side, the pre-stored reverse 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, and A3. Each address may store multiple code pointers or data pointers (original pointers that are not randomized based on the base address), for example, CP1*, CP2*, CP3*, and CP4* stored in A1 are represented as CP1*@A1, CP2*@A1, CP3*@A1, and CP4*@A1; DP1*, DP2*, and DP3* stored in A2 are represented as DP1*@A2, DP2*@A2, and DP3*@A2; and DP1*, DP2*, and DP3* stored in A3 are represented as DP1*@A3, DP2*@A3, and DP3*@A3. After receiving at least two tags (e.g., Tag 1, Tag 2, and Tag 3) from the proving node, the verification node can reversely deduce the original pointer values ​​associated with A1, A2, and A3 (e.g., CP1*, DP3*, and DP1*) used by the proving node during the proof calculation process using the reverse lookup table. The verification node can then perform the same computational steps as the proving node based on the original pointer values, performing a hash calculation on the mirrored data block read based on the original pointers, until a corresponding second proof result is obtained. The verification node can then compare this second proof result with the first proof result from the proving node to verify the credibility of the target data on the proving node.

[0242] It should be noted that, theoretically, if the target data has not been tampered with by the attacker, CP1*=CP1-B, DP3*=DP3-B, and DP1*=DP1-B. After the verification node performs calculations based on CP1*, DP3*, and DP1*, the second proof result obtained is the same as the first proof result from the proof node, indicating that the target data is trustworthy. If the target data has been tampered with by the attacker, the above equations may not hold. For example, at least one of CP1*=CP1-B, DP3*=DP3-B, and DP1*=DP1-B may not hold. As a result, when the verification node performs calculations based on CP1*, DP3*, and DP1*, the final second proof result obtained will be different from the first proof result from the proof node, indicating that the target data is untrustworthy.

[0243] So far, the dual-core system architecture applicable to the embodiment of the present application and the detailed implementation process of the verification method implemented under this system architecture have been introduced based on the above-mentioned combination of Figures 8 to 13. Through the above-mentioned 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 inspection dimension information (such as execution time information), so as to verify the trusted state of the first device to which the proof node belongs and ensure the security of the first device. At the same time, the scheme can also protect the target data in many aspects and effectively prevent attacks by randomly extracting the code segments, configuration data (files), static code pointers, and static data pointers running by the key program or proof program of the first device and verifying them using different methods. On the other hand, in this scheme, the dual-core characteristics can be used for task scheduling so that the operation of the proof program will not preempt the CPU core used by the key program to ensure the operation requirements of high real-time business, and greatly reduce the communication volume between the CPU core and the HSM core, thereby reducing the impact of the verification process on the performance of the first device.

[0244] It is understandable that the verification scheme described in the embodiment of the present application in conjunction with Figures 8 to 13 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 a multi-core system, the attacker may also use the multi-core concurrency characteristics to accelerate the calculation. In the embodiment of the present application, in a multi-core system, the challenge node can adjust the number of target parameters interacting with the proof node or the verification node, and the number of target address sequences generated, etc., based on the total number of CPU cores of the first device (such as the ECU CPU) to which the proof node belongs and the number of CPU cores allocated to the critical tasks, so as to run the proof program as fully as possible and verify the credibility of the target data on at least one CPU core that is not currently occupied by the critical task, so as to compensate for the multi-core concurrency vulnerability.

[0245] For example, let n represent the number of CPU cores in the first device, where n is an integer greater than or equal to 3. Assume that the task scheduler of the first device allocates k CPU cores to a critical program executing a critical task, where k is an integer greater than or equal to 1. Then, in S810, at time point 1, when the challenging node initiates a challenge to the proving node and the verification node, it may send nk random numbers as target parameters. In S821, RTOS1, through the task scheduler, may allocate nk target CPU cores to the nk proving nodes. In S822, the target function may generate nk target address sequences based on the nk target parameters. The proving node may calculate nk proof results based on the nk target address sequences, each of which is associated with nk time points. In S830, the proving node sends the nk proof results to the second device to which the verification node belongs. The verification node verifies the credibility of the target data of the first device to which the proving node belongs based on the nk proof results and the nk time points. The detailed implementation details are the same as those for the dual-core system described above. Please refer to the relevant description in conjunction with Figures 8-13 above and will not be repeated here.

[0246] The present application also provides a verification method, which can be implemented by the above-mentioned certification node and verification node in collaboration. As shown in FIG15 , the verification method can include the following steps:

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

[0248] S1520: The proving node obtains a first proving result based on the target data.

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

[0250] S1540: The verification node verifies the credibility of the target data based on the target parameters, the first proof result and the first moment.

[0251] The attestation node may run on at least one first resource unit, which is a resource unit included in a first device to which the attestation node belongs, and is configured to run at least a program. The at least one first resource unit runs programs other than critical programs of the first device, wherein the critical programs include at least programs for executing security tasks and / or programs for executing scheduling tasks.

[0252] When implementing the above S1510, in an optional implementation, the proof node can obtain the target parameter and generate the target address sequence based on the target parameter and the target function. The proof node can obtain the target parameter from the challenge node or the real-time operating system RTOS of the first device to which the proof node belongs. The challenge node is the node that triggers the verification of the credibility of the target data. The target parameter includes a random number, and the target function includes a pseudo-random generation function. In another optional implementation, the proof node can obtain the target address sequence from the RTOS of the first device to which the proof node belongs. The target address sequence is generated by the RTOS based on the target parameter and the target function. The target parameter includes a random number, and the target function includes a pseudo-random generation function. The detailed implementation process can be found in the relevant description above in conjunction with Figures 8 to 13, which will not be repeated here.

[0253] The target address sequence includes at least two addresses, each of which points to at least two different data blocks of the target data. When performing S1520, the proving node may employ a target algorithm to perform calculations on the at least two different data blocks of the target data in a first order to obtain the first proof result. During the calculations, the proving node may, on the one hand, split the data block pointed to by the first of the at least two addresses when the length of the data block pointed to by the first address exceeds a data length threshold. The proving node can then obtain the first proof result without the data block being split or the data block resulting from the splitting process. On the other hand, the proving node may also obtain a base address and, based on the base address and the values ​​of at least two addresses in the target address sequence, calculate the original value of the address pointing to the target data. This original value is used to read the target data. The detailed implementation process can be found above in conjunction with the relevant description of Figures 8-13 and will not be repeated here. It should be noted that in this embodiment of the present application, when a first address exists in the target address sequence, the number of first addresses is not limited to one.

[0254] Before implementing 1540 , the verification node may obtain the target parameters from a challenging node or an RTOS of a second device to which the verification node belongs. The challenging node is a node that triggers verification of the credibility of the target data.

[0255] When implementing 1540, in one example, the verification node may employ the same calculation method as the proof node to obtain a second proof result based on the target parameters, and verify the credibility of the target data based on the second proof result, the first proof result from the proof node, and the first moment associated with the first proof result. The verification node obtaining the second proof result based on the target parameters may include: the verification node obtaining a target address sequence based on the target parameters, wherein the target address sequence points to mirror data of the target data; and the verification node obtaining the second proof result based on the mirror data. The verification node obtaining the target address sequence based on the target parameters may include: the verification node generating the target address sequence based on the target parameters and a target function; or, the verification node obtaining the target address sequence based on the target parameters from the RTOS of the second device to which the verification node belongs, wherein the target address sequence is generated by the RTOS based on the target parameters and a target function. The target function may include a pseudo-random generator 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 proof result based on the mirror data may include: the verification node adopts the target algorithm to calculate the at least two data blocks contained in the mirror data in a first order to obtain the second proof result. In an optional embodiment, the at least two addresses point to the at least two data blocks contained in the mirror data, which may include: when the length of the data block pointed to by the first address of the at least two addresses is greater than the data length threshold, the data block pointed to by the first address is split. The detailed implementation process can be found in the relevant description above in conjunction with Figures 8 to 13, which will not be repeated here.

[0256] When implementing 1540, in another example, the verification node obtaining the second proof result based on the target parameter may include: the verification node using the target parameter as an index to obtain the second proof result from a first list, wherein the first list includes multiple parameters and proof results associated with each parameter, and the multiple parameters include the target parameter. In an optional implementation, the verification node may obtain tag information from the proof node; the verification node using the target parameter as an index to obtain the second proof result from the first list, including: the verification node using the target parameter and the tag information as indexes to obtain the second proof result from the first list. The detailed implementation process can be found in the above description in conjunction with Figures 8 to 13, which will not be repeated here.

[0257] It should be noted that, in an embodiment of the present application, the first device to which the proof 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 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 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 third device to which the challenge node belongs 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 based on the target parameter, the first proof result and the first moment, which may include: the verification node determines whether the target data meets a preset trust condition based on the target parameter, the first proof result and the first moment to verify the credibility of the target data; wherein the trust condition includes: the first proof result is the same as the second proof result obtained by the verification node based on the target parameter, and the first time interval associated with the first moment is within the time range allowed by the verification node. The detailed implementation process can be found in the above description in conjunction with Figures 8 to 13, which will not be repeated here.

[0258] An embodiment of the present application also provides a communication device for executing the method executed by the certification node or verification node in the above method embodiment. Relevant features can be found in the above method embodiment and will not be repeated here.

[0259] As shown in FIG16 , in one example, apparatus 1600 may correspond to a proof node and may include: an acquisition unit 1601 for acquiring a target address sequence, the target address sequence pointing to target data to be verified; a processing unit 1602 for obtaining a proof result based on the target data; and a transceiver unit 1603 for providing the proof result to the verification node, wherein the proof result is associated with a first moment in time, and the proof result and the first moment in time are used to verify the credibility of the target data. For specific implementation methods, please refer to the detailed description of the embodiments shown in FIG1 through FIG15 , which will not be repeated here.

[0260] As shown in Figure 17, in another example, the apparatus 1700 may correspond to a verification node and may include: an acquisition unit 1701 for acquiring a target parameter and a first proof result from the proving node, wherein the target parameter includes a random number; the first proof result is obtained by the proving node based on the target data to be verified, and the first proof result is associated with a first moment; and a determination unit 1702 for verifying the credibility of the target data based on the target parameter, the first proof result, and the first moment. For specific implementation methods, please refer to the detailed description of the embodiments shown in Figures 1 to 15, which will not be repeated here.

[0261] It should be noted that the division of units in the embodiments of the present application is schematic and is merely a logical functional division. In actual implementation, other division methods may be used. The functional units in the embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0262] 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 the contributing part or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) or a processor to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0263] In one possible implementation, an embodiment of the present application provides a computer-readable storage medium, which stores program code. When the program code runs on the computer, the computer executes the above method embodiment.

[0264] In a possible implementation, an embodiment of the present application provides a computer program product. When the computer program product is run on a computer, the computer is caused to execute the above method embodiment.

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

[0266] As shown in FIG18 , the apparatus 1800 includes at least one processor 1810 and a communication interface 1830. In an optional design, a memory 1820 may also be included.

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

[0268] In the apparatus as shown in FIG. 18 , the processor 1810 may transmit data through the communication interface 1830 when communicating with other devices.

[0269] 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.

[0270] An embodiment of the present application also relates 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.

[0271] In a possible implementation, the processor may be coupled to the memory through an interface.

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

[0273] For example, the memory may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. The non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache memory. By way of example and not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).

[0274] An embodiment of the present application further relates to a processor, which is used to call a computer program or computer instruction stored in a memory so that the processor executes the method described in any of the above embodiments.

[0275] For example, in the embodiment of the present application, the processor is an integrated circuit chip with signal processing capabilities. For example, the processor can be a field programmable gate array (FPGA), a general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC) or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component, a system on chip (SoC), a central processing unit (CPU), a network processor (NP), a microcontroller (MCU), a programmable logic device (PLD) or other integrated chip, which can implement or execute the various methods, steps and logic block diagrams disclosed in the embodiment of the present application. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. The steps of the method disclosed in conjunction with the embodiment of the present application can be directly embodied as a hardware decoding processor for execution, or can be executed by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium well-known in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. The storage medium is located in the memory, and the processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the above method.

[0276] It should be understood that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0277] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0278] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0279] 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. Thus, if these modifications and variations of the embodiments of the present application fall within the scope of the claims of the present application and their equivalents, the present application also intends to include such modifications and variations.

Claims

1. A verification method, characterized in that: include: The proving node obtains a target address sequence, wherein the target address sequence points to target data to be verified; The proving node obtains a proving result according to 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.

2. The method according to claim 1, characterized in that The certification node obtains the target address sequence, including: The certification node obtains target parameters; The proving node generates the target address sequence according to the target parameter and the target function; The target parameter includes a random number, and the target function includes a pseudo-random generation function.

3. The method according to claim 2, characterized in that The certification node obtains target parameters, including: The proving node obtains the target parameter from a challenging node or a real-time operating system RTOS of a first device to which the proving node belongs, wherein the challenging node is a node that triggers verification of the credibility of the target data.

4. The method according to claim 1, wherein The certification node obtains the target address sequence, including: The proof node obtains the target address sequence from the RTOS of the first device to which the proof node belongs, wherein the target address sequence is generated by the RTOS according to target parameters and a target function.

5. The method according to any one of claims 1 to 4, characterized in that The proof node runs on at least one first resource unit, which is a resource unit included in a first device to which the proof node belongs, and the resource unit is at least used to run a program.

6. The method according to claim 5, characterized in that The at least one first resource unit runs programs other than critical programs of the first device, where the critical programs include at least programs for executing security tasks and / or programs for executing scheduling tasks.

7. 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 included in the target data, and the proving node obtains a proof result based on the target data, including: The proof node adopts a target algorithm to calculate at least two data blocks included in the target data in a first order to obtain the proof result.

8. 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 included in the target data, and further includes: When the length of the data block pointed to by a first address among the at least two addresses is greater than a data length threshold, the data block pointed to by the first address is split.

9. The method according to any one of claims 1 to 8, characterized in that The method further comprises: The certification node obtains a base address; The proof node calculates an original value of the 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.

10. The method according to any one of claims 1 to 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 trusted hardware of 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.

11. The method according to any one of claims 1 to 10, characterized in that When the target data meets a preset trust condition, the credibility verification of the target data is passed; wherein, the trust condition includes: the proof result provided by the proof 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.

12. A verification method, characterized in that: include: The verification node obtains a target parameter, wherein the target parameter includes a random number; The verification node obtains a first proof result from the proving node, wherein the first proof result is obtained by the proving node based on target data to be verified, and the first proof result is associated with a 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.

13. The method according to claim 12, characterized in that The verification node obtains target parameters, including: The verification node obtains the target parameter from a challenging node or an RTOS of a second device to which the verification node belongs, wherein the challenging node is a node that triggers verification of the credibility of the target data.

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

15. The method according to claim 14, characterized in that The verification node obtains a second proof 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 proof result based on the mirror data.

16. The method according to claim 15, characterized in that The verification node obtains a target address sequence according to the target parameter, including: 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 RTOS of the second device to which the verification node belongs according to the target parameter, wherein the target address sequence is generated by the RTOS according to the target parameter and the target function. Wherein, the objective function includes a pseudo-random generation function.

17. The method according to claim 15 or 16, 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 included in the mirror data. The verification node obtains the second proof result according to the mirror data, including: The verification node uses a target algorithm to calculate at least two data blocks included in the mirror data in a first order to obtain the second proof result.

18. 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 a first address among the at least two addresses is greater than a data length threshold, the data block pointed to by the first address is split.

19. The method according to claim 14, wherein The verification node obtains a second proof 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, wherein the first list includes multiple parameters and proof results associated with each parameter, and the multiple parameters include the target parameter.

20. The method according to claim 19, characterized in that The method further comprises: The verification node obtains the marking information from the certification node; The verification node obtains the second proof result from the first list using the target parameter as an index, including: The verification node uses the target parameter and the tag information as indexes to obtain the second proof result from the first list.

21. The method according to any one of claims 12 to 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 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 second device is a trusted device.

22. 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 challenging node belongs are different devices, and the third device and the first device are different devices.

23. The method according to any one of claims 12 to 22, characterized in that The verification node verifies the credibility of the target data according to the target parameter, the first certification result, and the first time, including: The verification node determines whether the target data meets a preset trust condition based on the target parameters, the first proof result and the first moment to verify the credibility of the target data; wherein the trust condition includes: the first proof result is the same as the second proof result obtained by the verification node based on the target parameters, and the first time interval associated with the first moment is within the time range allowed by the verification node.

24. A device for proving a node, characterized in that include: an acquiring unit, configured to acquire a target address sequence, wherein the target address sequence points to target data to be verified; A processing unit, configured to obtain a certification result based on the target data; The transceiver unit is configured to provide the certification result to the verification node, 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.

25. A device for verifying a node, characterized in that: include: a transceiver unit, configured to obtain a target parameter and a first proof result from a proving node, wherein the target parameter includes a random number, the first proof result is obtained by the proving node based on target data, and the first proof result is associated with a first moment; A determination unit is used to verify the credibility of the target data based on the target parameter, the first certification result and the first moment.

26. A communication system, characterized in that: The invention comprises an apparatus for implementing the method according to any one of claims 1 to 11, and an apparatus for implementing the method according to any one of claims 12 to 23.

27. A chip system, characterized in that: The chip system comprises at least one processor and an interface circuit, wherein the processor is used to execute instructions and / or data interaction through the interface circuit, so that the chip system executes the method according to any one of claims 1 to 11, or executes the method according to any one of claims 12 to 23.

28. A vehicle, characterized in that: Includes the device as claimed in claim 24 or the chip system as claimed in claim 27, and / or, the device as claimed in claim 25 or the chip system as claimed in claim 27, or includes the communication system as claimed in claim 26.

29. A computer-readable storage medium, characterized in that The method comprises a program or an instruction. When the program or the instruction is executed, the method according to any one of claims 1 to 11 is executed, or the method according to any one of claims 12 to 23 is executed.

30. A computer program product, characterized in that When a computer reads and executes the computer program product, the computer is enabled to execute the method according to any one of claims 1 to 11, or execute the method according to any one of claims 12 to 23.

Images