Multi-file control flow remote proving method oriented to Internet of Things equipment

Abstract

The invention provides a multi-file control flow remote attestation method oriented to Internet of Things equipment. The method comprises the following steps: unpacking firmware; reverse analysis, including IPC interface identification and data key reasoning; binary rewriting, including single file path measurement and accumulation and transmission of multiple file paths; pre-measuring; deploying to a prover device; and finally, detecting the running state of the prover through a challenge response mechanism. According to the method, the control flows of a plurality of files are associated through the IPC interface and the data key, and the instrumentation method is designed based on the association so as to realize transmission and accumulation of the control flows among different files, so that cross-file runtime attacks which are difficult to discover by a traditional control flow remote certification method can be effectively detected.

Description

Technical Field

[0001] The present invention belongs to the field of Internet of Things security, and specifically provides a multi-file control flow remote attestation method for Internet of Things devices, which is used to detect cross-file control flow attacks that may occur during the collaborative operation of multiple binary files in Internet of Things devices. Background Art

[0002] Internet of Things devices usually achieve various functions through the collaborative operation of multiple binary files, such as sensor data acquisition, network communication, data processing, and user interaction. These binary files exchange data through the inter-process communication (IPC) mechanism, forming complex dependencies and interaction relationships.

[0003] Existing control flow attestation technologies mainly target single-file programs, and detect runtime attacks by instrumenting to record control flow paths. However, in Internet of Things devices with multi-file collaborative operation, it is often difficult to capture attack behaviors that may occur across files by performing control flow attestation on a single file alone. For example, the execution state of one file may affect the control flow path of other files through IPC, resulting in abnormal behaviors. If only control flow attestation is performed on a single file, these cross-file attack behaviors are likely to be ignored.

[0004] In addition, existing technologies also face the problem of path explosion. In actual operation, Internet of Things devices need to work in a real-time and changing environment, and dynamic factors such as external inputs and sensor data will cause the execution paths to grow exponentially, bringing huge challenges to path storage and verification. Summary of the Invention

[0005] Based on the above-mentioned problems, the present invention provides a multi-file control flow remote attestation method for Internet of Things devices, aiming to solve the problem that existing control flow attestation technologies cannot effectively detect cross-file runtime attacks in a multi-file collaborative working environment, and at the same time effectively alleviate the verification challenges brought by path explosion.

[0006] The technical solution for achieving the object of the present invention is as follows:

[0007] Step 1, firmware unpacking: Preprocess the firmware of the target Internet of Things device, use the binwalk tool to unpack the firmware, and extract binary files;

[0008] Step 2, Reverse Analysis: Construct the control flow graph of each binary file, identify and locate the IPC interfaces in each file, including five types: environment variables, files, shared memory, sockets, and command line arguments. Treat the IPC interfaces as convergence points, starting from the target IPC function call, perform reverse data flow tracing on its call parameters to find all possible call paths. Analyze the parameters of the target function, locate the position of the parameter where the data key is located, and trace the source of its input data. Perform coarse-grained value dependency analysis from each caller to the callee, and parse the specific content of the data reaching the IPC interface to infer the value of its data key.

[0009] Step 3, Binary Rewriting: Static instrumentation of the binary file to measure the control flow execution evidence of the program. At the entry of each basic block, insert measurement code to calculate the current execution evidence measurement value using a hash function based on the measurement value of the previous step and the start address of the current basic block.

[0010] Implement the transfer and accumulation of cross-file control flow based on IPC and its data keys. Maintain two dictionaries to record the execution evidence during the measurement process. Among them, the execution evidence dictionary stores key-value pairs of <binary file identifier, the execution evidence measurement value of this file>, and the inter-process communication dictionary stores key-value pairs of <data key, <binary file identifier, the current execution evidence measurement value when this file executes to the IPC interface using this data key>>;

[0011] Before calling the IPC interface of the data class, update its corresponding entries in the execution evidence dictionary and the inter-process communication dictionary, and transfer the execution evidence measurement value of the current file through the inter-process communication dictionary;

[0012] Before calling the IPC interface of the data class, update its corresponding entry in the execution evidence dictionary, and retrieve the existing record of the data key used by this interface in the inter-process communication dictionary. After the execution of this interface call, accumulate the existing record into the execution path measurement value of the current file.

[0013] Step 4, Pre-measurement: Package the rewritten binary file into firmware, execute the target firmware multiple times for pre-measurement, and store the obtained execution evidence hash value in the database;

[0014] Step 5, Deploy to the Prover Device: Deploy the modified firmware to the prover device;

[0015] Step 6, Challenge-Response Mechanism Detection: The verifier and the prover interact through two different levels of challenge-response mechanisms, and the information content of the interaction is guaranteed confidentiality, integrity, and authenticity through encryption, digest, and signature;

[0016] The verifier first sends a challenge request to the prover. The request content includes input parameters, a random nonce, and a verification level, where the verification level is used to distinguish the hash value of the request execution evidence or the complete execution evidence;

[0017] At a low level, the hash value of the request execution evidence is requested. The verifier retrieves the response content from the database. If a match is found, the verification is successful, indicating that the prover device has not been under a runtime attack. If the verification fails, a high-level challenge request is sent to the prover;

[0018] At a high level, the complete execution evidence is requested. The verifier simulates the execution process in the firmware emulation unit to verify the legality of the execution evidence. If the verification is successful, the measurement value is stored in the database. If the verification fails, an alarm is issued, reporting that the prover device is under a runtime attack.

[0019] The prover executes the program according to the received challenge, measures the control flow execution evidence, and maintains the update of the execution evidence dictionary and the inter-process communication dictionary during the execution process. According to the level of the challenge, a corresponding response is returned;

[0020] At a low level, the hash value of the execution evidence is returned. The number of entries in the execution evidence dictionary is counted, which is the number of files run during the execution process. Then, a hash calculation is performed on the execution evidence measurement values of all the run files and returned;

[0021] At a high level, the complete execution evidence is returned, which is the complete content of the execution evidence dictionary and the inter-process communication dictionary.

[0022] Compared with the prior art, the significant advantages of the present invention are as follows: By identifying and associating the IPC interfaces and data keys among multiple files, the present invention realizes the transfer and accumulation of cross-file control flow execution evidence, effectively detecting cross-file attacks that are difficult to discover by traditional single-file verification methods. The present invention also adopts a hierarchical challenge-response mechanism, initially only returning the hash value for quick comparison, and only transmitting the complete execution evidence when necessary, reducing data transmission and processing overhead. Combining with the firmware emulation technology to simulate the critical execution paths, it effectively alleviates the path explosion problem and improves the verification efficiency and scalability.

[0023] The following further describes the present invention in detail with reference to the accompanying drawings. Description of the Drawings

[0024] Figure 1 It is a flowchart of the multi-file control flow remote attestation method of the present invention.

[0025] Figure 2 It is an overall framework diagram of the multi-file control flow remote attestation method of the present invention.

[0026] Figure 3 It is a schematic diagram of multi-file control flow measurement of the present invention.

[0027] Figure 4 This is the challenge response interaction diagram in the online stage of the present invention. Detailed implementation manners

[0028] The solutions of the present invention will be described in detail below in conjunction with the accompanying drawings:

[0029] In conjunction with the Figure 1 and the Figure 2 , the present invention can be divided into three modules, six steps, and two stages. The three modules include a verifier, a prover, and a secure communication channel. The verifier is usually a server or cloud platform with sufficient computing resources, and the prover is a remote Internet of Things device that needs to be verified, with relatively scarce resources and difficult to deploy complex security protection mechanisms. The secure communication channel ensures that the communication content between the prover and the verifier in the online verification stage meets confidentiality, integrity, and authenticity. The six steps include: firmware unpacking; reverse analysis, including IPC interface identification and data key inference; binary rewriting, including single file path measurement and cumulative and transfer of multi-file paths; pre-measurement; deployment to the prover device; and finally, detecting the runtime state of the prover through a challenge response mechanism. The two stages include offline preprocessing and online verification, where steps 1 to 5 are completed in the offline preprocessing stage, and step 6 is the online verification stage. The following is a detailed introduction to each step:

[0030] Step 1, firmware unpacking: Preprocess the firmware of the target Internet of Things device, use the binwalk tool to unpack the firmware, and extract binary files;

[0031] Step 2, reverse analysis: Construct the control flow graph of each binary file, identify and locate the inter-process communication (IPC) interfaces in each file, including five types: environment variables, files, shared memory, sockets, and command line arguments. Regard the IPC interface as a convergence point, starting from the target IPC function call, perform reverse data flow tracing on its call parameters to find all possible call paths. Analyze the parameters of the target function, locate the position of the data key in the parameters, and trace the source of its input data. Perform coarse-grained value dependence analysis from each caller to the callee, and parse the specific content of the data reaching the IPC interface to infer the value of the data key.

[0032] Step 3, binary rewriting: Static instrumentation of the binary file to measure the control flow execution evidence of the program. At the entrance of each basic block, insert measurement code to calculate the current execution evidence measurement value using a hash function based on the measurement value of the previous step and the starting address of the current basic block.

[0033] Based on IPC and its data keys, implement the transfer and accumulation of cross-file control flow. Maintain two dictionaries to record the execution evidence during the measurement process. In the execution evidence dictionary, store key-value pairs of <binary file identifier, execution evidence measurement value of this file>. In the inter-process communication dictionary, store key-value pairs of <data key, <binary file identifier, current execution evidence measurement value when this file executes to the IPC interface using this data key>>. Divide the IPC interfaces into data setting types and data acquisition types;

[0034] Before calling the IPC interface of the data setting type, update its corresponding entries in the execution evidence dictionary and the inter-process communication dictionary, and transfer the execution evidence measurement value of the current file through the inter-process communication dictionary;

[0035] Before calling the IPC interface of the data acquisition type, update its corresponding entry in the execution evidence dictionary, and retrieve the existing record of the data key used by this interface in the inter-process communication dictionary. After the execution of this interface call, accumulate the existing record into the execution path measurement value of the current file.

[0036] Step 4, pre-measurement: Package the rewritten binary file into firmware, execute the target firmware multiple times for pre-measurement, and store the obtained execution evidence hash value in the database;

[0037] Step 5, deploy to the prover device: Deploy the modified firmware to the prover device;

[0038] Step 6, challenge-response mechanism detection: The verifier and the prover interact through two different levels of challenge-response mechanisms. The information content of the interaction is guaranteed confidentiality, integrity, and authenticity through encryption, hashing, and signature;

[0039] The verifier first initiates a challenge request to the prover. The request content includes input parameters, a random nonce, and a verification level, where the verification level is used to distinguish between requesting the hash value of the execution evidence or the complete execution evidence;

[0040] At the low level, request the hash value of the execution evidence. The verifier retrieves the response content in the database. If it hits, the verification is successful, indicating that the prover device has not been under a runtime attack. If the verification fails, continue to send a high-level challenge request to the prover;

[0041] At the high level, request the complete execution evidence. The verifier simulates the execution process in the firmware emulation unit to verify the legality of the execution evidence. If the verification is successful, store the measurement value in the database. If the verification fails, issue an alarm reporting that the prover device is under a runtime attack.

[0042] The prover executes the program according to the received challenge, measures the control flow execution evidence, and maintains the update of the execution evidence dictionary and the inter-process communication dictionary during the execution process. According to the level of the challenge, a corresponding response is returned;

[0043] At a low level, the hash value of the execution evidence is returned, the number of entries in the execution evidence dictionary is counted, that is, the number of files run during the execution process, and the hash calculation is performed on the execution evidence measurement values of all the run files and returned;

[0044] At a high level, the complete execution evidence is returned, that is, the complete content of the execution evidence dictionary and the inter-process communication dictionary.

[0045] Embodiment

[0046] Figure 1 and Figure 2 A flowchart and an overall framework diagram of a multi-file control flow remote attestation method for Internet of Things devices are provided. The framework consists of three parts: a verifier, a prover, and a secure communication channel. The verifier is usually a resource-rich server or cloud platform, and the prover is an untrusted remote Internet of Things device. The verifier and the prover interact through a challenge-response mechanism, and the secure communication channel ensures the confidentiality, authenticity, and integrity of the interaction process.

[0047] The overall process is divided into two stages: offline preprocessing and online verification. In the offline stage, the target firmware is preprocessed. The firmware unpacking and packing tools and binary rewriting are used to modify the firmware content. The measurement code of the control flow path is inserted into the program execution process, and the cross-file control flow transfer and accumulation are realized based on IPC and its data keys. The modified firmware is pre-measured, and the possible measurement values are stored in the database for subsequent online verification, and the modified firmware is deployed to the prover. After the prover is deployed, it enters the online verification stage. The verifier and the prover are verified through a two-level challenge-response mechanism, and the interaction process is protected by the secure communication module. The message content needs to be encrypted and the digest signed before sending, and the signature and digest are verified and the content is decrypted when the message is received.

[0048] The multi-file control flow measurement method is as Figure 3As shown, the transfer and accumulation of cross-file control flow are achieved based on IPC and its data keys. During the measurement process, two dictionaries are maintained to record the execution evidence during the measurement process. Among them, the execution evidence dictionary (PATH_dict) stores key-value pairs of <binary file identifier (BinaryID), the measured value of the execution evidence of this file>, and the inter-process communication dictionary (IPC_dict) stores key-value pairs of <data key, <binary file identifier, the current measured value of the execution evidence when this file executes to the IPC interface using this data key>>. This is because the same data key may be subject to get or set operations of multiple files. Before calling the set class IPC interface, update its corresponding entries in the execution evidence dictionary and the inter-process communication dictionary, and transfer the measured value of the execution evidence of the current file through the inter-process communication dictionary. Before calling the get class IPC interface, update its corresponding entry in the execution evidence dictionary, and retrieve the existing record of the data key used by this interface in the inter-process communication dictionary. After the execution of this interface call, accumulate the existing record into the measured value of the execution path of the current file.

[0049] The interaction process of online verification is as Figure 4 As shown, the interaction is carried out through a two-level challenge-response mechanism. Before sending a message, the content needs to be encrypted and the digest needs to be signed. When receiving a message, verify the signature and digest and then decrypt the content. In the low-level request, the prover returns the hash value of the execution evidence, and the verifier retrieves the response content in the database. If a hit is found, the verification is successful, indicating that the prover device has not been under a runtime attack. If the verification fails, a high-level challenge request is sent to the prover. In the high-level request, the prover returns the complete execution evidence, and the verifier simulates the execution process in the firmware emulation unit to verify the legality of the execution evidence. If the verification is successful, store the measured value in the database. If the verification fails, an alarm is issued, reporting that the prover device is under a runtime attack.

[0050] Those skilled in the art of this technology can understand that, unless otherwise defined, all terms used here (including technical terms and scientific terms) have the same meaning as the general understanding of those of ordinary skill in the art to which this invention belongs. It should also be understood that terms defined in a general dictionary should be understood to have a meaning consistent with the meaning in the context of the prior art, and will not be interpreted with an idealized or overly formal meaning unless defined as here.

[0051] The specific embodiments described above have further elaborated on the purpose, technical solutions, and beneficial effects of the present invention. It should be understood that the above description is only the specific embodiments of the present invention and is not used to limit the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present invention shall be included within the protection scope of the present invention.

Claims

1. A multi-file control flow remote attestation method for Internet of Things devices, characterized in that, It includes the following steps: Step 1, firmware unpacking: Unpack the firmware of the Internet of Things device and extract the binary files; Step 2, reverse analysis: Construct the control flow graph of each binary file, identify and locate the IPC interfaces therein; Determine the data keys of each IPC interface based on the data flow from sink to source; Step 3, binary rewriting: Static instrumentation of the binary files to measure the control flow execution evidence of the program. At the entrance of each basic block, use a hash function to calculate the current execution evidence measurement value, and realize the transfer and accumulation of cross-file control flow based on IPC and data keys; Step 4, pre-measurement: Package the rewritten binary files into firmware, execute the target firmware multiple times for pre-measurement, and store the obtained execution evidence hash values in the database; Step 5, deploy to the prover device: Deploy the repackaged firmware to the prover device; Step 6, challenge-response mechanism detection: The verifier sends a challenge request to the prover, the prover returns the execution evidence, and the verifier verifies the execution evidence.

2. The multi-file control flow remote attestation method for Internet of Things devices according to claim 1, wherein The specific method for constructing the control flow graph of each binary file, identifying and locating the IPC interfaces therein, and determining the data keys of each IPC interface based on the data flow from sink to source is as follows: Step 2.1, identify and locate the IPC interfaces in each file, where the IPC interfaces include environment variables, files, shared memory, sockets, and command-line parameters; Step 2.2, data key inference: Regard the IPC interface as a convergence point, start from the target IPC function call, perform reverse data flow tracing on the parameters of the target IPC function call to find all possible call paths; Analyze the parameters of the target function, locate the parameter position where the data key is located, and trace the source of the parameter input data; Perform coarse-grained value dependence analysis for each caller to callee; Parse the specific content of the data reaching the IPC interface and infer the value of the data key of the IPC interface.

3. The multi-file control flow remote attestation method for Internet of Things devices according to claim 1, wherein The specific method for Step 3 binary rewriting is as follows: Step 3.1, static instrumentation of the binary files to measure the control flow execution evidence of the program. At the entrance of each basic block, insert measurement code to use a hash function to calculate the current execution evidence measurement value according to the measurement value and the start address of the current basic block; Step 3.2, realize the transfer and accumulation of cross-file control flow based on IPC and its data keys, and maintain two dictionaries to record the execution evidence during the measurement process. Among them, the execution evidence dictionary stores key-value pairs of <binary file identifier, execution evidence measurement value of the file>, and the inter-process communication dictionary stores key-value pairs of <data key, <binary file identifier, current execution evidence measurement value when the file executes to the IPC interface using this data key>>. Divide the IPC interfaces into two categories: data setting and data acquisition; Update the corresponding entries in the execution evidence dictionary and the inter-process communication dictionary before the call of the data setting type IPC interface, and transfer the execution evidence measurement value of the current file through the inter-process communication dictionary; Before getting the IPC interface call of the data class, update its corresponding entry in the execution evidence dictionary, and retrieve the existing record in the inter-process communication dictionary for the data key used by the interface. After the interface call is executed, accumulate the existing record into the execution path measurement value of the current file.

4. The multi-file control flow remote attestation method for Internet of Things devices according to claim 1, characterized in that, Step 4: Pre-measurement, including: Package the rewritten binary file into firmware; Execute the target firmware multiple times in a simulation environment, covering different input and environmental conditions; Record the execution evidence hash value generated by each execution; These hash values are stored in the database as a whitelist for subsequent online verification.

5. The multi-file control flow remote attestation method for Internet of Things devices according to claim 1, wherein, Step 5: Deploy to the prover device, including: The rewritten and packaged firmware is deployed to the prover device. After receiving the challenge, the prover executes according to the challenge content. The measurement code inserted during the rewrite automatically measures the current control flow path during operation.

6. The multi-file control flow remote attestation method for Internet of Things devices according to claim 1, wherein Step 6: Challenge response mechanism detection, including: The verifier and the prover interact through two different levels of challenge response mechanisms. The content of the interaction is encrypted, summarized and signed to ensure confidentiality, integrity and authenticity. The verifier first sends a challenge request to the prover. The request content includes input parameters, random numbers, and verification levels. The verification level is used to distinguish the hash value of the requested execution evidence or the complete execution evidence. At a low level, the hash value of the execution evidence is requested. The verifier retrieves the response content in the database. If it hits, the verification is successful and the prover's device has not been attacked at runtime. If the verification fails, a high-level challenge request will continue to be issued to the prover. At a high level, the complete execution evidence is requested. The verifier simulates the execution process in the firmware simulation unit to verify the legitimacy of the execution evidence. If the verification succeeds, the measurement value is stored in the database. If the verification fails, an alarm is issued to report that the prover's device is under runtime attack. The prover executes the program according to the received challenge, measures the control flow execution evidence, and maintains the update of the execution evidence dictionary and the inter-process communication dictionary during the execution process, and returns the corresponding response according to the level of the challenge; At a low level, it returns the hash value of the execution evidence, counts the number of entries in the execution evidence dictionary, that is, the number of files that have been run during the execution process, and performs hash calculations on the execution evidence measurement values of all files that have been run, and returns them; At high level, the complete execution evidence is returned, that is, the complete contents of the execution evidence dictionary and the inter-process communication dictionary.

Images