Docker-based internet of things program runtime verification method

Abstract

The application discloses a kind of based on Docker's Internet of Things program runtime verification method, it is related to program verification technical field, the method includes: based on integrity measurement architecture, container image is hashed and is measured and is written into measurement list;The measurement value in the measurement list corresponding to target container is stored to the vPCR module corresponding to target container;vPCR module is extended into trusted platform module;The identity information and state information of the host platform where target container is located are verified, and the container is successfully started if the verification is passed;According to container ID, target container inner process pid and acquisition time, the memory binary information of corresponding process runtime is acquired, and memory event is constructed;The memory event corresponding to the verification of business flow on Internet of Things program of the memory event on the state machine end received by inter-state flow is realized. The application improves the security of Internet of Things program running.

Description

Technical Field

[0001] This invention relates to the field of program verification technology, and in particular to a Docker-based method for runtime verification of IoT programs. Background Technology

[0002] With the rapid development of IoT technology and the large-scale deployment of terminal applications, higher demands are being placed on cloud computing virtualization technology. Unlike traditional virtual machine technology, containers, as a new type of virtualization technology, offer advantages such as convenient deployment, fast startup, and high operating efficiency, making them popular among many IoT vendors and enterprises. Docker, as a typical example, is currently the mainstream container technology; however, it faces increasingly serious security challenges. Furthermore, with the proliferation of attack techniques, many attacks can cause unexpected errors in software runtime, affecting the entire software operation process and even causing denial-of-service attacks on the target system. In the unattended and highly automated application environment of IoT, the operational security of IoT services still needs improvement. Summary of the Invention

[0003] The purpose of this invention is to provide a Docker-based method for runtime verification of IoT programs, thereby improving the security of IoT program operation.

[0004] To achieve the above objectives, the present invention provides the following solution:

[0005] A Docker-based method for runtime verification of IoT applications, comprising:

[0006] Start the target container corresponding to the container ID; the target container is a Docker container.

[0007] Based on the integrity measurement architecture, the container image is hashed and written into the measurement list. The startup dependency files and application files when the target container is started are hashed and written into the measurement list. The measurement values ​​in the measurement list corresponding to the target container are stored in the vPCR module corresponding to the target container.

[0008] Extend the vPCR module into the Trusted Platform module;

[0009] A virtual AIK certificate is generated for the vPCR module based on the trusted platform module;

[0010] Based on the metric list corresponding to the target container, the identity information and status information of the host platform where the target container is located are verified. If the verification is successful, the target container starts successfully.

[0011] Once the target container starts successfully, the memory binary information of the corresponding process during runtime is obtained based on the container ID, the process pid within the target container, and the collection time sent by the verification state machine.

[0012] Determine the function call trajectory and target parameter information corresponding to the memory binary information and construct a memory event, then send the constructed memory event to the verification state machine.

[0013] By performing state transitions on the memory events received by the verification state machine, the verification of the IoT program business process corresponding to the memory events is achieved.

[0014] Optionally, based on the integrity measurement architecture, the container image is hashed and written to a measurement list, and the startup dependency files and application files when starting the target container are hashed and written to the measurement list, specifically including:

[0015] Create a list of metrics corresponding to the target container, named after the container ID.

[0016] The measurement agent listens for and captures measurement events from the integrity measurement architecture.

[0017] For the detected measurement event, parse the structure of the measurement event process to obtain the NamespaceID of the measurement event process, and compare the NamespaceID of the measurement event process with the NamespaceID of the target container;

[0018] If the NamespaceID of the metric event process is equal to the NamespaceID of the target container, the metric value corresponding to the monitored metric event will be expanded into the metric list corresponding to the target container.

[0019] Optionally, the vPCR module can be extended into the trusted platform module, specifically including:

[0020] Traverse the vPCR modules in the vPCR module linked list and calculate the median hash metric value based on the hash metric value of each vPCR module.

[0021] If the value of the extended register of the trusted platform module is not 0, compare the value of the extended register with the current intermediate value of the hash metric. If they are not the same, the target container fails to start.

[0022] If the value of the extended register is 0 or the value of the extended register is the same as the current intermediate hash metric, then the vPCR module corresponding to the target container is extended to obtain the intermediate hash metric after the extension operation.

[0023] The intermediate hash metric value after the expansion operation is extended into the expansion register.

[0024] Optionally, generating a virtual AIK certificate for the vPCR module based on the trusted platform module specifically includes:

[0025] The trusted platform module generates an AIK key pair, designated as the first AIK key pair, and generates an EK certificate, which is then sent to the certification center.

[0026] The certification center verifies the identity of the trusted platform module using the EK certificate, and issues an AIK certificate to the trusted platform module after successful verification.

[0027] The vPCR module of the target container sends a certificate request to the trusted platform module, and the certificate request includes the container ID;

[0028] After receiving the certificate application request, the trusted platform module creates a vAIK key pair based on the container ID and generates a Key, which is an RSA key pair.

[0029] The trusted platform module uses the private key in the first AIK key pair to sign the Key, thereby obtaining first signature information;

[0030] The trusted platform module uses the Key to sign the public key, the container ID, and the register in the vAIK key pair to obtain the second signature information;

[0031] The trusted platform module combines the first signature information, the second signature information, and the public key in the vAIK key pair to form the virtual AIK certificate.

[0032] Optionally, based on the metric list corresponding to the target container, the identity and status information of the host platform where the target container resides are verified, specifically including:

[0033] The prover sends a verification request to the verifier, the verification request including the container ID of the target container; the prover is the prover of the host platform where the target container is located;

[0034] The verifier generates an AIK key pair and an AIK certificate, and the AIK key pair generated by the verifier is recorded as the second AIK key pair;

[0035] When the verifier receives the verification request, it collects the status information of the host platform where the verifier is located, generates a first random number, and signs the status information, the first random number and the container ID using the private key in the second AIK key pair to obtain third signature information. The third signature information and the AIK certificate are then sent to the verifier.

[0036] After receiving the third signature information and the AIK certificate, the prover decrypts the third signature information using the public key in the second AIK key pair to verify the prover's identity. After successful identity verification, the prover generates a virtual AIK certificate according to the virtual AIK certificate application protocol. The prover uses the AIK certificate to sign the pPCR value to obtain a fourth signature information, and uses the prover's virtual AIK certificate to sign the vPCR module value to obtain a fifth signature information. Simultaneously, a second random number is generated. The fourth signature information, the fifth signature information, the second random number, the AIK certificate, the prover's virtual AIK certificate, the value set of each vPCR module in the vPCR module chain list, and the metric list corresponding to the target container are combined to form a first authentication report. The first authentication report and a first authentication message consisting of the hash value of the first authentication report are sent to the prover.

[0037] After receiving the first authentication message, the verifier verifies the first authentication message, generates a second verification report from the verification result, and sends a second authentication message consisting of the second verification report, the second random number, and the hash value formed by concatenating the second verification report and the second random number to the prover.

[0038] The verifier verifies the second authentication message after receiving it. If the verification of the second authentication message is successful, the identity and status information of the host platform where the target container is located are verified.

[0039] Optionally, after the target container starts successfully, the memory binary information of the corresponding process during runtime is obtained based on the container ID, the process pid within the target container, and the collection time sent by the verification state machine. Specifically, this includes:

[0040] The NamespaceID of the target container is determined based on the container ID;

[0041] The location array node is located by querying the pid_hash table based on the NamespaceID of the target container and the pid of the process within the target container; the location array node includes an ns value and an nr value, where the ns value represents the NamespaceID and the nr value represents the pid of the process.

[0042] Based on the queried location array node, locate the upid structure in the target process and determine the PID entity corresponding to the upid structure;

[0043] The process descriptor is obtained based on the PID entity, and the process virtual space memory address is determined based on the member variables in the process descriptor.

[0044] Translate the virtual space memory address to a physical address;

[0045] Based on the virtual space memory address, the physical address, and the mmap function, the memory binary information of the corresponding process during runtime is determined.

[0046] Optionally, verification of the IoT program business process corresponding to the memory event is achieved by performing state transitions on the memory events received by the verification state machine, specifically including:

[0047] Memory events are collected based on the predicted time value of the current state node, and timing is started. When the verification state machine collects a memory event, the multi-function constraint expression of the next state node of the current state node in the IoT program business process is traversed. If the currently collected memory event satisfies any constraint in the multi-function constraint expression, the transition is successful, and the next state node is updated to the current state node. If the currently collected memory event does not satisfy any constraint in the multi-function constraint expression, the transition fails, and memory event collection continues until the transition is successful, and the total transition time of the current state node is obtained. If the number of times the total transition time of the current state node occurs reaches a set threshold, the total transition time of the current state node is updated to the predicted time value of the current state node.

[0048] If the current state node is the final node, then the IoT program business process verification is complete.

[0049] According to specific embodiments provided by the present invention, the present invention discloses the following technical effects:

[0050] This invention first verifies the runtime environment during the target container startup process, and then verifies the runtime state after the target container has successfully started, thereby improving the security of IoT program operation. Attached Figure Description

[0051] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0052] Figure 1 A schematic diagram of a runtime verification method for IoT programs based on Docker, provided in an embodiment of the present invention;

[0053] Figure 2 This is a schematic diagram illustrating the generation of a virtual AIK certificate provided in an embodiment of the present invention;

[0054] Figure 3 A timing interaction diagram of the proof end and the verification end during remote verification provided in an embodiment of the present invention;

[0055] Figure 4 A schematic diagram illustrating the conversion of virtual addresses to physical addresses provided in an embodiment of the present invention;

[0056] Figure 5 This is a schematic diagram of the state transition of a single node provided in an embodiment of the present invention;

[0057] Figure 6 This is a schematic diagram of the memory event string format provided in an embodiment of the present invention. Detailed Implementation

[0058] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0059] The purpose of this invention is to provide a Docker-based method for runtime verification of IoT programs, thereby improving the security of IoT program operation.

[0060] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0061] Example 1

[0062] like Figure 1 As shown in the figure, this embodiment provides a runtime verification method for IoT programs based on Docker, which specifically includes the following steps.

[0063] Step 101: Start the target container corresponding to the container ID; the target container is a Docker container.

[0064] Step 102: Based on the integrity measurement architecture, perform hash measurement on the container image and write it into the measurement list; perform hash measurement on the startup dependency files and application files when starting the target container and write them into the measurement list; store the measurement values ​​in the measurement list corresponding to the target container into the vPCR module corresponding to the target container.

[0065] Step 103: Extend the vPCR module into the Trusted Platform module.

[0066] Step 104: Generate a virtual AIK certificate for the vPCR module based on the trusted platform module.

[0067] Step 105: Based on the metric list corresponding to the target container, verify the identity information and status information of the host platform where the target container is located. If the verification is successful, the target container starts successfully.

[0068] Step 106: After the target container starts successfully, obtain the memory binary information of the corresponding process during runtime based on the container ID, the process pid inside the target container, and the collection time sent by the verification state machine.

[0069] Step 107: Determine the function call trajectory and target parameter information corresponding to the memory binary information and construct a memory event, then send the constructed memory event to the verification state machine.

[0070] Step 108: By performing state transitions on the memory events received by the verification state machine, the verification of the IoT program business process corresponding to the memory events is achieved.

[0071] To address the issue of verifying the operating environment during the startup process, this invention utilizes Trusted Platform Module (TPM) and Integrity Measurement Architecture (IMA) technology in steps 101-103 to implement integrity measurement in trusted startup.

[0072] To address the issue of verifying the runtime state after successful startup, this invention utilizes remote verification technology in steps 104-105 to complete the reliable verification of the measurement value.

[0073] In this invention, the container (target container) is a manifestation of Docker. It starts based on an image file, forming dynamic instances, which are essentially processes. Containers use namespace technology to isolate process communication, file systems, network configurations, and domain names, achieving the goal of preventing internal processes from interfering with each other. The trusted startup objective of this invention is to ensure the integrity of the container image file, startup dependency files, and application file metrics within the container. In step 101, the user uses `docker start`. <containerid>The command starts the corresponding target container.

[0074] The metrics agent is the core module of integrity measurement, undertaking the collection and distribution of metric values ​​for container images, startup dependencies, and application files throughout the entire measurement process. The metrics agent first performs hash measurements on the container image (the Docker image is the foundation for Docker container startup, containing all the static data resources needed for startup; essentially, it's a root file system), and then introduces an improved IMA mechanism to perform hash measurements on the integrity of dependency files and applications during container startup.

[0075] Related terms explained: ConID represents the container ID dynamically assigned to a container by Docker in real time; NamespaceID refers to the container process namespace ID, and processes within the same container have the same NamespaceID. IMA metrics are implemented by embedding hook functions at corresponding metric points in the kernel, enabling the measurement of relevant code and key data and writing them into the metric list when kernel modules are loaded, dynamic link libraries are loaded, and applications are running. The vPCR (virtual PCR) module stores the metric values ​​of each container and is bound to the underlying TPM through step 103.

[0076] Step 102 specifically includes:

[0077] Retrieve the NamespaceID of the target container based on the container ID (ConID).

[0078] Name the target container with the container ID and create a metric list corresponding to the target container. The created metric list is an empty file.

[0079] The metric agent listens for and captures metric events from the integrity metric architecture.

[0080] For a detected metric event, the task_struct structure of the metric event process is parsed to obtain the NamespaceID of the metric event process, and then the NamespaceID of the metric event process is compared with the NamespaceID of the target container.

[0081] If the NamespaceID of the metric event process is equal to the NamespaceID of the target container, the metric value corresponding to the monitored metric event will be expanded into the metric list corresponding to the target container.

[0082] Finally, the contents of the container metric list are expanded into the corresponding vPCR module (virtual PCR module) of the container according to the following formula.

[0083] target-vPCR.conHash=HASH(target-vPCR.conHash||en ode hash ),(e∈conML i );

[0084] target-vPCR.value=HASH(target-vPCR.value||target-vPCR.conHash);

[0085] Where, target-vPCR.conHash represents the hash metric of the startup dependencies and applications in the target vPCR module, and e.node hash The metric value representing the current IMA metric event, conML i This represents the target container metric list. target-vPCR.value represents the hash metric values ​​of the container image, startup dependencies, and application in the target vPCR module, and e is the current IMA metric event.

[0086] In step 103, the metric values ​​from different containers are isolated and stored in vPCR modules to form a vPCR module-List (the vPCR modules of each container are linked together by pointers to form a vPCR module-List linked list), and extended into the physical PCR of the TPM (Trusted Platform Module) to ensure the trusted storage of the metric values. TPM is a secure cryptographic processor. The method of this invention uses dedicated secure hardware TPM to encrypt and store information, specifically including:

[0087] Since the PCR15 register of TPM is a user-defined register, the PCR15 register is selected as the extended register.

[0088] When a vPCR module receives a request to bind a TPM, it first traverses the first n-1 vPCR modules in the vPCR module linked list and calculates the hash metric value vPCR for each vPCR module. i The `.value` function calculates the median hash metric. The first n-1 vPCR modules expand the target container's metric list by extending all previous vPCR modules.

[0089] The vPCR module linked list is formed by linking the vPCR modules of each container together through pointers.

[0090] The first n-1 vPCR modules are set according to the total number of vPCR modules currently available.

[0091] The initial value of the intermediate hash metric tempPCR for each vPCR module is 0, and the calculation formula is as follows:

[0092] tempPCR = HASH(tempPCR||vPCR) i .value),(0<i<n,n≠+∞);

[0093] Where tempPCR represents the intermediate value of the hash metric, and vPCR i .value represents the hash metric of the container image, startup dependencies, and application in the i-th vPCR module.

[0094] If the value of the extended register of the trusted platform module is not 0, compare the value of the extended register with the intermediate value of the hash metric. If they are not the same, the target container fails to start.

[0095] If the value of the extended register is 0 or the value of the extended register is the same as the current intermediate hash metric, then the vPCR module corresponding to the target container is extended to obtain the intermediate hash metric after the extended operation.

[0096] Extending the intermediate hash metric value after the expansion operation into the extended register specifically includes:

[0097] The value of the nth vPCR module in the vPCR module-List is used to calculate the new tempPCR using the following formula.

[0098] tempPCR = HASH(tempPCR||vPCR) n .value);

[0099] Among them, vPCR n .value represents the hash metric of the container image, startup dependencies, and application in the nth vPCR module (the target container's vPCR module).

[0100] Reset the PCR15 register value of TPM and extend the new tempPCR into the PCR15 register.

[0101] PCR15=PCR_Extend(PCR15,tempPCR);

[0102] The PCR15 register represents the 15th PCR register in the TPM.

[0103] After completing the integrity measurement, the measurement value needs to be verified remotely. However, before remote verification, the trustworthiness of the vPCR management module needs to be ensured, therefore a virtual AIK (Platform Identity Authentication Key) certificate needs to be generated for it. In the method of this invention, the application for the virtual AIK certificate is implemented based on trust extension, and the trustworthiness of the virtual AIK is ensured by extending the certificate chain of the physical AIK, thereby ensuring the trustworthiness of the vPCR management module.

[0104] Among them, such as Figure 2 As shown, step 104 specifically includes:

[0105] 1) The trusted platform module generates an AIK key pair, denoted as the first AIK key pair, and uses TPM to initialize and generate an EK certificate, and sends the generated EK certificate to the certification center.

[0106] An EK certificate, also known as an endorsement certificate, is a unique identifier for a TPM chip. Each TPM chip can only have one EK certificate in its lifetime.

[0107] The certification center verifies the identity of the trusted platform module using the EK certificate, and issues an AIK certificate to the trusted platform module upon successful verification. The AIK is used to sign the PCR0-PCR7 and PCR15 registers on the hardware TPM to prove the integrity of the host platform.

[0108] The PCR0-PCR7 and PCR15 registers on the TPM are called pPCR.

[0109] 2) The vPCR module of the target container sends a certificate request to the Trusted Platform Module and extends the ConID to the TPM. The certificate request includes the container ID.

[0110] 3) After receiving the certificate application request, the trusted platform module creates a vAIK key pair based on the container ID and generates a Key, which is an RSA key pair.

[0111] 4) The trusted platform module uses the private key in the first AIK key pair to sign the Key to obtain the first signature information, thereby binding the Key with the physical platform identity information (the integrity measurement information of the physical host where the container is located).

[0112] 5) The trusted platform module uses the Key to sign the public key, the container ID, and the registers (register PCR0-register PCR7) in the vAIK key pair to obtain the second signature information; there are a total of 8 registers from register PCR0 to register PCR7.

[0113] The trusted platform module combines the first signature information, the second signature information, and the public key in the vAIK key pair to form the virtual AIK certificate.

[0114] The prover collects verification information, using dual AIK signatures to verify platform identity and status information. The prover then performs dual verification of both platform identity and status information.

[0115] Related terms explained: Target container refers to the container that needs to be verified in this remote verification; AIK v This represents the AIK key pair generated by the verifier. Platform identity information represents the authenticity of the platform's identity; platform status information represents the trustworthiness of applications running on the platform.

[0116] The prover is the prover of the host platform where the target container is located; the prover and the verifier belong to different host platforms.

[0117] The remote verification process is as follows: Figure 3 As shown, step 105 specifically includes:

[0118] 1) The prover sends a verification request to the verifier, the verification request including the container ID of the target container.

[0119] Attester→Verifier:ConID;

[0120] Attester represents the prover, Verifier represents the verifier, and ConID represents the target container number.

[0121] 2) The verifier completes the identity verification of its platform through the CA, generates an AIK key pair and an AIK certificate, and records the AIK key pair generated by the verifier as the second AIK key pair.

[0122] Upon receiving the verification request, the verifier collects the status information verPCR of its host platform and generates a first random number N1. It then uses the private key from the second AIK key pair to sign the status information, the first random number, and the container ID, obtaining a third signature. This third signature, along with the AIK certificate, is sent to the prover, requesting a challenge. Sending the platform status information demonstrates the platform's trustworthiness to the prover, and generating the N1 random number maintains the freshness of the session and prevents replay attacks.

[0123]

[0124] Here, verPCR represents the status information of the validator's host platform, which refers to the hash metric value of the extended register of the TPM on the validator's host. N1 represents the first random number generated by the validator. AIK key representing the validator. v Sign up. AIK certificate representing the verifier.

[0125] 3) After receiving the third signature information and the AIK certificate, the prover uses the second AIK key AIK. v The public key is used to decrypt the third signature information to verify the verifier's identity. After successful authentication, a virtual AIK certificate is generated for the prover according to the virtual AIK certificate application protocol. The AIK certificate is used to sign the pPCR values ​​(hardware PCR0-PCR7 and PCR15 registers) to obtain a fourth signature. The prover's virtual AIK certificate is used to sign the vPCR module value corresponding to the target container to obtain a fifth signature. Simultaneously, a second random number N2 is generated. The fourth signature, the fifth signature, the second random number, the AIK certificate, the prover's virtual AIK certificate, the value set of each vPCR module in the vPCR module linked list, and the metric list (conML) corresponding to the target container are combined to form a first authentication report M1. The first authentication report and its hash value, forming a first authentication message, are sent to the verifier. The generated second random number N2 is used to ensure the freshness of the returned request.

[0126] signPCR = Sign AIK (pPCR||N1)||Sign vAIK (vPCR||N1);

[0127] M1={signPCR,sendPCRs,conML,Cert AIK Cert vAIK ,N2};

[0128] Attester→Verifier:M1,HASH(M1);

[0129] Among them, Sign AIK The sign represents the use of the prover's AIK key to sign. vAIK This indicates that a virtual AIK (vAIK) key is used for signing. `sendPCRs` represents the set of values ​​for each vPCR module in the `vPCR Module-List`. `conML` represents the list of target container metrics. `Cert`... AIK and Cert vAIK These represent the AIK certificate and vAIK certificate of the prover, respectively. HASH represents hash calculation, signPCR is the result of concatenating the fourth and fifth signature information, and || indicates concatenation.

[0130] 4) After receiving the first authentication message, the verifier verifies the first authentication message, generates a second verification report M2 based on the verification result, and sends a second authentication message consisting of the second verification report, the second random number, and the hash value formed by concatenating the second verification report and the second random number to the prover.

[0131] After receiving the first authentication message, the verifier performs a hash calculation on the received first authentication report M1, compares the calculated hash value with the hash value in the first authentication message, and if they are the same, the verification passes; otherwise, the verification fails. The second verification report M2 is used to indicate whether the verification passed or failed.

[0132] Verifier → Attester:M2,N2,HASH(M2||N2).

[0133] 5) After receiving the second authentication message, the prover performs a hash calculation on the received second authentication report M2, compares the calculated hash value with the hash value in the second authentication message, and compares the received second random number with the second random number stored by the prover. If they are the same, the verification is successful, that is, the identity information and status information of the host platform where the target container is located are verified; otherwise, the verification fails.

[0134] The prover first verifies that the hash value confirmation report has not been tampered with, then verifies the validity of the random number N2 to prove the freshness of the session, and finally obtains the verification report M2.

[0135] The design of hashing and resending the M1 and M2 reports is to prevent the reports from being maliciously tampered with by attackers during transmission, which would cause the reports to become invalid and thus affect the normal startup of the container.

[0136] After passing the verification in step 105, the program started successfully. Next, we will begin verifying the program's runtime status.

[0137] On the host machine, based on the ConID, the process pid inside the container, and the next collection time sent by the process verification end, the memory binary information of the corresponding process during runtime is obtained.

[0138] In step 106, the process memory acquisition method uses the pid_hash hash value method to search for the specified program process, then performs virtual address to physical address conversion on the target process address, and finally combines the mmap function to perform memory mapping to obtain the memory address content.

[0139] Explanation of related terms: pid represents the process ID; PID represents the process ID entity; the upid structure refers to the upid type structure contained in the PID entity, which is the upid entity under different namespaces corresponding to the same PID.

[0140] Step 106 specifically includes:

[0141] 1) Determine the NamespaceID of the target container based on the container ID.

[0142] 2) Based on the NamespaceID of the target container and the PID of the process within the target container, query the pid_hash table to locate the array node. The array node includes ns and nr values, where ns represents the NamespaceID and nr represents the process PID. Specifically, iterate through the node array to determine if the ns and nr values ​​of each node match the target NamespaceID and PID. If they match, locate the upid structure of the target process.

[0143] 3) Locate the upid structure in the target process based on the queried location array node, and determine the PID entity corresponding to the upid structure through the system function container_of.

[0144] 4) Obtain the process descriptor `task_struct` based on the PID entity, and determine the virtual space memory address range of the process based on the member variables in the process descriptor. The virtual space memory address range includes the start address and the end address.

[0145] 5) Combine with / proc / <pid>The / pagemap file, combined with Figure 4 The virtual space memory address within the virtual space memory address range is converted to a physical address according to the following formula.

[0146]

[0147]

[0148] Where vaddr represents the virtual address, pageSize represents the page size (usually 4KB), offset represents the offset of the pagemap file, phyPageIndex represents the mapped physical page number, paddr represents the physical address, and sizeof(uint64) represents the size of the 64-bit unsigned integer.

[0149] 6) Based on the virtual memory address range, the physical address, and the mmap function, determine the memory binary information of the corresponding process at runtime. That is, by combining the / dev / fmem device with the mmap system call, the target process's memory is mapped to the address space where the memory forensics program resides. The memory forensics program then accesses the specified physical memory in real time by accessing its own virtual memory address information.

[0150] In step 107, the runtime function call trajectory and target parameter information are restored through semantic analysis and semantic reconstruction based on the obtained memory binary information, and a memory event is constructed and sent to the verification state machine.

[0151] Related terminology explanation: The process code segment is the area used to store the machine instructions that will be executed after the program is compiled. It is the image of the executable program in memory.

[0152] Step 107 specifically includes:

[0153] 1) Read the stack memory information (hereinafter referred to as block information) from low address to high address in units of 4 bytes, and reconstruct the actual storage information by organizing the bytes in endianness according to the hardware configuration.

[0154] 2) Compare the block information with the disassembled contents of the process code segment to determine if a return address exists.

[0155] 3) Based on the determined return address, disassemble and read the content at return address -5 of the process code segment. The content read is in the format callq<address content><function name>. Parse the function name based on the read content and determine the function call trajectory based on each function name.

[0156] 4) Based on the address of the target function (known function) in the code segment, and according to the number of parameters, disassemble the code segment content to determine the position of the parameters relative to the start address of the stack frame.

[0157] 5) Obtain the binary content of the parameter from the stack frame based on the relative position of the parameter, and restore the specific value of the parameter based on the parameter type.

[0158] 6) Construct the memory event string according to the predefined XML format requirements, as shown in the format below. Figure 6 As shown, the memory event string includes the target function name, function parameter values, etc. obtained in the above steps.

[0159] 7) Based on the IP address and port number of the verification state machine system, send an event request to the verification state machine and wait for the verification system to connect before sending the memory event string (memory event).

[0160] The verification state machine verifies the IoT application's business process by transitioning between states based on memory events collected by the memory event acquisition terminal. The business process consists of multiple state nodes.

[0161] The IoT program business process consists of multiple state nodes.

[0162] In step 108, the business process verification employs strategies such as data acquisition time prediction, multi-function verification, and time prediction correction during state machine transitions to further improve verification efficiency. A schematic diagram of the state transition for a single node is shown below. Figure 5 As shown, this includes the application of various strategies, with the specific steps as follows:

[0163] 1) The prediction time values ​​and multi-function constraint expressions of the state nodes are pre-configured during initialization. That is, the prediction time values ​​and multi-function constraint expressions are initialized for each state node.

[0164] 2) When a memory event occurs, the multi-function constraint expression of the next state node to which the event is about to occur is traversed and a transition is attempted. If any of the constraints are satisfied, the transition is successful and the next node becomes the current state node.

[0165] 3) The current status node starts the time counter and sends the predicted time value to the memory event acquisition side for accurate event acquisition (acquiring memory event strings).

[0166] 4) Repeat the state node transition attempt from the previous step for the collected event. If successful, proceed to the next state node; otherwise, notify the event collection side to continue collecting until the state node transition is successful, and record the total transition time at this point. When the cumulative number of occurrences of this total transition time reaches a certain threshold, modify the predicted time value of the current state node.

[0167] 5) The entire business process verification is completed when the current state node is transferred to the final node.

[0168] During the business process verification process, each state node transition is compared with the set process template. If each state node transition is consistent with the set process template, the verification passes; otherwise, the verification fails.

[0169] Set the process template to the correct flow of the IoT program business process corresponding to the memory event.

[0170] This invention provides a Docker-based runtime verification method for IoT applications. Addressing the issues of untrusted runtime environments and states faced by IoT applications, it combines trusted computing, remote verification, memory forensics, and runtime verification technologies to ensure the trustworthiness and efficient startup of the Docker container, enabling accurate and stable monitoring of the IoT application's business processes. By introducing this method, enterprises can improve the security of their IoT applications, promptly detect attacks, and take remedial measures, minimizing losses.

[0171] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0172] This document uses specific examples to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. Furthermore, those skilled in the art will recognize that, based on the ideas of the present invention, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of the present invention.< / pid> < / containerid>

Claims

1. A method for runtime verification of IoT programs based on Docker, characterized in that, include: Start the target container corresponding to the container ID; The target container is a Docker container; Based on the integrity measurement architecture, the container image is hashed and written into the measurement list. The startup dependency files and application files when the target container is started are hashed and written into the measurement list. The measurement values ​​in the measurement list corresponding to the target container are stored in the vPCR module corresponding to the target container. Extend the vPCR module into the Trusted Platform module; A virtual AIK certificate is generated for the vPCR module based on the trusted platform module; Based on the metric list corresponding to the target container, the identity information and status information of the host platform where the target container is located are verified. If the verification is successful, the target container starts successfully. Once the target container starts successfully, the memory binary information of the corresponding process during runtime is obtained based on the container ID, the process pid within the target container, and the collection time sent by the verification state machine. Determine the function call trajectory and target parameter information corresponding to the memory binary information and construct a memory event, then send the constructed memory event to the verification state machine. By performing state transitions on the memory events received by the verification state machine, the verification of the IoT program business process corresponding to the memory events is achieved. Specifically, after the target container starts successfully, the memory binary information of the corresponding process during runtime is obtained based on the container ID, the process pid (PID) within the target container, and the collection time sent by the verification state machine. This includes: The NamespaceID of the target container is determined based on the container ID; The location array node is located by querying the pid_hash table based on the NamespaceID of the target container and the pid of the process within the target container; the location array node includes an ns value and an nr value, where the ns value represents the NamespaceID and the nr value represents the pid of the process. Based on the queried location array node, locate the upid structure in the target process and determine the PID entity corresponding to the upid structure; The process descriptor is obtained based on the PID entity, and the process virtual space memory address is determined based on the member variables in the process descriptor. Translate the virtual space memory address to a physical address; Based on the virtual space memory address, the physical address, and the mmap function, determine the memory binary information of the corresponding process during runtime; Specifically, by performing state transitions on the memory events received by the verification state machine, the verification of the IoT program business process corresponding to the memory events is achieved, including: Memory events are collected based on the predicted time value of the current state node, and timing is started. When the verification state machine collects a memory event, the multi-function constraint expression of the next state node of the current state node in the IoT program business process is traversed. If the currently collected memory event satisfies any constraint in the multi-function constraint expression, the transition is successful, and the next state node is updated to the current state node. If the currently collected memory event does not satisfy any constraint in the multi-function constraint expression, the transition fails, and memory event collection continues until the transition is successful, and the total transition time of the current state node is obtained. If the number of times the total transition time of the current state node occurs reaches a set threshold, the total transition time of the current state node is updated to the predicted time value of the current state node. If the current state node is the final node, then the IoT program business process verification is complete.

2. The method for runtime verification of IoT programs based on Docker according to claim 1, characterized in that, Based on the integrity measurement architecture, the container image is hashed and written to a measurement list. The startup dependency files and application files used when starting the target container are also hashed and written to the measurement list. Specifically, this includes: Create a list of metrics corresponding to the target container, named after the container ID. The measurement agent listens for and captures measurement events from the integrity measurement architecture. For the detected measurement event, parse the structure of the measurement event process to obtain the NamespaceID of the measurement event process, and compare the NamespaceID of the measurement event process with the NamespaceID of the target container; If the NamespaceID of the metric event process is equal to the NamespaceID of the target container, the metric value corresponding to the monitored metric event will be expanded into the metric list corresponding to the target container.

3. The Docker-based IoT program runtime verification method according to claim 1, characterized in that, Extending the vPCR module into the trusted platform module specifically includes: Traverse the vPCR modules in the vPCR module linked list and calculate the median hash metric value based on the hash metric value of each vPCR module. If the value of the extended register of the trusted platform module is not 0, compare the value of the extended register with the current intermediate value of the hash metric. If they are not the same, the target container fails to start. If the value of the extended register is 0 or the value of the extended register is the same as the current intermediate hash metric, then the vPCR module corresponding to the target container is extended to obtain the intermediate hash metric after the extension operation. The intermediate hash metric value after the expansion operation is extended into the expansion register.

4. The method for runtime verification of IoT programs based on Docker according to claim 1, characterized in that, The trusted platform module generates a virtual AIK certificate for the vPCR module, specifically including: The trusted platform module generates an AIK key pair, designated as the first AIK key pair, and generates an EK certificate, which is then sent to the certification center. The certification center verifies the identity of the trusted platform module using the EK certificate, and issues an AIK certificate to the trusted platform module after successful verification. The vPCR module of the target container sends a certificate request to the trusted platform module, and the certificate request includes the container ID; After receiving the certificate application request, the trusted platform module creates a vAIK key pair based on the container ID and generates a Key, which is an RSA key pair. The trusted platform module uses the private key in the first AIK key pair to sign the Key, thereby obtaining first signature information; The trusted platform module uses the Key to sign the public key, the container ID, and the register in the vAIK key pair to obtain the second signature information; The trusted platform module combines the first signature information, the second signature information, and the public key in the vAIK key pair to form the virtual AIK certificate.

5. The Docker-based IoT program runtime verification method according to claim 4, characterized in that, Based on the metric list corresponding to the target container, the identity and status information of the host platform where the target container resides are verified, specifically including: The prover sends a verification request to the verifier, the verification request including the container ID of the target container; the prover is the prover of the host platform where the target container is located; The verifier generates an AIK key pair and an AIK certificate, and the AIK key pair generated by the verifier is recorded as the second AIK key pair; When the verifier receives the verification request, it collects the status information of the host platform where the verifier is located, generates a first random number, and signs the status information, the first random number and the container ID using the private key in the second AIK key pair to obtain third signature information. The third signature information and the AIK certificate are then sent to the verifier. After receiving the third signature information and the AIK certificate, the prover decrypts the third signature information using the public key in the second AIK key pair to verify the prover's identity. After successful identity verification, the prover generates a virtual AIK certificate according to the virtual AIK certificate application protocol. The prover uses the AIK certificate to sign the pPCR value to obtain a fourth signature information, and uses the prover's virtual AIK certificate to sign the vPCR module value to obtain a fifth signature information. Simultaneously, a second random number is generated. The fourth signature information, the fifth signature information, the second random number, the AIK certificate, the prover's virtual AIK certificate, the value set of each vPCR module in the vPCR module chain list, and the metric list corresponding to the target container are combined to form a first authentication report. The first authentication report and a first authentication message consisting of the hash value of the first authentication report are sent to the prover. After receiving the first authentication message, the verifier verifies the first authentication message, generates a second verification report from the verification result, and sends a second authentication message consisting of the second verification report, the second random number, and the hash value formed by concatenating the second verification report and the second random number to the prover. The verifier verifies the second authentication message after receiving it. If the verification of the second authentication message is successful, the identity and status information of the host platform where the target container is located are verified.

Images