Method and apparatus for proof

Abstract

Methods and apparatuses for demonstrating the integrity of a program are disclosed. A method may include: sending a first request to a second device for verifying the integrity of a program on the second device; receiving a first response from the second device, where the first response includes information about one or more tags collected during the execution of the program; and demonstrating the integrity of the program based on the first response and an expected response.

Description

Technical Field

[0001] Embodiments of the present disclosure generally relate to information technology, and more particularly, to attestation for the integrity of programs. Background Art

[0002] Electronic devices such as Internet of Things (IoT) devices, machine-to-machine (M2M) devices, and / or wireless sensor networks (WSNs) have a wide range of applications that can be used in various scenarios, such as industrial production, medical, home use, smart office, urban construction, and daily wear, medical emergency detection, volcanic monitoring, forest fire detection, scene reconstruction, event detection, video surveillance, traffic monitoring, driver assistance systems, advanced driver assistance systems (ADAS), unmanned aerial vehicle systems (UAS), autonomous vehicles, traffic monitoring, public safety, sensor-based information appliances used in smart homes, etc.

[0003] Electronic devices such as IoT devices, M2M devices, and / or sensors may store a large amount of private information of users or affect the operation of the entire system. For example, compromised nodes / devices may disrupt network operation, causing the entire network to crash in an infectious manner, resulting in the leakage of personal privacy, or making it report false information that may cause catastrophic consequences, etc.

[0004] There are many attacks against the normal operation of devices. For example, an attacker may potentially use compromised nodes (such as IoT devices and / or sensors) not only to steal other nodes but also as an entry point to disrupt the system to which the nodes report their data. For example, some related work on the security of Internet of Things devices and / or sensors focuses on protecting their underlying protocols or on trust and reputation management in the network. However, by exploiting existing software vulnerabilities, an adversary can easily steal high-reputation nodes without breaking their protocols.

[0005] Therefore, how to ensure the integrity (or correctness) of software running on various electronic devices such as IoT devices, M2M devices, and / or wireless sensor networks (WSNs) has become a security issue that needs to be solved. Summary of the Invention

[0006] This Summary of the Invention is provided to introduce a selection of concepts in a simplified form, which are further described below in the Detailed Description. This Summary of the Invention is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0007] According to a first aspect of the present disclosure, a method is provided. The method may include: sending a first request to a second device for verifying the integrity of a program on the second device; and receiving a first response from the second device, wherein the first response includes information about one or more tags collected during the execution of the program; and proving the integrity of the program based on the first response and an expected response.

[0008] According to a second aspect of the present disclosure, an apparatus is provided. The apparatus may include at least one processor, at least one memory including computer program code, the memory and the computer program code being configured to work together with the at least one processor to cause the apparatus to: send a first request to a second device for verifying the integrity of a program on the second device; and receive a first response from the second device, wherein the first response includes information about one or more tags collected during the execution of the program; and prove the integrity of the program based on the first response and an expected response.

[0009] According to a third aspect of the present disclosure, a computer program product is provided, which is embodied on a computer-readable distribution medium and includes program instructions that, when loaded into a computer, perform the following operations: send a first request to a second device for verifying the integrity of a program on the second device; and receive a first response from the second device, wherein the first response includes information about one or more tags collected during the execution of the program; and prove the integrity of the program based on the first response and an expected response.

[0010] According to a fourth aspect of the present disclosure, a method is provided. The method may include: receiving a first request from a first device for verifying the integrity of a program on a second device; and collecting one or more tags during the execution of the program; generating a first response including information about the one or more tags; and sending the first response to the first device.

[0011] According to a fifth aspect of the present disclosure, an apparatus is provided. The apparatus may include at least one processor, at least one memory including computer program code, the memory and the computer program code being configured to work together with the at least one processor to cause the apparatus to receive a first request from a first device for verifying the integrity of a program on a second device; and collect one or more tags during the execution of the program; generate a first response including information about the one or more tags; and send the first response to the first device.

[0012] According to a sixth aspect of the present disclosure, there is provided a computer program product embodied on a computer-readable distribution medium and including program instructions that, when loaded into a computer, perform the following operations: receiving a first request from a first device for verifying the integrity of a program on a second device; and collecting one or more tags during the running of the program; generating a first response including information about the one or more tags; and sending the first response to the first device.

[0013] These and other objects, features, and advantages of the present disclosure will become apparent from the following detailed description of exemplary embodiments in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 depicts tag categories according to an embodiment of the present disclosure;

[0015] Figure 2 is a flowchart depicting a method according to an embodiment of the present disclosure;

[0016] Figure 3 schematically shows pseudocode including various tags according to an embodiment of the present disclosure;

[0017] Figure 4 depicts a schematic system in which some embodiments of the present disclosure can be implemented;

[0018] Figure 5 is a flowchart depicting a method according to an embodiment of the present disclosure;

[0019] Figure 6 is a flowchart depicting a method according to another embodiment of the present disclosure;

[0020] Figure 7 is a flowchart depicting a method according to another embodiment of the present disclosure;

[0021] Figure 8 is a flowchart depicting a method according to another embodiment of the present disclosure;

[0022] Figure 9 shows a simplified block diagram of a device according to an embodiment of the present disclosure;

[0023] Figure 10 shows a simplified block diagram of a device according to an embodiment of the present disclosure;

[0024] Figure 11 shows a simplified block diagram of a device according to an embodiment of the present disclosure; and

[0025] Figure 12 shows a simplified block diagram of a device according to an embodiment of the present disclosure. Detailed implementation manners

[0026] Embodiments of the present disclosure are described in detail with reference to the accompanying drawings. It should be understood that these embodiments are discussed only for the purpose of enabling those skilled in the art to better understand and thus implement the present disclosure, rather than suggesting any limitation to the scope of the present disclosure. References throughout the specification to features, advantages, or similar language do not imply that all features and advantages that can be realized by the present disclosure should be in any single embodiment of the present disclosure or in any single embodiment of the present disclosure. On the contrary, the language referring to features and advantages should be understood as: a particular feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present disclosure. In addition, the described features, advantages, and characteristics of the present disclosure may be combined in any suitable manner in one or more embodiments. Those skilled in the relevant art will recognize that the present disclosure may be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be identified in certain embodiments that may not be present in all embodiments of the present disclosure.

[0027] As used herein, the term "communication network" refers to a wired or wireless network. For example, a wireless network may follow any suitable communication standard, such as New Radio (NR), Long Term Evolution (LTE), LTE-Advanced, Wideband Code Division Multiple Access (WCDMA), High Speed Packet Access (HSPA), and so on. In addition, the communication between a first device and a second node in a wireless communication network may be performed according to any suitable generation of communication protocols and / or any other protocol known or to be developed in the future, and the generations of communication protocols include, but are not limited to, the first generation (1G), the second generation (2G), 2.5G, 2.75G, the third generation (3G), the fourth generation (4G), 4.5G, and the fifth generation (5G) communication protocols.

[0028] As used herein, the terms "first", "second", etc. refer to different elements. Unless the context clearly indicates otherwise, the singular forms "a" and "an" are also intended to include the plural forms. As used herein, the terms "comprises", "comprising", "has", "having", "contains", and / or "including" specify the presence of the stated features, elements, and / or components, etc., but do not preclude the presence or addition of one or more other features, elements, components, and / or combinations thereof. The term "based on" should be understood as "at least partially based on". The terms "an embodiment" and "embodiments" should be understood as "at least one embodiment". The term "another embodiment" should be understood as "at least one other embodiment". Other definitions (explicit and implicit) may be included hereinafter.

[0029] As described above, there are many attacks against the normal operation of devices. To verify the software integrity on, for example, an untrusted platform and determine whether it has been misappropriated, several attestation techniques have been proposed, such as remote attestation. Remote attestation generally follows a challenge-response mechanism, which can be used by a trusted entity to verify the software integrity of an untrusted platform. For example, there is usually a trusted entity called the verifier that sends a challenge to another entity called the prover. The prover can generate a response based on the challenge and its existing running state. Finally, the verifier can determine the software integrity of the prover through the response and some prior knowledge.

[0030] Some remote attestation methods have been proposed. They can obtain attestation through software, hardware, or a combination of software and hardware. Some existing remote attestation schemes are based on static attestation. That is, only the integrity of the program is verified. However, the runtime properties of the program are ignored. Static attestation schemes can only verify the integrity of the program and lack supervision of the program's running state. Static attestation is difficult to resist certain runtime attacks, such as control-flow vulnerabilities and non-control data vulnerabilities.

[0031] In addition to some traditional attacks (such as replay, forgery, proxy, and collusion attacks), some new attack methods have been proposed, such as control-flow vulnerabilities and non-control data vulnerabilities. A commonly used control-flow vulnerability is stack overflow. The attacker can control the computer pointer to execute the target code. Return-Oriented Programming (ROP) is also a control-flow hijacking method. ROP searches the entire process space for suitable instruction sequences called "gadgets" of existing functions. Then, it links the gadgets together to achieve a malicious attack. Additionally, non-control data vulnerabilities can change the program's flow by changing the values of certain variables. The characteristic of this type of attack is to achieve the purpose of malicious attack by changing the running process of the existing program without changing the integrity of the program, because they do not require injecting new malicious code. Traditional static attestation methods lack the ability to resist such attacks.

[0032] In addition, there are many techniques that have been studied for mitigating runtime exploitation for resisting control-flow vulnerabilities and non-control data vulnerabilities, such as Data Execution Protection (DEP), stack cookies, Address Space Layout Randomization (ASLR), Control-Flow Integrity (CFI), and Code Pointer Integrity (CPI). However, there are still some flaws in these protection mechanisms, including for example 1) some existing control-flow proof schemes can only resist control-flow hijacking attacks. However, there is no effective defense mode against data-oriented attacks. 2) Some existing control-flow proof schemes design the control-flow graph (CFG) based on program slicing. However, program slicing can be a very complex operation, especially for some intricate structures; 3) Only the correctness of the control flow is verified. However, there is a lack of proof of memory integrity; 4) Some existing control-flow proof schemes cannot feedback the attack area; 5) The mitigation techniques for runtime exploitation require changing the programming language and / or changing the compiler and / or changing the machine code, and / or adding some other hardware beyond the tolerance range of some IoT devices, M2M devices, and / or sensors, 6) Some existing control-flow proof schemes cannot feedback a specific program execution process, but can only feedback results indicating whether an attack has occurred, etc. Therefore, it is more meaningful to resist these attacks through improved proofs.

[0033] To overcome at least one of the above problems or other problems, embodiments of the present disclosure propose a runtime proof scheme. It can record the control flow without a CFG. In other words, program slicing is not required. It can not only defend against control-flow vulnerabilities, but also resist data-oriented attacks. In addition, the proposed runtime proof scheme can verify the integrity of the program while ensuring the correctness of the control flow. Additionally, two localization algorithms are proposed, which can quickly locate the code area where a runtime attack occurs.

[0034] As described below, there may be some differences between the proposed runtime proof scheme of the embodiments of the present disclosure and the prior art as follows.

[0035] · Data-oriented proof. Some existing control-flow proof schemes can only resist control-flow hijacking attacks. However, there are no effective defenses against data-oriented attacks. The proposed runtime proof scheme can put some sensitive and important information into special tags and collect it during proof. In this way, the verifier can quickly determine whether the prover has suffered a non-control data attack during the operation process.

[0036] · Code integrity. Some existing proof schemes focus on the correctness of the control flow but ignore code integrity. The proposed runtime proof scheme can use static proof in addition to dynamic proof to prove the integrity of the entire program.

[0037] · Location algorithm. Some control-flow proof schemes only determine whether a node is misappropriated. However, they cannot feedback the attack area. The proposed runtime proof scheme can quickly locate the code area where a runtime attack occurs.

[0038] · New runtime proof mode. Some runtime proof schemes are based on program slicing to produce a CFG. However, program slicing can be a very complex operation, especially for some intricate structures. The proposed runtime proof scheme can utilize tags to measure the control flow, which is more flexible and easier to implement.

[0039] The proposed runtime proof scheme can include an offline phase and an online phase. In the offline phase, the verifier and the prover can obtain some basic information to prepare for the proof. For example, the prover can send the public key pk and the hash value h of its program code to the verifier. In addition, the verifier can insert at least one tag into the prover's program. The at least one tag can be divided into the following three categories.

[0040] · Ordinary tag. This type of tag can mark the flow of a normal program. In an embodiment, ordinary tags can be evenly inserted throughout the program. The denser the insertion, the more detailed the control flow is proven, but the greater the overhead. In another embodiment, at some important connection points, such as jump statements, ordinary tags can be inserted. As Figure 1 shown, an ordinary tag can be divided into two parts such as a tag bit and a tag name. For example, the starting binary digit "1" can be used as the tag bit. The remaining tags can be used as the tag name. Note that the format of the ordinary tag can adopt any suitable format.

[0041] · Data tag. This type of tag can be used to mark certain data, such as certain variables used by a statement. Data tags can disclose data-oriented attacks. Data tags can be inserted immediately after data initialization or the latest assignment. As Figure 1 shown, a data tag can be divided into three parts, such as a tag bit, a data name, and a data value. For example, the first two binary digits "00" can be used as the tag bit. The remaining parts are the data name and the data value. Note that the format of the data tag can adopt any suitable format.

[0042] · Iteration tag. This type of tag can be used to mark loop statements. As Figure 1 shown, an iteration tag can be divided into three parts, such as a tag bit, an iteration name, and an iteration count. For example, the first two binary digits "01" can be used as the tag bit. The remaining parts can be used as the iteration name and the iteration count. The iteration count can indicate the number of loops. Note that the format of the iteration tag can adopt any suitable format.

[0043] The online phase can be a mix of runtime proofs and static proofs. Runtime proofs can be used to detect control-flow vulnerabilities and data-oriented attacks. Static proofs can be used to ensure the integrity of the program's binary code.

[0044] Figure 2 is a flowchart depicting a method according to an embodiment of the present disclosure. As Figure 2 shown, the verifier can send a challenge to the prover, which can include parameters such as an input i, an indicator of a program region r to be proven, and a random number n at the start of the proof. The input i can be one or more parameters of the program. The random number n can ensure the freshness of the response from the prover. The program region r can be used to locate the code region where a runtime attack occurs in a localization algorithm, which will be described in detail below. In one embodiment, the program region r is the entire code region.

[0045] When the prover receives the challenge, it can start a proof program, which can include runtime proofs and static proofs. The runtime proofs can collect tags generated during the execution of the program. Figure 3 Schematically shows pseudocode including various tags according to an embodiment of the present disclosure. As Figure 3 shown, the prover can compute a runtime response A accumulated from the hash values of each tag, such as where represents the exclusive-or (XOR) operation. Additionally, the static proof can compute a hash value B of the program's code. Finally, the prover can send back A, B, and a digital signature S = sign(A||B; sk), where "||" represents the logical-or operation.

[0046] The verifier can verify the signature using pk after receiving the response. Then, A can be used to check the control flow and data flow of the prover's program. B can be used to estimate the integrity of the prover's program.

[0047] Once the verifier determines that the prover has been compromised, the verifier can utilize a localization algorithm to locate the code region where the runtime attack occurred. The verifier can use any suitable localization algorithm. In one embodiment, the verifier can use the following fast localization algorithm and / or global localization algorithm.

[0048] The fast localization algorithm can quickly find the first compromised region. As shown in Algorithm 1, l indicates the length of the program's code, t f indicates the first compromised region, l max indicates the entire program, and m indicates the number of tags included in the code region. Algorithm 1 can quickly find the attacked region through iteration and binary search.

[0049]

[0050] The quick location algorithm can find the first misappropriated area. However, there may be more than one code area under attack. The global location algorithm can find all the code areas where runtime attacks occur based on the quick location algorithm. As shown in Algorithm 2, l indicates the length of the code, T indicates all the misappropriated code areas, l max indicates the entire program, and m indicates the number of labels included in the code area.

[0051]

[0052] Figure 4 FIG. illustrates a schematic system in which some embodiments of the present disclosure can be implemented. As Figure 4 shown, the system 400 may include one or more second devices 404 (i.e., prover), and each of the second devices 404 in the second device 404 may be operably connected to the first device 402 (i.e., verifier) via a communication network 406. However, it should be understood that the first device 402 and the second device 404 shown and described hereinafter are merely illustrative of the devices that can benefit from the embodiments of the present disclosure, and thus should not be regarded as limiting the scope of the present disclosure. Although the first device 402 and the second device 404 are shown for purposes of example and will be described hereinafter, other types of devices can readily adopt the embodiments of the present disclosure.

[0053] The first device 402 can be any kind of computing device, including but not limited to user equipment, mobile computer, desktop computer, laptop computer, mobile phone, smart phone, tablet computer, server, cloud computer, virtual server, computing device, distributed system, base station (BS), access point (AP), multi-cell / multicast coordination entity (MCE), controller, and / or any other type of electronic device. The first device 402 can run any kind of operating system, including but not limited to Windows, Linux, UNIX, Android, iOS, and their variants.

[0054] The second device 404 can be any kind of computing device, including but not limited to IoT devices, M2M devices, portable digital assistants (PDAs), media players, video recorders, mobile phones, global positioning system (GPS) devices, user equipment, mobile computers, desktop computers, portable computers, mobile phones, smart phones, tablets, servers, cloud computers, virtual servers, computing devices, distributed systems, video surveillance devices (such as surveillance cameras), human-machine interaction (HMI), ADAS, UAS, cameras, glasses / goggles, smart sticks, smart watches, necklaces or other wearable devices, sensors used in various systems such as intelligent transportation systems (ITS), police information systems, etc., gaming devices, devices for assisting disabled persons, and / or any other type of electronic device. The second device 404 can run any kind of operating system, including but not limited to Windows, Linux, UNIX, Android, iOS and their variants. In addition, the second device 404 of at least one example embodiment does not have to be the entire device, but in other example embodiments can be a component or group of components of the device.

[0055] The second device 404 can provide a trusted execution environment (TEE), which allows the creation of an isolated area within a normal untrusted operating system. The trusted execution environment can be configured to perform functions related to attestation. For example, the trusted execution environment can be provided by an ARM TrustZone with a trusted environment or other types of TEE-enabled processors.

[0056] As a specific example, in an Internet of Things scenario, the second device 404 can be an IoT device, and a machine or other device that represents and performs monitoring, sensing, and / or measurement, etc. and transmits the results of such monitoring, sensing, and / or measurement, etc. to another terminal device and / or network device. In this case, the second device 404 can be an M2M device, which can be referred to as a machine type communication (MTC) device in the context of the 3rd Generation Partnership Project (3GPP).

[0057] As another specific example, the second device 404 can be a UE that implements the 3GPP narrowband Internet of Things (NB-IoT) standard. Specific examples of such machines or devices are sensors, metering devices such as power meters, industrial machinery, or household or personal appliances (such as refrigerators, TVs), personal wearable devices such as watches, and so on. In other scenarios, the second device 404 can represent a vehicle or other device, such as a medical instrument that can monitor, sense, and / or report on its working state, etc. or has other functions associated with its operation.

[0058] The communication between the first device 402 and the second device 404 can be secure communication. For example, by applying secure communication protocols (such as, Transport Layer Security (TLS), Secure Sockets Layer (SSL), OpenSSL, TLS-based Hypertext Transfer Protocol (HTTP), SSL-based HTTP, and HTTP Secure (HTTPS), etc.), a secure channel can be established between every two parties in the system 400.

[0059] Figure 5 is a flowchart depicting a method according to an embodiment of the present disclosure. The method 500 can be executed at a device such as Figure 4 the first device 402. Thus, the device can provide components for completing various parts of the method 500 and components for combining with other components to complete other processes. For some identical or similar parts that have been described for Figures 1 - 4 conciseness, the description of these parts is omitted herein.

[0060] As Figure 5 shown, the method 500 can start at block 502, where the first device can send a first request to the second device for verifying the integrity of a program on the second device. The second device can be any suitable device, such as the Figure 4 second device 404 as described above. The program can be any suitable program that can run on the second device. The first request can be triggered in various ways. For example, the first device can periodically perform integrity verification of the program on the second device, or the second device can request the first device to perform integrity verification of the program, or the first device can perform integrity verification when receiving a security event, or another entity (such as a network device providing services for the second device) requests the first device to perform integrity verification.

[0061] The first device can know in advance the correct response to the first request. Therefore, the first device challenges the second device to confirm that it is in a valid expected state. As described in the above embodiments, one or more tags can be inserted into the code of the program. For example, one or more tags can be inserted into the code of the program by the first device or another entity. When the insertion operation is performed by another entity, the second device can know how one or more tags are inserted into the code of the program.

[0062] For example, depending on the type of the tag, one or more tags can be inserted into any suitable location in the code of the program. For example, ordinary tags can be evenly inserted throughout the program. In another embodiment, at some important connection points, such as jump statements, ordinary tags can be inserted. Data tags can be inserted immediately after data initialization or the latest assignment. Iteration tags can be inserted after loop statements.

[0063] The first request can be any suitable message such as a challenge. The first request can include any suitable parameters or no parameters. When the first request contains no parameters, it may mean a default request known to both the first device and the second device. For example, when the second device receives the default request, the second device can initiate a proof procedure according to the default request. When the first request contains one or more parameters, the second device can initiate a proof procedure by using the one or more parameters.

[0064] In one embodiment, the first request can include at least one of the following: input parameters of the program, indicators of one or more code regions of the program to be proven, and a random number, etc. The input parameters of the program can be any suitable parameters that can be input into the program, such as configuration parameters, test parameters, etc. The input parameters of the program can control the operation of the program. For example, the input parameters may result in the following: specific program statement(s) being executed, variables being set to specific values, loop statements being executed a specific number of times, etc. The indicator can be an index of a code region of the program. For example, the program can be divided into one or more code regions according to one or more labels. As an example, the code between two adjacent labels can be defined as a code region. Note that the code regions of the program can be defined in any other suitable way known to the first device and the second device.

[0065] In one embodiment, one or more labels can include at least one of the following: ordinary labels for marking the flow of the program, data labels for marking data parameters, and iteration labels for marking loop statements, etc.

[0066] At block 504, the first device can receive a first response from the second device, where the first response can include information about one or more labels collected during the execution of the program. For example, the second device can initiate a proof procedure according to the first request. The proof procedure can be executed in the TEE and can include runtime proof. The runtime proof can collect the labels generated during the execution of the program. For example, during the execution of the program, if certain program statements containing one or more labels are executed, the program can generate or output one or more labels.

[0067] The information about one or more labels can have various forms. In one embodiment, the information can include at least one of the following: actual labels, logical calculation results of one or more labels, and logical calculation results of one or more labels and other parameters such as random numbers, etc. In one embodiment, the logical calculation can be an exclusive OR (XOR) operation.

[0068] The proof procedure may further include a static proof. The static proof may calculate a hash value of the code of the program. The code of the program may be source code, binary code, or any other suitable type of code. In one embodiment, the first response may further include the hash value of the code of the program.

[0069] In one embodiment, the first response further includes a digital signature of the second device. The digital signature may be generated by using any suitable digital signature algorithm.

[0070] In block 506, the first device may prove the integrity of the program based on the first response and the expected response. For example, the first device may first verify the digital signature. If the digital signature is valid, the first device may compare the received first response with the expected response or the correct response to check if they match each other. If the received first response matches the expected response or the correct response, the first device may prove that the program has not been attacked. Otherwise, the first device may prove that the program has been attacked. For example, if the information about one or more tags matches the expected information about one or more tags, the first device may prove that the program has not been attacked.

[0071] In one embodiment, if the first response is not received or there is no response from the second device within a predetermined period of time, the first device may determine that the program fails the runtime proof.

[0072] Figure 6 is a flowchart depicting a method according to an embodiment of the present disclosure. The method 600 may be executed at a device such as Figure 4 the first device 402. Thus, the device may provide components for completing various parts of the method 600 and components for combining with other parts to complete other processes. For some identical or similar parts that have been described with respect to Figures 1 - 7 For the sake of brevity, the description of these parts is omitted herein.

[0073] In block 602, the first device may insert one or more tags into the code of the program on the second device. For example, the first device may obtain the code of the program and insert one or more tags into the code of the program. As described above, one or more tags may be inserted into any suitable location in the code of the program, for example, according to the type of the tags.

[0074] At block 604, the first device may send a first request for verifying the integrity of the program on the second device. Block 604 is similar to block 502, and for the sake of brevity, its description is omitted herein.

[0075] At block 606, the first device may determine an expected response based on the first request and the program. For example, the first device may run the program itself based on the first request and then obtain the expected response. As another example, the first device may analyze the program based on the first request and then obtain the expected response.

[0076] At block 608, the first device may receive a first response from the second device, where the first response includes information related to one or more tags collected during the execution of the program. Block 608 is similar to block 504, and for the sake of brevity, its description is omitted here.

[0077] At block 610, the first device may prove the integrity of the program based on the first response and the expected response. Block 610 is similar to block 506, and for the sake of brevity, its description is omitted here.

[0078] At block 612, when the program fails the runtime proof, the first device may send a second request to the second device to obtain information related to at least a portion of one or more tags. At least a portion of the one or more tags may be determined using various methods. For example, the one or more tags may be grouped into any suitable number of portions. Alternatively, the one or more tags may first be grouped into two portions, and then each of the two portions may be further grouped into two portions, and so on. In one embodiment, at least a portion of the one or more tags may be determined based on a binary search algorithm as shown in the above fast localization algorithm and global localization algorithm. Each portion may be assigned an index.

[0079] At block 614, the first device may receive a second response from the second device, where the second response includes information related to at least a portion of the one or more tags. In one embodiment, the information related to at least a portion of the one or more tags may include the logical calculation result of at least a portion of the one or more tags. The logical calculation may be any suitable logical calculation. In one embodiment, the logical calculation is an exclusive OR (XOR) operation.

[0080] At block 616, the first device may compare the received information with the corresponding expected information. For example, if the information includes the logical calculation result of tags 1 and 2, the first device may compare the received logical calculation result with the corresponding expected logical calculation result of tags 1 and 2.

[0081] At block 618, the first device may locate the attacked area of the program based on the comparison result. For example, if the logical calculation result of tags 1 and 2 does not match the expected logical calculation result of tags 1 and 2, the first device may determine that the code area related to tags 1 and 2 may be attacked.

[0082] The frames 612, 614, 616, and 618 can implement the above-mentioned fast positioning algorithm or global positioning algorithm.

[0083] Figure 7 is a flowchart depicting a method according to an embodiment of the present disclosure. The method 700 can be executed at a device such as Figure 4 a second device 404. In this way, the device can provide components for completing various parts of the method 700 and components for combining with other components to complete other processes. For some identical or similar parts that have been described for Figures 1 - 6 the sake of brevity, the description of these parts is omitted here.

[0084] At block 702, the second device 404 can receive a first request from the first device for verifying the integrity of a program on the second device. The first device can be any suitable device, such as the first device 402 described above. The program can be any suitable program that can run on the second device. The first request can be triggered in various ways as described above.

[0085] As described in the above embodiments, one or more tags can be inserted into the code of the program. For example, one or more tags can be inserted into the code of the program by the first device or another entity. One or more tags can be inserted into any suitable position in the code of the program, for example, according to the type of the tag. The second device may or may not know how the tags are inserted into the code of the program.

[0086] The first request can be any appropriate message, such as a challenge. The first request can contain any suitable parameters or no parameters. When the first request contains no parameters, it can mean a default request. For example, when the second device receives a default request, the second device can start a proof program according to the default request. When the first request contains one or more parameters, the second device can start a proof program by using the one or more parameters.

[0087] In one embodiment, as described above, the first request can include at least one of the following: input parameters of the program, indicators of one or more code regions to be proved by the program, and a random number. In one embodiment, one or more tags can include at least one of the following: for example, ordinary tags for marking the flow of the program, data tags for marking data parameters, and iteration tags for marking loop statements.

[0088] At block 704, the second device may collect one or more tags during the execution of a program. For example, the second device may initiate a proof program in accordance with a first request. The proof program may be executed within a TEE and may include runtime proof. The runtime proof may collect tags generated during the execution of the program. For example, during the execution of the program, if some program statements containing tags are executed, the program may generate or output the tag. The proof program may further include static proof. The static proof may compute a hash value of the program code. The code of the program may be source code, binary code, or any other suitable type of code. In one embodiment, the first response may further include the hash value of the code of the program.

[0089] At block 706, the second device may generate a first response that includes information about the one or more tags. The information about the one or more tags may have various forms. In one embodiment, the information may include at least one of the following: the actual tags, the logical calculation results of the one or more tags, the logical calculation results of the one or more tags and other parameters such as random numbers, etc. The logical calculation is an XOR operation.

[0090] In one embodiment, the first response further includes a digital signature of the second device. The digital signature may be generated by using any suitable digital signature algorithm.

[0091] At block 708, the second device may send the first response to the first device.

[0092] Figure 8 is a flowchart depicting a method according to an embodiment of the present disclosure. Method 800 may be executed at a device such as Figure 4 the second device 404. As such, the device may provide means for performing the various parts of method 800 and means for combining with other components to perform other processes. For some parts that have been described as being the same or similar with respect to Figures 1 - 7 for the sake of brevity, the description of these parts is omitted herein. Blocks 802, 804, 806, and 808 are similar to blocks 702, 704, 706, and 708, and their descriptions are omitted herein for brevity.

[0093] At block 810, the second device may receive a second request from the first device, the second request being for obtaining information related to at least a portion of one or more tags. For example, when a program fails runtime attestation, the first device may send a second request to the second device for obtaining information related to at least a portion of one or more tags. At least a portion of the one or more tags may be determined by using various means. For example, the one or more tags may be grouped into any suitable number of portions. Alternatively, the one or more tags may first be grouped into two portions, and then each of the two portions may be further grouped into two portions, and so on. In one embodiment, at least a portion of the one or more tags may be determined based on a binary search algorithm as shown in the above quick location algorithm and global location algorithm. Each portion may be assigned an index.

[0094] At block 812, the second device may generate a second response that includes information related to at least a portion of the one or more tags. In one embodiment, the information related to at least a portion of the one or more tags may include a logical calculation result of at least a portion of the one or more tags. The logical calculation may be any suitable logical calculation. In one embodiment, the logical calculation is an exclusive OR (XOR) operation.

[0095] At block 814, the second device may send the second response to the first device.

[0096] In one embodiment, method 700 and / or 800 is executed in a trusted execution environment, and the one or more tags collected are stored in the trusted execution environment.

[0097] Figure 9 A simplified block diagram of a device according to an embodiment of the present disclosure is shown. Device 900 may be implemented as the first device or its module as shown in Figure 4 As shown in Figure 9 Device 900 includes a processor 904, a memory 905, and a transceiver 901 operably communicating with the processor 904. The transceiver 901 includes at least one transmitter 902 and at least one receiver 903. Although only one processor is shown in Figure 9 , the processor 904 may include multiple processors or multi-core processors (plural). Additionally, the processor 904 may also include a cache to facilitate processing operations. For some of the same or similar parts that have been described for Figures 1 - 8 , for the sake of brevity, the description of these parts is omitted here.

[0098] Computer-executable instructions can be loaded into the memory 905 and, when executed by the processor 904, can cause the apparatus 900 to implement the above method. In particular, the computer-executable instructions can cause the apparatus 900 to send a first request to a second device for verifying the integrity of a program on the second device; receive a first response from the second device, where the first response includes information about one or more tags collected during the execution of the program; and prove the integrity of the program based on the first response and an expected response.

[0099] In one embodiment, the computer-executable instructions can cause the apparatus 900 to insert one or more tags into the code of the program.

[0100] In one embodiment, the computer-executable instructions can cause the apparatus 900 to determine an expected response based on the first request and the program.

[0101] In one embodiment, if the first response is not received within a predetermined period of time or there is no response from the second device, the computer-executable instructions can cause the apparatus 900 to determine that the program fails the integrity verification.

[0102] In one embodiment, when the program fails the runtime proof, the computer-executable instructions can cause the apparatus 900 to send a second request to the second device for obtaining information related to at least a portion of one or more tags; receive a second response from the second device, where the second response includes information related to at least a portion of one or more tags; compare the received information with corresponding expected information; and locate the attacked area of the program based on the comparison result.

[0103] In one embodiment, at least a portion of one or more tags is determined based on a binary search algorithm.

[0104] In one embodiment, the information about one or more tags includes the logical calculation result of one or more tags, and the information related to at least a portion of one or more tags includes the logical calculation result of at least a portion of one or more tags.

[0105] In one embodiment, the logical calculation is an exclusive OR operation.

[0106] In one embodiment, the first response further includes the hash value of the code of the program.

[0107] In one embodiment, the first response further includes the digital signature of the second device.

[0108] In one embodiment, one or more tags include at least one of the following: a normal tag, a data tag, and an iterative tag.

[0109] In one embodiment, the first request includes at least one of the following: input parameters of a program, an indicator of one or more code regions of the program to be proven, and a random number.

[0110] Figure 10 FIG. shows a simplified block diagram of a device according to an embodiment of the present disclosure. The device 1000 may be implemented as a second device or a module thereof as shown in Figure 4 shown. As shown in Figure 10 FIG., the device 1000 includes a processor 1004, a memory 1005, and a transceiver 1001 operably communicating with the processor 1004. The transceiver 1001 includes at least one transmitter 1002 and at least one receiver 1003. Although only one processor is shown in Figure 10 , the processor 1004 may include multiple processors or multi-core processors (plural). Additionally, the processor 1004 may further include a cache to facilitate processing operations. For some of the same or similar parts that have been described for Figures 1 - 8 , the description of these parts is omitted here for the sake of brevity.

[0111] Computer-executable instructions may be loaded into the memory 1005 and, when executed by the processor 1004, cause the device 1000 to implement the above-described method. In particular, the computer-executable instructions may cause the device 1000 to receive a first request from a first device for verifying the integrity of a program on a second device; collect one or more tags during the execution of the program; generate a first response including information about the one or more tags; and send the first response to the first device.

[0112] In one embodiment, one or more tags are inserted into the code of the program.

[0113] In one embodiment, the computer-executable instructions may cause the device 1000 to receive a second request from the first device for obtaining information related to at least a portion of the one or more tags; generate a second response including information related to at least a portion of the one or more tags; and send the second response to the first device.

[0114] In one embodiment, at least a portion of the one or more tags is determined based on a binary search algorithm.

[0115] In one embodiment, the information about the one or more tags includes a logical calculation result of the one or more tags, and the information related to at least a portion of the one or more tags includes a logical calculation result of at least a portion of the one or more tags.

[0116] In one embodiment, the logical calculation is an exclusive OR operation.

[0117] In one embodiment, the first response further includes a hash value of the code of the program.

[0118] In one embodiment, the first response further includes a digital signature of the second device.

[0119] In one embodiment, one or more tags include at least one of the following: a normal tag, a data tag, and an iterative tag.

[0120] In one embodiment, the first request includes at least one of the following: an input parameter of the program, an indicator of one or more code regions of the program to be proven, and a random number.

[0121] In one embodiment, the device includes a trusted execution environment, and the one or more collected tags are stored in the trusted execution environment.

[0122] Figure 11 A simplified block diagram of a device according to an embodiment of the present disclosure is shown. The device 1100 may be implemented as the first device or its module as Figure 4 shown. As Figure 11 shown, the device 1100 includes: a sending module 1102, configured to send a first request to a second device for verifying the integrity of a program on the second device; a receiving module 1104, configured to receive a first response from the second device, where the first response includes information related to one or more tags collected during the running of the program; a proving module 1106, configured to prove the integrity of the program based on the first response and an expected response.

[0123] In one embodiment, the device 1100 further includes: an inserting module 1110, configured to insert one or more tags into the code of the program.

[0124] In one embodiment, the device 1100 further includes: a determining module 1108, configured to determine an expected response based on the first request and the program.

[0125] In one embodiment, the proving module 1106 is further configured to: if the first response is not received within a predetermined time period or there is no response from the second device, prove that it is determined that the program fails the integrity verification.

[0126] In one embodiment, the sending module 1102 may send a second request to a second device, where the second request is used to obtain information related to at least a part of one or more tags. The receiving module 1104 may receive a second response from the second device, where the second response includes information related to at least a part of one or more tags. The apparatus may further include: a comparison module 1112, configured to compare the received information with corresponding expected information; and a positioning module 1114, configured to locate an attacked area of the program according to the comparison result.

[0127] Figure 12 FIG. shows a simplified block diagram of an apparatus according to an embodiment of the present disclosure. The apparatus 1200 may be implemented as the second device or its module as shown in Figure 4 shown. As shown in Figure 12 FIG., the apparatus 1200 includes: a receiving module 1202, configured to receive a first request from a first device for verifying the integrity of a program on the second device; a collecting module 1204, configured to collect one or more tags during the running of the program; a generating module 1206, configured to generate a first response including information about one or more tags; and a sending module 1208, configured to send the first response to the first device.

[0128] In one embodiment, the receiving module 1202 is further configured to receive a second request from the first device, where the second request is used to obtain information related to at least a part of one or more tags; the generating module 1206 is further configured to generate a second response, where the second response includes information related to at least a part of one or more tags; and the sending module 1208 is further configured to send the second response to the first device.

[0129] In one embodiment, the apparatus 1200 includes a trusted execution environment, and the one or more collected tags are stored in the trusted execution environment.

[0130] Embodiments of the present disclosure may provide the following advantages. Embodiments of the present disclosure can resist data-oriented attacks. By means of a combination of dynamic proof and static proof, embodiments of the present disclosure can not only prove the control flow and data flow of the prover, but also estimate the integrity of the entire program. Embodiments of the present disclosure can quickly locate the code area where a runtime attack occurs. Embodiments of the present disclosure do not require program segmentation. Embodiments of the present disclosure use tags to measure the control flow, which is more flexible and easier to implement.

[0131] Additionally, one aspect of the present disclosure can utilize software running on a computing device. Such an implementation can employ, for example, a processor, a memory, and an input / output interface such as formed by a display and a keyboard. As used herein, the term "processor" is intended to include any processing device, such as a processing device including a CPU (Central Processing Unit) and / or other forms of processing circuitry. Additionally, the term "processor" can refer to more than one individual processor. The term "memory" is intended to include a memory associated with the processor or CPU, for example, random access memory (RAM), read-only memory (ROM), fixed memory devices (such as hard disk drives), removable storage devices (such as floppy disks), flash memory, etc. The processor, the memory, and the input / output interface such as a display and a keyboard can be interconnected, for example, via a bus that is part of the data processing unit. Appropriate interconnections (such as via a bus) can also be provided to a network interface (such as a network card) and a media interface. The network interface can be provided for interfacing with a computer network, and the media interface (such as a floppy disk or CD-ROM drive) can be provided for interfacing with a media.

[0132] Accordingly, computer software including instructions or code for performing the methods of the present disclosure as described herein can be stored in an associated storage device (such as ROM, fixed or removable memory), and when ready for use, be loaded in part or in whole (such as loaded into RAM) and implemented by the CPU. Such software can include, but is not limited to, firmware, resident software, microcode, etc.

[0133] As noted, aspects of the present disclosure can take the form of a computer program product embodied in a computer-readable medium having computer-readable program code embodied thereon. Moreover, any combination of computer-readable media can be utilized. The computer-readable media can be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium can be, for example but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer-readable storage medium would include the following: an electrical connection having one or more wires, a portable computer floppy disk, a hard disk, a RAM, a ROM, an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium can be any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.

[0134] Computer program code for performing operations in accordance with aspects of the present disclosure may be written in any combination of at least one programming language, including object-oriented programming languages such as Java, Smalltalk, C++, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer, or entirely on the remote computer or server.

[0135] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagram may represent a module, segment, or portion of code, which includes at least one executable instruction for implementing the specified logical function. It should also be noted that, in some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, depending on the functionality involved, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order. It should also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, can be implemented by a system based on dedicated hardware for performing the specified functions or actions, or by a combination of dedicated hardware and computer instructions.

[0136] In any case, it should be understood that the components shown in the present disclosure may be implemented in various forms of hardware, software, or a combination thereof, such as, for example, an application specific integrated circuit (ASIC), functional circuitry, a suitably programmed general purpose digital computer with associated memory, etc. Given the teachings of the present disclosure provided herein, one of ordinary skill in the relevant art will be able to conceive of other implementations of the components of the present disclosure.

[0137] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the present disclosure. As used herein, unless the context clearly dictates otherwise, the singular forms "a", "an", and "the" are also intended to include the plural forms. It will be understood that although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, without departing from the scope of the example embodiments, a first element may be referred to as a second element, and similarly, a second element may be referred to as a first element. It will be further understood that when the terms "comprises", "comprising", and / or "includes" are used in this specification, they specify the presence of the stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of another feature, integer, step, operation, element, component, and / or group thereof.

[0138] Descriptions of various embodiments have been given for purposes of illustration, but these descriptions are not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be obvious to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments.

Claims

1. A method implemented at a first device, comprising: sending a first request to a second device for verifying the integrity of a program on the second device; receiving a first response from the second device, wherein the first response includes information about one or more tags collected during the execution of the program; proving the integrity of the program based on the first response and an expected response, and when the program fails the runtime proof, sending a second request to the second device for obtaining information related to at least one of the one or more tags; receiving a second response from the second device, the second response including the information related to the at least one of the one or more tags; comparing the received information with corresponding expected information; and locating an attacked area of the program based on the comparison result.

2. The method according to claim 1, further comprising: inserting the one or more tags into the code of the program.

3. The method according to claim 1, further comprising: determining the expected response based on the first request and the program.

4. The method according to claim 1, wherein, proving the integrity of the program based on the first response and an expected response includes: if the first response is not received or there is no response from the second device within a predetermined time period, determining that the program fails the runtime proof.

5. The method according to claim 1, wherein, at least one of the one or more tags is determined based on a binary search algorithm.

6. The method according to claim 1, wherein, the information about the one or more tags includes a logical calculation result of the one or more tags, and the information related to at least one of the one or more tags includes: a logical calculation result of at least one of the one or more tags.

7. The method according to claim 6, wherein, the logical calculation is an exclusive OR operation.

8. The method according to any one of claims 1 to 7, wherein, the first response further includes a hash value of the code of the program.

9. The method according to any one of claims 1 to 7, wherein, the first response further includes a digital signature of the second device.

10. The method according to any one of claims 1 to 7, wherein, the one or more tags include at least one of the following: a normal tag, a data tag, and an iteration tag.

11. The method according to any one of claims 1 to 7, wherein, the first request includes at least one of the following: an input parameter of the program, an indicator of one or more code regions of the program to be proved, and a random number.

12. A method implemented at a second device, comprising: receiving a first request from a first device for verifying the integrity of a program on the second device; collecting one or more tags during the execution of the program; generating a first response including information about the one or more tags; sending the first response to the first device; Receive a second request from the first device for obtaining information related to at least one of the one or more tags; Generate a second response, the second response including the information related to the at least one of the one or more tags; and Send the second response to the first device.

13. The method according to claim 12, wherein, The one or more tags are inserted into the code of the program.

14. The method according to claim 12, wherein, At least one of the one or more tags is determined based on a binary search algorithm.

15. The method according to claim 12, wherein, The information about the one or more tags includes the logical calculation result of the one or more tags, and the information related to the at least one of the one or more tags includes: the logical calculation result of the at least one of the one or more tags.

16. The method according to claim 15, wherein, The logical calculation is an exclusive - or operation.

17. The method according to any one of claims 12 to 16, wherein, The first response further includes the hash value of the code of the program.

18. The method according to any one of claims 12 to 16, wherein, The first response further includes the digital signature of the second device.

19. The method according to any one of claims 12 to 16, wherein, The one or more tags include at least one of the following: ordinary tags, data tags, and iterative tags.

20. The method according to any one of claims 12 to 16, wherein, The first request includes at least one of the following: the input parameters of the program, an indicator of one or more code regions of the program to be proven, and a random number.

21. The method according to any one of claims 12 to 16, wherein, The method is executed in a trusted execution environment, and the one or more tags collected are stored in the trusted execution environment.

22. An apparatus at a first device, comprising: At least one processor; At least one memory, which includes computer program code, the memory and the computer program code being configured to work with the at least one processor to cause the apparatus to: Send a first request to a second device for verifying the integrity of a program on the second device; Receive a first response from the second device, where the first response includes information about one or more tags collected during the running of the program; Prove the integrity of the program based on the first response and an expected response, and When the program fails the runtime proof, Send a second request to the second device for obtaining information related to at least one of the one or more tags; Receive a second response from the second device, the second response including the information related to the at least one of the one or more tags; Compare the received information with the corresponding expected information; and Locate the attacked area of the program based on the comparison result.

23. The apparatus according to claim 22, wherein, the memory and the computer program code are configured to work with the at least one processor to cause the apparatus to perform the method according to any one of claims 2 to 11.

24. An apparatus at a second device, comprising: at least one processor; at least one memory including computer program code, the memory and the computer program code being configured to work with the at least one processor to cause the apparatus to: receive a first request from a first device for verifying the integrity of a program on the second device; collect one or more tags during the execution of the program; generate a first response including information about the one or more tags; send the first response to the first device; receive a second request from the first device for obtaining information related to at least one of the one or more tags; generate a second response, the second response including the information related to the at least one of the one or more tags; and send the second response to the first device.

25. The apparatus according to claim 24, wherein, the memory and the computer program code are configured to work with the at least one processor to cause the apparatus to perform the method according to any one of claims 13 to 21.

26. A computer program product comprising instructions which, when executed by at least one processor, cause the at least one processor to perform the method according to any one of claims 1 to 11.

27. A computer program product comprising instructions which, when executed by at least one processor, cause the at least one processor to perform the method according to any one of claims 12 to 21.

Images