A secure communication method of an internet of things device

Abstract

The application provides a secure communication method of an Internet of Things device, which can send an operating system fingerprint of a to-be-verified device to a verification device, the verification device generates a detector and a verifier through a trust network according to the received operating system fingerprint, and sends the detector to the to-be-verified device, the to-be-verified device executes the detector in a kernel mode and sends a verification result to the verification device, the verification device compares the received verification result with a verification result obtained by executing the verifier in a user mode, if the verification results are the same, the to-be-verified device passes the authentication of the verification device, the same method is used to perform the authentication of the verification device by the to-be-verified device, if the authentication is passed, the authentication of both sides is successful, and then a key obtained in the authentication process is used for secure communication, so that the bidirectional identity authentication and key negotiation of the Internet of Things device are realized through a pure software mode, zero trust and code open source level security can be realized, and the security level is extremely high.

Description

Technical Field

[0001] This invention relates to the field of secure communication, and in particular to a secure communication method for Internet of Things (IoT) devices. Background Technology

[0002] Currently, trusted and secure communication between devices is mainly achieved through dedicated hardware such as Trusted Platform Modules (TPMs). However, TPMs suffer from high costs, hardware vendor maintenance risks, low update frequency, and vulnerability to hacking in the quantum era. To address these issues, pure software-based trusted and secure communication technologies have gained widespread attention. These technologies implement strong authentication and trusted communication between devices solely through software, offering not only low cost but also the ability to update security factors after each authentication, thereby significantly enhancing security and resisting quantum attacks.

[0003] Pure software trusted secure communication technology involves the combination of two key technologies: identity authentication and secure communication. Its "trustworthiness" is often built upon "machine identity." Therefore, machine identity, two-way authentication, secure channels, and zero-trust foundation are the four core requirements of pure software trusted secure communication technology. However, existing pure software trusted secure communication solutions suffer from trust barriers and security vulnerabilities, providing a low level of security. For example, existing solutions define the functional attributes of machine identity in a simple way, failing to fully define the machine's runtime environment and unable to eliminate the risk of malicious modules and operating system hijacking. While machine identity includes system characteristics and running process information, it does not consider virus hijacking, making environment verification vulnerable. Furthermore, although mutual identity verification is achieved, it is passive trust rather than active verification, making it very easy to be deceived if the other party's operating system is untrustworthy. Currently, there is no technical route to achieve secure communication without relying on a third party.

[0004] Therefore, existing pure software trusted secure communication schemes achieve relatively secure verification with the help of a series of external aids. The authentication and secure communication between devices are difficult to trust, thus requiring a pure software trusted secure communication scheme with enhanced security level. Summary of the Invention

[0005] One objective of this application is to provide a secure communication method for Internet of Things (IoT) devices, thereby addressing the problem that it is difficult to achieve strong authentication and trusted communication between IoT devices through pure software methods in the prior art.

[0006] To achieve the above objectives, some embodiments of this application provide a secure communication method for an Internet of Things (IoT) device, for a first device, the method comprising:

[0007] The system sends its own first operating system fingerprint to the second device. The operating system fingerprint includes the fingerprint characteristics of the kernel image, the fingerprint characteristics of the dynamically loaded kernel module, and the fingerprint characteristics of the kernel boot process.

[0008] The device receives a first detector sent by the second device, which is generated by the second device through a trusted network based on the fingerprint of the first operating system.

[0009] The first detector is executed in kernel mode to obtain the first verification result and the first communication key, and then the first verification result is sent to the second device.

[0010] Furthermore, the method also includes:

[0011] Receive the encrypted second operating system fingerprint sent by the second device and decrypt it using the first communication key;

[0012] A second detector and a second verifier are generated through a trust network based on the fingerprint of the second operating system.

[0013] The second detector is encrypted using the first communication key and then sent to the second device.

[0014] Execute the second verifier in user mode to obtain the third verification result and the third communication key;

[0015] Receive the encrypted fourth verification result sent by the second device and decrypt it using the first communication key;

[0016] If the third verification result is the same as the fourth verification result, the data is encrypted and transmitted using the third communication key and sent to the second device.

[0017] Furthermore, the fingerprint feature includes multiple feature items, which at least include the following: path, content hash, control type, and feature type.

[0018] Furthermore, the method also includes:

[0019] Calculate the checksum for the contents of each feature item in the fingerprint;

[0020] Accumulate the checksums corresponding to all feature items;

[0021] The accumulated results are hashed to determine the HASH value corresponding to the fingerprint features.

[0022] Furthermore, the method for generating the first detector, the first verifier, the second detector, and the second verifier is the code DNA generation method.

[0023] Furthermore, trust network nodes within the network, including virtual machine monitors running in the highest privilege state.

[0024] Furthermore, the construction process of the trust network in the startup phase includes:

[0025] The first network node sends its own first node operating system fingerprint and the identity challenge information of the first virtual machine monitor to the second network node. The identity challenge information includes a preset value corresponding to the first virtual machine monitor and the signature information of the preset value.

[0026] The second network node authenticates the first network node's Hypervisor based on the identity challenge information of the first virtual machine monitor;

[0027] If the Hypervisor of the first network node is successfully authenticated, the second network node performs operating system fingerprint authentication on the operating system fingerprint of the first node.

[0028] If the first node's operating system fingerprint is successfully authenticated, the second network node will confirm that the first network node has been authenticated.

[0029] The second network node sends its own second node operating system fingerprint and second virtual machine monitor identity challenge information to the first network node, so that the first network node can perform Hypervisor authentication and operating system fingerprint authentication on the second network node.

[0030] Once the second network node passes Hypervisor authentication and operating system fingerprint authentication, the first network node confirms that the second network node has passed authentication, and the trusted network is completed during the startup phase.

[0031] Furthermore, the second network node authenticates the first network node's Hypervisor based on the identity challenge information of the first virtual machine monitor, including:

[0032] The second network node checks whether the identity challenge information of the first virtual machine monitor is stored locally;

[0033] If the identity challenge information of the first virtual machine monitor is not stored in the second network node, the second network node generates a third virtual machine monitor based on the operating system fingerprint of the first node; otherwise, the Hypervisor authentication of the first network node is successful. The third virtual machine monitor includes a preset value generation module and a signature module. The preset value generation module is used to generate preset values ​​based on the operating system fingerprint of the first node and random logic. The signature module is used to sign the preset values ​​based on the built-in private key and output the signature information.

[0034] The second network node sends the third virtual machine monitor to the first network node;

[0035] The first network node restarts and loads the third virtual machine monitor;

[0036] The first network node re-requests Hypervisor authentication from the second network node.

[0037] Some embodiments of this application also provide a secure communication method for an Internet of Things (IoT) device, for a second device, the method comprising:

[0038] Receive the first operating system fingerprint sent by the first device. The operating system fingerprint includes the fingerprint characteristics of the kernel image, the fingerprint characteristics of the kernel dynamically loaded module, and the fingerprint characteristics of the kernel boot process.

[0039] A first detector and a first verifier are generated through a trust network based on the fingerprint of the first operating system.

[0040] Send the first detector to the first device;

[0041] Receive the first verification result sent by the first device;

[0042] Execute the first verifier in user mode to obtain the second verification result and the second communication key;

[0043] If the first verification result is the same as the second verification result, the second operating system fingerprint is encrypted using the second communication key and sent to the first device.

[0044] Furthermore, the method includes:

[0045] Receive the encrypted second detector sent by the first device and decrypt it using the second communication key;

[0046] The second detector is executed in kernel mode to obtain the fourth verification result and the fourth communication key;

[0047] The fourth verification result is encrypted using the second communication key and then sent to the first device.

[0048] It receives encrypted transmission data sent by the first device, decrypts and processes it using the fourth communication key.

[0049] Compared with existing technologies, the solution provided in this application can send the operating system fingerprint of the device to be verified to the verification device. The verification device generates a detector and a verifier through a trusted network based on the received operating system fingerprint, and sends the detector to the device to be verified. The device to be verified executes the detector in kernel mode and sends the verification result to the verification device. The verification device compares the received verification result with the verification result obtained by executing the verifier in user mode. If they are the same, the device to be verified passes the authentication of the verification device. Then, the device to be verified authenticates the verification device using the same method. If the authentication passes, both parties are successfully authenticated. Then, the key obtained during the authentication process is used for secure communication. Thus, two-way identity authentication and key negotiation of IoT devices are realized in a pure software manner, which can achieve zero trust and open-source code-level security, with an extremely high level of security. Attached Figure Description

[0050] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0051] Figure 1 This application provides an interactive flowchart for authenticating a first device using a second device, which is provided for some embodiments of the present application.

[0052] Figure 2 This application provides an interactive flowchart for authenticating a second device using a first device, which is provided for some embodiments of the present application.

[0053] Figure 3 A schematic diagram illustrating the operating modes of an IoT operating system provided for some embodiments of this application.

[0054] Figure 4 A security control flowchart for the kernel startup process of an IoT device operating system provided for some embodiments of this application.

[0055] Figure 5 A flowchart illustrating how an IoT device B authenticates an IoT device A, provided for some embodiments of this application.

[0056] Figure 6 The technical architecture diagram of VoidChain provided for some embodiments of this application.

[0057] Figure 7 This is a schematic diagram of a closed-loop safety space index system provided for some embodiments of this application. Detailed Implementation

[0058] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. These embodiments are based on the technical solution of the present invention and provide detailed implementation methods and specific operating procedures. However, the scope of protection of the present invention is not limited to the following embodiments.

[0059] Here, the secure communication method for IoT devices in this application embodiment is suitable for scenarios where trusted and secure communication is established between IoT devices. IoT devices may include, but are not limited to, robots, autonomous vehicles, automated unmanned factories, IoT terminals, etc. The functions of IoT devices are relatively simple and the operating environment is relatively fixed.

[0060] In this scenario, mutually distrustful IoT devices need to verify each other's machine identities and cannot rely on any entity for control. The authentication process must be guaranteed to be free from interference or deception by any other device, and a high-security key negotiation process is required to ultimately achieve zero-trust, open-source-level security.

[0061] The secure communication method for IoT devices provided in this application can send the operating system fingerprint of the device to be verified to the verification device. The verification device generates a detector and a verifier through a trusted network based on the received operating system fingerprint, and sends the detector to the device to be verified. The device to be verified executes the detector in kernel mode and sends the verification result to the verification device. The verification device compares the received verification result with the verification result obtained by executing the verifier in user mode. If they are the same, the device to be verified passes the authentication of the verification device. Then, the device to be verified authenticates the verification device using the same method. If the authentication passes, both parties are successfully authenticated. The key obtained during the authentication process is then used for secure communication. Thus, two-way identity authentication and key negotiation of IoT devices are achieved through pure software, which can achieve zero trust and open-source code-level security, with an extremely high security level.

[0062] Some embodiments of this application provide a technical solution for establishing trusted and secure communication between a first device 100 and a second device 200, such as... Figure 1 and Figure 2 As shown, the first device 100 can be any type of IoT device, and the second device 200 can also be any type of IoT device. Specifically, Figure 1 This illustrates the process of the first device 100 being connected to the second device 200, and the second device 200 authenticating the first device 100:

[0063] In step S101, the first device 100 sends its own first operating system fingerprint to the second device 200.

[0064] Here, the first device 100 is the device to be verified, and the second device 200 is the verification device. The second device verifies the first device to confirm that the first device is a trusted device.

[0065] In some embodiments of this application, the operating system fingerprint includes the fingerprint characteristics of the kernel image, the fingerprint characteristics of the dynamically loaded kernel module, and the fingerprint characteristics of the kernel boot process. The fingerprint characteristics of the kernel image are used to describe the fingerprint characteristics of the operating system kernel image of the IoT device; the fingerprint characteristics of the dynamically loaded kernel module are used to describe the fingerprint characteristics of the modules dynamically loaded by the operating system kernel of the IoT device; and the fingerprint characteristics of the kernel boot process are used to describe the fingerprint characteristics of the process booted by the operating system kernel of the IoT device.

[0066] Here, operating system fingerprint refers to the operating system runtime environment fingerprint. For most IoT devices, the operating system fingerprint is constant. The operating system fingerprint not only serves as the unique identifier for communication between IoT devices, but also as the most important indicator of the security of its own operating system. In the operating environment of IoT devices with a fixed operating system fingerprint, computer viruses cannot exist, because as soon as a virus enters the device's operating environment, it will change the operating system fingerprint and thus be detected by the operating system fingerprint detection process.

[0067] All fingerprint features are automatically managed and maintained by the operating system kernel of IoT devices and are part of the operating system kernel. For IoT devices, the fingerprint features of the kernel image include the addresses of the core functions of the operating system kernel and the hash of the memory code segment (including code segment alignment gaps). Once the operating system version is determined, the hash value of the kernel image fingerprint features is also a fixed value. Therefore, a detector running in kernel mode can identify whether the current operating system kernel is complete, clean, and whether there are viruses, thereby accurately identifying the machine identity of the IoT device.

[0068] In the embodiments of this application, the fingerprint features of the kernel dynamically loaded modules and the fingerprint features of the kernel startup process are managed and controlled by the operating system kernel. The operating system kernel will perform fingerprint feature checks, such as scanning the content HASH of the module or process, before activating the module or starting the process, and register the relevant fingerprint features in the runtime library of the operating system kernel. This ensures that when the operating system kernel is secure and trustworthy, the fingerprint features of all modules and processes loaded by the kernel are also trustworthy.

[0069] In some embodiments of this application, the fingerprint feature includes multiple feature items, which include, but are not limited to, the following: path, content hash, control type, and feature type. The path describes the access path of a related object, such as a kernel loading module; the content hash describes the hash value obtained after hash calculation of the related object; the control type describes the related control state, such as registering the feature, allowing a child process to ignore the feature, or allowing the addition of fingerprint feature items; the feature type describes the type of the fingerprint feature, such as a kernel image or a kernel startup process.

[0070] In some embodiments of this application, calculating the HASH value corresponding to the fingerprint feature may include the following steps:

[0071] 1) Calculate the checksum for each feature item in the fingerprint;

[0072] 2) Accumulate the checksums corresponding to all feature items;

[0073] 3) Perform hash calculation on the accumulated results to determine the HASH value corresponding to the fingerprint features.

[0074] Using the above method, even if the arrangement order of the feature items within a fingerprint feature is different, a consistent HASH value corresponding to the fingerprint feature can be obtained.

[0075] In step S102, the second device 200 generates a first detector and a first verifier through a trust network based on the fingerprint of the first operating system.

[0076] Here, the detector is used to run on the device to be verified and identify the identity of the device. The detector in the embodiments of this application can lock the operating system fingerprint of the device to be verified without being deceived, and it has the following key features:

[0077] 1. Use open-source programs to generate detectors; only open-source and secure code can be used as a standard technology for public adoption.

[0078] 2. The detector is logically impossible to exhaustively explore or crack, thus ensuring that the detector cannot be cracked in a short period of time;

[0079] 3. The detector is compiled as an operating system kernel-level module. By running in kernel mode, it ensures that the operating system fingerprint is obtained without being deceived, and that the obtained operating system fingerprint is consistent with the declared operating system fingerprint.

[0080] 4. The detector's security reaches a level that the device to be verified trusts sufficiently, causing the device to agree to let the detector run in its kernel mode;

[0081] 5. The communication key built into the detector can only be obtained by executing under the correct operating system fingerprint environment and cannot be cracked by bypassing the system.

[0082] When the trust network generates a detector, it also generates a corresponding verifier. The verifier runs locally on the verification device. The verifier's processing logic is the same as the detector's, the difference being that the verifier runs in user mode. Because the detector performs various random iterations on the intermediate verification results when checking the validity of the operating system fingerprint of the device to be verified, similar to performing a one-time logical hash on the operating system fingerprint features, the final verification result cannot be used to determine the validity of the operating system fingerprint of the device to be verified. By running a verifier with the same processing logic locally on the verification device, and inputting the operating system fingerprint as a parameter into the verifier, the verification result output by the verifier can be used to identify whether the detector detects the validity of the operating system fingerprint of the device to be verified. That is, when the operating system fingerprint of the device to be verified obtained by the detector matches the operating system fingerprint sent by the device to be verified, the verification result output by the detector is the same as the verification result output by the verifier, thus ensuring the verifiability of the one-time logical hash.

[0083] In the embodiments of this application, the device to be verified needs to execute the detector in kernel mode. If the source of the detector is untrusted, the device to be verified will not easily execute an untrusted program in kernel mode; otherwise, the operating system may be maliciously attacked or damaged. Therefore, the detector needs to be generated by a trusted network and be verifiable before the device to be verified will run the detector as a trusted program in kernel mode. The trusted network is a network composed of network nodes that are sufficiently trusted by both the device to be verified and the verification device. The trusted network provides a trusted detector for the device to be verified and a trusted verifier for the verification device.

[0084] In some embodiments of this application, when the first device sends the fingerprint of the first operating system, it includes a detector source requirement, which describes the trust network that generated the detector. Alternatively, if it is authentication between network nodes that build the trust network, the detector source requirement is empty; in this case, the detector and verifier are automatically generated directly by the verification node. The first device trusts its designated trust network. If the second device also trusts the trust network, then the trust network is trusted by both parties, and the detector and verifier generated through this trust network are considered trustworthy by both parties.

[0085] In a trust network, the generation, execution, and verification of any code are restricted to a verifiable, fully controlled execution environment. In some embodiments of this application, the trust network can be a trust network built by the IoT device itself, or an existing trust network can be used, such as the VoidChain public chain.

[0086] Furthermore, the construction process of the trust network, the generation methods of the detector and the validator will be described in detail later.

[0087] In step S103, the second device 200 sends the first detector to the first device 100.

[0088] In some embodiments of this application, before the verification of the device to be verified is successful, the data packets sent by both parties are digitally signed. The data packets include a public key for signing and signature information, thereby preventing illegal tampering during the transmission of the data packets.

[0089] Specifically, the second device digitally signs the first detector, and then encapsulates the signing public key, signing information, and the first detector into a data packet and sends it to the first device.

[0090] In step S104, the first device 100 executes the first detector in kernel mode to obtain the first verification result and the first communication key.

[0091] In some embodiments of this application, before executing the first detector, the first device checks whether the source of the first detector meets the detector source requirements. If it does, the first detector is executed; otherwise, the first detector is refused to be executed.

[0092] Here, the first detector obtains the operating system fingerprint corresponding to the first device, performs random logic processing, and outputs the first verification result and the first communication key during the calculation process. The first communication key is used to encrypt the data sent by the first device to the second device after the second device successfully verifies the first device, and to decrypt the data sent by the second device to the first device.

[0093] In step S105, the first device 100 sends the first verification result to the second device 200.

[0094] In step S106, the second device 200 executes the first verifier in user mode to obtain the second verification result and the second communication key.

[0095] Here, the random processing logic of the first verifier is the same as that of the first detector. The second device executes the first verifier in user mode with the first operating system fingerprint as a parameter, and outputs the second verification result and the second communication key during the calculation process.

[0096] In step S107, the second device 200 determines whether the first verification result and the second verification result are the same.

[0097] Here, if the first verification result is the same as the second verification result, it means that the operating system fingerprint of the first device obtained by the first detector is the same as the first operating system fingerprint sent to the second device. The operating system of the first device is the operating system it claims to be, and it is clean and trustworthy. Therefore, the second device successfully authenticates the first device and trusts the first device.

[0098] If the first verification result differs from the second verification result, it indicates that the operating system of the first device is not the operating system it claims to be, and there is a problem. Therefore, the second device fails to authenticate the first device.

[0099] After the second device successfully authenticates the first device, the first device needs to authenticate the second device to achieve two-way authentication and ultimately establish secure communication between the two devices. The authentication process between the first and second devices uses the same authentication method. Figure 2 This illustrates the process by which the first device 100 authenticates the second device 200:

[0100] In step S201, the second device 200 uses the second communication key to encrypt its own second operating system fingerprint and sends it to the first device.

[0101] After the second device successfully authenticates the first device, it can be determined that the first communication key and the second communication key are the same communication key. The first device and the second device can use this communication key to encrypt and decrypt transmitted data.

[0102] Therefore, the second device obtains its own second operating system fingerprint, encrypts the second operating system fingerprint using the second communication key, and sends it to the first device.

[0103] In step S202, the first device 100 uses the first communication key to decrypt the received encrypted second operating system fingerprint.

[0104] In step S203, the first device 100 generates a second detector and a second verifier through a trust network based on the fingerprint of the second operating system.

[0105] In step S204, the first device 100 uses the first communication key to encrypt the second detector and then sends it to the second device 200.

[0106] In step S205, the second device 200 uses the second communication key to decrypt the received encrypted second detector.

[0107] In step S206, the second device 200 executes the second detector in kernel mode to obtain the fourth verification result and the fourth communication key.

[0108] In step S207, the second device 200 uses the second communication key to encrypt the fourth verification result and sends it to the first device 100.

[0109] In step S208, the first device 100 uses the first communication key to decrypt the encrypted fourth verification result.

[0110] In step S209, the first device 100 executes the second verifier in user mode to obtain the third verification result and the third communication key.

[0111] In step S210, the first device 100 determines whether the third verification result and the fourth verification result are the same.

[0112] If the third verification result is the same as the fourth verification result, then the first device successfully authenticates the second device, and the first device trusts the second device.

[0113] Since the process of the first device authenticating the second device is similar to the process of the second device authenticating the first device, the specific content involved in steps S201 to S210 can be found in steps S101 to S107, and will not be repeated here.

[0114] After both parties successfully authenticate, the first device and the second device can communicate securely. Therefore, the first device uses the third communication key to encrypt and transmit data and sends it to the second device. The second device receives the encrypted data sent by the first device, decrypts it using the fourth communication key, and processes it.

[0115] In some embodiments of this application, the method for generating the first detector, the first verifier, the second detector, and the second verifier is the code DNA generation method.

[0116] Here, the code DNA generation method offers high security. The node sequence (i.e., code DNA) consists of multiple DNA nodes. These nodes sequentially process the input data randomly and output the results. The complete detector program can be dynamically determined based on the node sequence. The detector is jointly determined by the code DNA and fingerprint features; only identical code DNA and fingerprint features can generate a consistent detector version. Therefore, the detector can be dynamically generated using fingerprint features and code DNA to verify the security of the detector version sent by the device under test, thus ensuring the secure execution of the detector.

[0117] The detector and verifier have basically the same processing logic for fingerprint features. The difference is that when verifying fingerprint features, the detector obtains the real operating system fingerprint features from the operating system kernel, while the verifier obtains them from the received operating system fingerprint parameters. Therefore, if the real operating system fingerprint features obtained by the detector are the same as the operating system fingerprint features sent by the device to be verified, the final verification result will definitely be consistent with the verification result of the verifier.

[0118] The more nodes in the code DNA, the safer the detector, but too many nodes will also increase the length of the detector, so it is best to use an appropriate number of nodes.

[0119] For example, a DNA node can be defined as follows:

[0120] Struct DnaNode{

[0121] Uint no; / / Fingerprint array index 0 is the kernel fingerprint feature

[0122] char rand_op; / / Random operation operators 0:+, 1:-, 2:*, 3: / , 4: Release communication key (ensure that there is only one DNA node operator in the code DNA that releases the communication key).

[0123] Uint rand; / / Random

[0124] }

[0125] The code function prototype generated by DNA nodes can be defined as follows:

[0126] Uint readFinger(char* path); / / Get fingerprint features

[0127] uint processDna(DnaNode*node,char* path, uint prv); / / The output of each node is used as the input of the next node.

[0128] In addition, since the detector and the verifier run in different environments—the detector runs in kernel mode while the verifier runs in user mode—there are slight differences in their compilation.

[0129] Figure 5 This application illustrates the process of IoT device B authenticating IoT device A in some embodiments, such as... Figure 5 As shown, A sends its fingerprint features to B, and B sends its fingerprint features to node B in the trust network. Node B generates a detector and a verifier, and broadcasts the detector hash and code DNA. It then returns the generated detector and verifier to B. B sends the detector to A, and A calculates the detector hash and sends it to node A in the trust network. Node A finds the code DNA through the detector hash, generates a detector locally, and if the detector hashes match, the check is passed. Once the detector is confirmed to be valid, A executes the detector, and B executes the verifier. The outputs of the two are compared, and if they match, B trusts A.

[0130] In the embodiments of this application, the trust network is the foundation of the entire IoT device's trusted and secure communication, equivalent to a root of trust. Ensuring the trust network's reliability is the most basic requirement. The root of trust is the very front of the trust chain, which can also be said to be the very front of the IoT device's operating system environment loading chain. Only when the root is trustworthy can the trustworthiness of subsequent loaded modules or processes of the operating system be guaranteed.

[0131] Figure 3 This application illustrates various modes of the operating system for IoT devices in some embodiments, such as... Figure 3 As shown, Ring 0 is kernel mode, where the operating system kernel runs; Ring 3 is user mode; and Ring -1 is the highest privilege mode, where the virtual machine monitor (Hypervisor) or virtual machine manager (VMM) runs.

[0132] Here, the root of trust for the operating system is Ring -1. Only by ensuring the trustworthiness of Ring -1 can the trustworthiness of the operating system kernel, loaded modules, or processes in the upper Ring 0 be guaranteed.

[0133] Hardware trust roots such as TPM sign the content of modules in Ring-1 using a built-in private key. Programs in Ring-0 or Ring-3 layers are remotely verified through the cloud to determine the trustworthiness of the current program in the Ring-1 layer.

[0134] The root of trust in this embodiment is a software root of trust, which achieves a similar effect to a hardware root of trust by dynamically customizing the program in the Ring-1 layer and verifying the legitimacy of the Ring-1 layer through local-remote interaction.

[0135] In the embodiments of this application, the network nodes in the trust network include virtual machine monitors running in the highest privilege state (Ring-1 layer), that is, IoT devices must have a Hypervisor layer.

[0136] In the embodiments of this application, the Hypervisor layer in the IoT device is not a static root of trust, but a "continuously proven root of trust" constructed through dynamic generation, self-verification, and runtime challenge mechanisms. If an attacker wants to forge this root of trust, he must simulate the complete execution environment and its dynamic behavior in real time within a very short time window, which raises the attack cost to a level that is almost infeasible in engineering.

[0137] The node operating system environment architecture of the trust network in the embodiments of this application is as follows:

[0138] +---------------------------------------------------+

[0139] | Guest OS 1 | Guest OS 2 | ← Running in non-privileged mode

[0140] +---------------------------------------------------+

[0141] | Hypervisor (VMM) | ← Runs in the highest privileged state

[0142] +---------------------------------------------------+

[0143] | Physical hardware (CPU, memory, disk, network card) |

[0144] +---------------------------------------------------+

[0145] To enable monitoring of the kernel, the CPU provides hardware-level privileged rings. Without virtualization, the kernel exclusively occupies Ring 0. With the introduction of virtualization, the hypervisor occupies Ring 0 or a higher level of Root Mode, forcing the Guest OS kernel to run with "downgraded privileges".

[0146] +---------------------------------------------------+

[0147] | Ring 3 (User Space) | Guest App | Guest App |

[0148] +---------------------------------------------------+

[0149] | Ring 0 (Kernel Mode) | Guest OS Kernel (Monitored Entity) | ← Originally intended to exclusively occupy Ring 0, now "degraded" in privileges.

[0150] +-------------------+-------------------------------+

[0151] | Ring -1 (Monitoring Layer) | Hypervisor | ← The "True Kernel" that actually controls the hardware

[0152] +---------------------------------------------------+

[0153] | Physical CPU Hardware |

[0154] +---------------------------------------------------+

[0155] The trust network in this embodiment can theoretically guarantee the security of the upper-layer operating system, achieving near-certain security, because it can come very close to ensuring the security of the Hypervisor.

[0156] Furthermore, in some embodiments of this application, the Hypervisor possesses static protection that prevents binary readability and dynamic protection that makes debugging impossible. It can also ensure that only one Hypervisor is running through the Hypervisor's memory address distribution characteristics, and can identify whether other malicious Ring-1 layer programs are nested and loaded. Since the Hypervisor in this application's embodiments is dynamically generated, its lifespan is extremely short, and debugging and memory scanning are prohibited, the probability of cracking is infinitesimally small, making it sufficiently secure.

[0157] In a trusted network, the operating system fingerprint of a network node is simultaneously scanned by the Hypervisor at the Ring-1 layer, achieving dual locking.

[0158] Therefore, once the root of trust is guaranteed to be trustworthy, the entire operating system can be made completely trustworthy.

[0159] Here, the initial trust network consists of two mutually authenticated network nodes, and the growth of the trust network follows a similar method. The construction of the trust network follows a trust model in which the network node that initiates the connection unconditionally trusts the other node. This ensures that the trust network has no security vulnerabilities because when the node initiates the connection, the chosen other node already knows the identity of the node that initiated the connection. Once the node that initiated the connection passes the verification of the other node, it can be trusted. In this way, the other node can confidently execute the detector sent by the node that initiated the connection, completing the two-way authentication process.

[0160] The construction of a trust network can include two phases: the startup phase and the expansion phase. The startup phase involves two network nodes authenticating each other to establish a minimal trust network. The expansion phase involves adding new network nodes to the trust network. The authentication process for network nodes differs slightly between the two phases. The following explanation uses the construction of a trust network by the first and second network nodes as an example.

[0161] In some embodiments of this application, the construction process of the trust network during the startup phase includes the following steps:

[0162] 1) The first network node sends its own first node operating system fingerprint and the identity challenge information of the first virtual machine monitor to the second network node;

[0163] Here, the first virtual machine monitor is a virtual machine monitor (Hypervisor) running on the first network node. The identity challenge information may include, but is not limited to, a preset value corresponding to the Hypervisor and signature information that uses the private key in the Hypervisor to sign the preset value.

[0164] 2) The second network node authenticates the first network node's Hypervisor based on the identity challenge information of the first virtual machine monitor;

[0165] 3) If the Hypervisor of the first network node is authenticated, the second network node performs operating system fingerprint authentication on the operating system fingerprint of the first node.

[0166] 4) If the first node's operating system fingerprint is authenticated, the second network node determines that the first network node has been authenticated.

[0167] 5) The second network node sends its own second node operating system fingerprint and second virtual machine monitor identity challenge information to the first network node, so that the first network node can perform Hypervisor authentication and operating system fingerprint authentication on the second network node;

[0168] Here, the second virtual machine monitor is the virtual machine monitor (Hypervisor) running on the second network node.

[0169] 6) If the second network node passes Hypervisor authentication and operating system fingerprint authentication, the first network node determines that the second network node has passed authentication, and the trusted network is built during the startup phase.

[0170] The completed trust network consists of a first network node and a second network node, which is the smallest trust network.

[0171] In some embodiments of this application, the second network node authenticates the first network node's Hypervisor based on the identity challenge information of the first virtual machine monitor, including the following steps:

[0172] 1) The second network node checks whether the identity challenge information of the first virtual machine monitor is stored locally;

[0173] Specifically, the second network node checks whether the identity challenge information of the first virtual machine monitor is consistent with the corresponding identity challenge information stored locally. For example, it can check whether the preset value in the identity challenge information of the first virtual machine monitor is the same as the preset value in the corresponding identity challenge information stored locally, and obtain the public key based on the signature information in the identity challenge information of the first virtual machine monitor, and then check whether the obtained public key is the same as the public key in the corresponding identity challenge information stored locally, etc.

[0174] 2) If the identity challenge information of the first virtual machine monitor is not stored in the second network node, the second network node generates a third virtual machine monitor based on the operating system fingerprint of the first node; otherwise, the first network node's Hypervisor authentication is successful.

[0175] Here, similar to the generation methods of detectors and verifiers, a third virtual machine monitor is generated using the code DNA generation method. The generated third virtual machine monitor may include, but is not limited to, a preset value generation module and a signature module. The processing logic of the preset value generation module is similar to that of the detector; it is used to generate a preset value based on the operating system fingerprint of the first node and random logic. This preset value is generated randomly and remains fixed after generation, corresponding to the Hypervisor. The signature module is used to sign the preset value using a built-in private key and output the signature information.

[0176] The implementation code of the preset value generation module and the signature module has been white-box encapsulated and obfuscated to avoid the possibility of being cracked or deceived in the short term.

[0177] In addition, the second network node also locally generates a preset value acquisition module corresponding to the preset value generation module in the third virtual machine monitor. The processing logic of the preset value acquisition module is similar to that of the verifier, and it is used to obtain the corresponding preset value based on the operating system fingerprint of the first node. The second network node also locally stores the public key corresponding to the private key built into the third virtual machine monitor.

[0178] 3) The second network node sends the third virtual machine monitor to the first network node;

[0179] 4) The first network node restarts and loads the third virtual machine monitor:

[0180] Here, the first network node loads the third virtual machine monitor to execute its preset value generation module and signature module, thereby obtaining the identity challenge information of the third virtual machine monitor.

[0181] 5) The first network node re-requests Hypervisor authentication from the second network node.

[0182] Here, the first network node sends the identity challenge information of the third virtual machine monitor to the second network node, requesting re-authentication of the first network node's Hypervisor. Since the third virtual machine monitor is generated by the second network node and the second network node stores the corresponding identity challenge information locally, the second network node will inevitably succeed in authenticating the identity challenge information of the third virtual machine monitor, thus causing the first network node's Hypervisor authentication to pass.

[0183] Using the above methods, neither hardware nor malicious Ring-1 layer programs can forge or deceive the authentication process without cracking the Hypervisor's built-in private key, thus ensuring that the second network node can accurately identify whether the first network node's Hypervisor is the Hypervisor it expects.

[0184] The Hypervisor also employs a white-box obfuscation method to hide the preset value generation module and the built-in private key, and ensures sufficient security through time-limited control.

[0185] In some embodiments of this application, the second network node performs operating system fingerprint authentication on the operating system fingerprint of the first node, including the following steps:

[0186] 1) The second network node generates a first node detector and a first node verifier based on the first node's operating system fingerprint;

[0187] 2) The second network node sends the first node detector to the first network node;

[0188] 3) The first network node executes the first node detector in kernel mode and obtains the execution result of the first node;

[0189] 4) The first network node sends the execution result of the first node to the second network node;

[0190] 5) The second network node executes the first node's verifier in user mode based on the first node's operating system fingerprint and obtains the execution result of the second node;

[0191] 6) If the execution results of the first node and the second node are the same, the second network node determines that the first network node has passed authentication.

[0192] During the expansion phase of the trusted network, newly connected network nodes trust the network's hypervisor by default. Therefore, during the two-way authentication process, new network nodes do not authenticate the hypervisors of nodes in the trusted network. After successful authentication, new network nodes obtain the hypervisor characteristic information of each network node from the trusted network.

[0193] Furthermore, nodes within the trust network authenticate each other without performing Hypervisor authentication. Nodes entering the trust network can trust the Hypervisors of other nodes in the network by default, without needing to perform repeated authentication.

[0194] Because Hypervisor authentication causes the other node to restart and reload, leading to network instability, Hypervisor authentication should be minimized while ensuring the security of nodes in the trusted network.

[0195] By using a hypervisor as the root of trust, software security can approach the effectiveness of secure hardware. With proper code implementation, it can even surpass hardware security in overall performance. This is because software security not only achieves near-unsolvable security in theory, but also avoids maintenance vulnerabilities associated with secure hardware and verification vulnerabilities on cloud servers, thus approaching deterministic security.

[0196] Unlike traditional open operating systems, the IoT device operating system in this embodiment can solidify the runtime environment configuration through kernel fingerprinting. All dynamically loaded modules throughout the entire lifecycle are pre-set by the operating system kernel. As long as the dynamic detector locks the kernel fingerprint, the entire runtime environment is completely locked with real-name authentication.

[0197] In some embodiments of this application, the operating system of IoT devices has been customized for security purposes. This customization differs significantly from the security concepts adopted by existing IoT device vendors, and is reflected in the following three aspects:

[0198] 1. Real-name registration and confirmation

[0199] The IoT operating system in this embodiment is minimally modified, supports self-locking of the verification name within the hash of each module, and supports controllable upgrades in the future. At the same time, all interfaces that are easily exploited by rootkits, such as network and redundant kernel modules, have been removed.

[0200] 2. Self-proving

[0201] By embedding the preset values ​​and signature module's dual white-box identity challenge information into the operating system kernel, it is ensured that the operating system kernel of each IoT device can be accurately and reliably verified by remote IoT devices.

[0202] 3. Operating system kernel feature management

[0203] Each loaded module of the operating system is accurately identified and fully recorded, maintaining a unique hash characteristic for the entire runtime environment.

[0204] For example, operating system kernel features can be defined as:

[0205] struct FingerItem{

[0206] char path

[256] ; / / Module path

[0207] char hash

[32] ; / / Fingerprint characteristics (content HASH)

[0208] Char Cstatus; / / Control status 0x1 Register characteristics 0x2 Can start child processes to ignore characteristics 0x4 Can add fingerprint characteristic items

[0209] Char Ftype; / / Fingerprint feature type 1: Kernel image 2: Kernel module 3: Process

[0210] struct FingerItem g_FDefined = {,,,,,,}; / / Pre-loaded fingerprint features

[0211] struct FingerItem* g_RunFeatures; / / Run fingerprint features

[0212] }

[0213] Figure 4 This application illustrates the security control flow of the IoT device operating system kernel startup process in some embodiments, such as... Figure 4 As shown, when a process starts, the kernel first calculates the fingerprint of the starting process, then checks if the fingerprint is in the pre-installed fingerprint database. If it is, it further checks if the fingerprint matches; otherwise, it checks if the parent process is in the pre-installed fingerprint database. If the parent process is in the database, it determines whether to allow the process to start. If so, it further determines whether to register the process in the runtime fingerprint database; otherwise, it intercepts and exits. If it is confirmed that the process needs to be registered in the runtime fingerprint database, the runtime fingerprint is registered and the process starts normally; otherwise, the process starts normally. Additionally, if the fingerprint matches, the runtime fingerprint is registered and the process starts normally; otherwise, it intercepts and exits.

[0214] In some embodiments of this application, the IoT operating system can be customized either through a self-designed approach or automatically generated via a trusted network. In the self-designed approach, the operating system for IoT devices can be customized for specific purposes based on fingerprint feature management technical standards.

[0215] In the automatic generation method via a trust network, a trusted operating system (including fingerprint feature management) is generated through a trust network such as VoidChain. Based on keywords and pre-installed fingerprint feature library prompts, AI performs deep trimming and customization of the operating system.

[0216] The advantages of automated generation are: the source code of the generated IoT operating system is unknown to anyone; the operating system is more professionally and thoroughly customized, with a smaller kernel; and the operating system for IoT devices is easier to popularize and personalize. The associated risk lies in code vulnerabilities, which can be controlled by having AI automatically perform functional testing after the operating system is generated, while a trusted network can formulate a complete automated detection task.

[0217] In some embodiments of this application, the operating system kernel of the first device and the operating system kernel of the second device include a fingerprint feature setting interface and a fingerprint feature query interface. The fingerprint feature setting interface is used to set a new fingerprint feature after the fingerprint feature of the operating system is updated, and the fingerprint feature query interface is used to obtain the fingerprint of the first operating system or the fingerprint of the second operating system.

[0218] Here, the fingerprint feature setting interface allows for the independent expansion of the programs that the current operating system kernel can run, improving the availability of the operating system. If the fingerprint feature setting interface is not provided, once a fingerprint feature in the operating system is upgraded or a new program needs to be run, the operating system will need to be reinstalled, causing difficulties for practical applications.

[0219] In addition, the fingerprint feature query interface can easily obtain the fingerprint features of the current operating system and provide them to the verification device to facilitate authentication between IoT devices.

[0220] In some embodiments of this application, VoidChain can be used as a trust network. VoidChain's fundamental contribution to the blockchain mainnet lies in proposing an architecture called "Vacuum Network + AI Network Robot". This architecture completely reconstructs the blockchain mainnet from four dimensions: security foundation, consensus mode, architectural form, and functional extension, in order to solve the classic "blockchain trilemma" problem that scalability, decentralization, and security cannot be achieved simultaneously.

[0221] The five core contributions of VoidChain are detailed below:

[0222] 1. Introduce a "vacuum network" to reconstruct the security boundary of the main network.

[0223] Contribution: Transform the mainnet node operating environment from an open Internet into a closed, isolated "vacuum" environment that is strictly verified and managed by AI robots.

[0224] Specific manifestations: Environmental consistency: All nodes run completely identical system images and code, like clones, eliminating the possibility of nodes acting maliciously from the source.

[0225] External stealth: The network does not respond to unknown connections, eliminating network layer attack surfaces such as DDoS and port scanning.

[0226] Internal transparent encryption: Inter-node communication is automatically encrypted at the quantum level, which is transparent to the application layer.

[0227] 2. Propose POT consensus, a new path to break the "impossible triangle".

[0228] Contribution: Abandoning the traditional PoW (i.e., competition for computing power) and PoS (i.e., competition for stake), it creatively proposed the POT (Proof of Trust) consensus.

[0229] Specifically, consensus no longer relies on resource consumption or token staking, but is dynamically verified and trusted by decentralized AI network robots that evaluate node behavior and the environment.

[0230] The theoretical result is that while maintaining a high degree of decentralization and security, extremely high processing speeds can be achieved, for example, a single shard can reach hundreds of thousands of TPS.

[0231] 3. Construct an "infinite metaspace" architecture, with the mainnet becoming a "chain factory".

[0232] Contribution: Upgrade the mainnet from a single chain to an infrastructure foundation that can generate and manage countless independent subchains (called "metaspace").

[0233] Specific manifestations: Dynamic Metaspace: The system's AI automatically schedules node resources to achieve load balancing and solve the problem of single-chain state explosion.

[0234] Static Metaspace: Allows enterprises or individuals to generate a completely independent subchain with customizable rules with a single click, meeting the combined needs of applications for autonomy, data privacy, and interoperability.

[0235] 4. Reconstruct cross-chain security to achieve atomic swaps with "trustless third parties".

[0236] Contribution: By utilizing the closed and trusted execution environment provided by the "vacuum network", the "man-in-the-middle risk" brought about by the reliance on multi-signature witnesses or relay chains in traditional cross-chain bridges is fundamentally eliminated.

[0237] Specifically, cross-chain transactions are executed in a closed environment verified by an AI bot, similar to a "physical smart contract." The process does not require trust in any external third party, achieving true trustless cross-chain functionality.

[0238] 5. Extend "chain-to-end" capabilities and launch edge trust machines and closed-loop spaces.

[0239] Contribution: By using edge trust mechanisms, the security and control capabilities of the mainnet are extended from on-chain to IoT terminals and the off-chain world.

[0240] Specifically, any device can access the "closed-loop space" managed by the main network through the edge trust machine, achieving logical isolation and automatic encrypted communication between devices.

[0241] This allows the VoidChain mainnet to transcend its role as a "ledger" and become the foundational operating system for managing the security of the Internet of Things, providing a complete solution for the trusted on-chaining of IoT data.

[0242] VoidChain's contribution to the blockchain mainnet is paradigmatic. It aims to upgrade the mainnet from a traditional, ledger-focused "global ledger" to a "secure space operating system" capable of creating, managing, and securing countless trusted, isolated networks. Its core is to enforce environmental trust through technological means (AI and closed networks), thereby theoretically bypassing the dilemma of traditional blockchains having to compromise between performance, decentralization, and security. Figure 6 The technical architecture of VoidChain in some embodiments of this application is shown, and its comparison with traditional solutions in several aspects is illustrated.

[0243] Figure 7 This illustration shows a closed-loop security space indicator system in some embodiments of this application. The closed-loop space is a revolutionary architectural change for IoT security, relying on security protocols and the VoidChain mainnet. Its core impact is to transform the traditional passive security model based on "boundary defense" and "feature detection" into an active space management system based on "logical isolation" and "environment trustworthiness".

[0244] The three core impacts of closed-loop spaces on IoT security are as follows:

[0245] 1. Fundamental impact: From "open network" to "stealth space", eliminating the external attack surface.

[0246] Traditional IoT devices are exposed to public IP addresses, making them extremely vulnerable to scanning, detection, and attacks. Closed-loop environments completely change this fundamental environment.

[0247] Impact Mechanism: Devices within the closed-loop space "do not accept any connections from unknown IPs" and "the network is completely isolated from the outside world," which means that the devices are logically "invisible" from the open Internet.

[0248] Security Value: Attack Entry Points Disappear: Hackers are unable to discover targets through regular network scans, rendering remote vulnerability exploitation and DDoS attacks impossible.

[0249] Zero-day vulnerability threat reduced: Even if a device has an undisclosed vulnerability, the risk of it being exploited is greatly reduced because external parties cannot actively connect to it.

[0250] 2. Structural impact: Establish "identity- and policy-based micro-segmentation" to achieve internal self-security.

[0251] After addressing external threats, the closed-loop space has built sophisticated access control internally, changing the dangerous state of "mutual trust by default once connected to the network" among IoT devices.

[0252] Impact Mechanism: The concept of a "Mac, IP, Space three-dimensional world" is introduced. Device communication not only requires an IP address, but also must be in the same space or obtain explicit cross-space authorization. Communication within the space is automatically and transparently encrypted, and access outside the space is prohibited by default.

[0253] Security Value: Lateral Penetration is Blocked: Even if a single device is physically compromised or breached from within, attackers cannot use it as a springboard to attack other devices within the same local area network but belonging to different spaces, effectively curbing the lateral spread of attacks.

[0254] Least privilege access: By configuring access policies through the blockchain mainnet, precise peer-to-peer authorization between devices and applications can be achieved, adhering to the zero-trust principle.

[0255] 3. Operational impact: Decoupling security and management enables transparent and decentralized operations and maintenance. Traditional IoT security solutions are complex and often conflict with device functions. Closed-loop space, through its architectural design, makes security management simple, transparent, and independent of centralized authority.

[0256] Influence mechanism:

[0257] Transparency: Communication between devices within the space requires "no adjustments or configurations to any applications," and security capabilities are provided by the underlying network layer.

[0258] Decentralized maintenance: Device maintenance is carried out by establishing an encrypted channel on a specific device through "blockchain authorization to a certain account". This replaces the traditional VPN or centralized bastion host. The audit trail is clearly recorded on the blockchain and there is no need to trust a third-party operation and maintenance team.

[0259] Security benefits: Reduced deployment complexity: Enterprises do not need to develop encryption functions or modify protocols for each IoT application.

[0260] Trustworthy and controllable operation and maintenance rights: The granting, use and revocation of maintenance rights are managed by blockchain smart contracts throughout the entire process. They are tamper-proof and traceable, which solves the risk of internal personnel abusing their rights or the operation and maintenance channels being breached.

[0261] The secure communication method for IoT devices provided in this application enables visual communication in the Internet of Things (IoT). The fully decentralized vacuum network environment achieved through security protocols also provides a complete infrastructure for blockchain technology. Since blockchain is inherently a standard privacy computing network, all the problems that previously hindered the development of blockchain technology will no longer exist, bringing the following disruptive impacts to its development:

[0262] 1. Secure and reliable digital wallet.

[0263] 2. Secure and reliable cross-chain bridge.

[0264] 3. A secure, decentralized, full-chain exchange.

[0265] 4. With the advent of the Web3 management era, IoT devices can enter various private cyberspaces like a social media circle, without the need for any intermediaries, authority, or control. This makes cyberattacks extremely difficult and unprofitable.

[0266] 5. The blockchain world trilemma is no longer a problem, achieving the highest level of decentralization and the fastest processing speed.

[0267] 6. Blockchain has become the most common and widespread information infrastructure.

[0268] In summary, the solution provided in this application enables two-way authentication and key negotiation for IoT devices through a pure software approach. This approach achieves zero-trust and open-source-level security, resulting in extremely high security. The authentication device sends the operating system fingerprint of the device to be verified to the authentication device. The device to be verified executes the detector in kernel mode and sends the verification result to the authentication device. The authentication device compares the received verification result with the verification result obtained by executing the authentication device in user mode. If they match, the device to be verified passes the authentication. The same method is then used to authenticate the authentication device. If successful, both parties are successfully authenticated. The key obtained during the authentication process is then used for secure communication. Thus, two-way authentication and key negotiation for IoT devices are achieved through pure software, enabling zero-trust and open-source-level security with extremely high security levels.

[0269] It should be noted that this application can be implemented in software and / or a combination of software and hardware, for example, using an application-specific integrated circuit (ASIC), a general-purpose computer, or any other similar hardware device. In one embodiment, the software program of this application can be executed by a processor to implement the steps or functions described above. Similarly, the software program of this application (including related data structures) can be stored in a computer-readable recording medium, such as RAM memory, a magnetic or optical drive, a floppy disk, or similar devices. Furthermore, some steps or functions of this application can be implemented in hardware, for example, as circuitry that cooperates with a processor to perform the various steps or functions.

[0270] In a typical configuration of this application, both the terminal and the network device include one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0271] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0272] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include non-transitory computer-readable media, such as modulated data signals and carrier waves.

[0273] Furthermore, a portion of this application can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to this application through the operation of the computer. The program instructions invoking the methods of this application may be stored in a fixed or removable recording medium, and / or transmitted via a data stream in a broadcast or other signal carrying medium, and / or stored in the working memory of a computer device operating according to the program instructions. Here, one embodiment of this application includes a device comprising a memory for storing computer program instructions and a processor for executing the program instructions, wherein, when the computer program instructions are executed by the processor, the device is triggered to run methods and / or technical solutions based on the foregoing embodiments of this application.

[0274] It will be apparent to those skilled in the art that this application is not limited to the details of the exemplary embodiments described above, and that this application can be implemented in other specific forms without departing from the spirit or essential characteristics of this application. Therefore, the embodiments should be considered exemplary and non-limiting in all respects, and the scope of this application is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be embraced within this application. No reference numerals in the claims should be construed as limiting the scope of the claims. Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in the apparatus claims may also be implemented by a single unit or device in software or hardware. The terms "first," "second," etc., are used to indicate names and do not indicate any particular order.

Claims

1. A secure communication method for an Internet of Things (IoT) device, used in a first device, characterized in that, The method includes: The system sends its own first operating system fingerprint to the second device, wherein the operating system fingerprint includes the fingerprint characteristics of the kernel image, the fingerprint characteristics of the kernel dynamically loaded module, and the fingerprint characteristics of the kernel boot process. The device receives a first detector sent by the second device, wherein the first detector is generated by the second device through a trusted network based on the first operating system fingerprint; The first detector is executed in kernel mode to obtain a first verification result and a first communication key, and the first verification result is sent to the second device.

2. The method according to claim 1, characterized in that, The method also includes: Receive the encrypted second operating system fingerprint sent by the second device and decrypt it using the first communication key; A second detector and a second verifier are generated through a trust network based on the fingerprint of the second operating system. The second detector is encrypted using the first communication key and then sent to the second device; The second verifier is executed in user mode to obtain the third verification result and the third communication key; Receive the encrypted fourth verification result sent by the second device and decrypt it using the first communication key; If the third verification result is the same as the fourth verification result, the data is encrypted and transmitted using the third communication key and sent to the second device.

3. The method according to claim 1, characterized in that, The fingerprint feature includes multiple feature items, which at least include the following: path, content hash, control type, and feature type.

4. The method according to claim 3, characterized in that, The method also includes: Calculate a checksum for the content of each feature item in the fingerprint features; Accumulate the checksums corresponding to all the aforementioned feature items; The accumulated result is hashed to determine the HASH value corresponding to the fingerprint feature.

5. The method according to claim 1, characterized in that, The method for generating the first detector, the first verifier, the second detector, and the second verifier is the code DNA generation method.

6. The method according to claim 1, characterized in that, The network nodes in the trust network include virtual machine monitors running in the highest privilege state.

7. The method according to claim 6, characterized in that, The construction process of the trust network during the startup phase includes: The first network node sends its own first node operating system fingerprint and the identity challenge information of the first virtual machine monitor to the second network node, wherein the identity challenge information includes a preset value corresponding to the first virtual machine monitor and the signature information of the preset value; The second network node authenticates the first network node's Hypervisor based on the identity challenge information of the first virtual machine monitor; If the Hypervisor of the first network node is authenticated, the second network node performs operating system fingerprint authentication on the operating system fingerprint of the first node. If the first node's operating system fingerprint is authenticated through the operating system fingerprint, the second network node determines that the first network node has been authenticated. The second network node sends its own second node operating system fingerprint and second virtual machine monitor identity challenge information to the first network node, so that the first network node can perform Hypervisor authentication and operating system fingerprint authentication on the second network node. If the second network node passes Hypervisor authentication and operating system fingerprint authentication, the first network node determines that the second network node has passed authentication, and the trusted network is built during the startup phase.

8. The method according to claim 7, characterized in that, The second network node authenticates the first network node's Hypervisor based on the identity challenge information of the first virtual machine monitor, including: The second network node checks whether the identity challenge information of the first virtual machine monitor is stored locally; If the identity challenge information of the first virtual machine monitor is not stored in the second network node, the second network node generates a third virtual machine monitor based on the operating system fingerprint of the first node; otherwise, the Hypervisor authentication of the first network node is successful. The third virtual machine monitor includes a preset value generation module and a signature module. The preset value generation module is used to generate a preset value based on the operating system fingerprint of the first node and random logic. The signature module is used to sign the preset value based on the built-in private key and output signature information. The second network node sends the third virtual machine monitor to the first network node; The first network node restarts and loads the third virtual machine monitor; The first network node re-requests Hypervisor authentication from the second network node.

9. A secure communication method for an Internet of Things (IoT) device, used in a second device, characterized in that, The method includes: Receive a first operating system fingerprint sent by a first device, wherein the operating system fingerprint includes the fingerprint features of the kernel image, the fingerprint features of the kernel dynamically loaded module, and the fingerprint features of the kernel boot process; Based on the first operating system fingerprint, a first detector and a first verifier are generated through a trust network; Send the first detector to the first device; Receive the first verification result sent by the first device; Execute the first verifier in user mode to obtain the second verification result and the second communication key; If the first verification result is the same as the second verification result, the second operating system fingerprint is encrypted using the second communication key and sent to the first device.

10. The method according to claim 9, characterized in that, The method includes: Receive the encrypted second detector sent by the first device and decrypt it using the second communication key; The second detector is executed in kernel mode to obtain the fourth verification result and the fourth communication key; The fourth verification result is encrypted using the second communication key and then sent to the first device. The encrypted transmission data sent by the first device is received, and decrypted and processed using the fourth communication key.

Images