Method for remotely verifying system environment of opposite side by trusted node

Abstract

The invention aims to solve the technical problems that nodes in a trusted network do not depend on the support of any third party, whether a node system environment of the opposite party is trusted or not can be absolutely and accurately verified, and when the trusted nodes are connected with each other, a decentralized trusted machine technology (citation of a basic technology with a patent application number of 2020111511913) is utilized, so that the reliability of the trusted nodes is improved. A detector and a verifier are automatically and dynamically generated, the detector sends the result to an opposite host for operation, and if the operation result is completely consistent with the execution result of the verifier of the host, the opposite system environment passes verification and can be trusted, and whether a node system environment is trusted or not is generally detected, so that a very large risk challenge exists. Even if the Trojan horse virus exists in a system environment, the Trojan horse virus is extremely easy to be cheated and interfered by Trojan horse hackers, particularly rootkit cheating, because whether the Trojan horse virus exists in the system environment or not cannot be predicted before a detector is executed, and if the Trojan horse virus exists, whether the current detector can absolutely identify the Trojan horse virus or not is an uncertain problem. The method is a method for absolutely and accurately verifying whether the opposite node system environment is credible or not, once the verification method is established, a great contribution is made to the block chain main network technology, and the block chain main network can run in an absolutely credible private network environment.

Description

Technical Field

[0001] The present invention relates to a technology for remotely identifying the identity of a counterparty through trusting network communication. Background Art

[0002] Trusted networks, especially privacy computing, not only automatically enter the encrypted world for network communications, but also hope that each node running the program is absolutely safe and trustworthy. Currently, TEE technology uses a kind of trusted network communication that is achieved through specific hardware support and combined with encryption algorithms. However, the deployment technology and cost of such a network environment are relatively high, and the participation of a third party also makes the privacy and security protection conditional. If there is a technology that does not rely on any third party, is transparent and compatible with the current application environment, and can absolutely realize a privacy network isolation space, it will bring a new operating platform for privacy computing. To realize an absolute privacy network space, it is necessary to provide the ability to verify each other's environment, and to be able to absolutely and accurately verify that the other party's operating environment is trustworthy without being deceived. There is currently no similar technology. Summary of the invention

[0003] For the sake of convenience, the system environment mentioned below refers to all processes running on a node, including the operating system and applications.

[0004] For the sake of convenience, the rootkit mentioned below refers to a special type of malware whose function is to hide itself and designated files, processes, network links and other information on the installation target. It is more common to see that rootkits are generally used in combination with other malicious programs such as Trojans and backdoors.

[0005] For the sake of convenience, the blocking system environment mentioned below refers to the driver layer module filtering from files, processes and networks, prohibiting the loading of all unknown modules and the connection of unknown network terminals.

[0006] The technical problem to be solved by the present invention is that nodes in a trust network can accurately verify whether the system environment of the other node is trustworthy without relying on any third-party support. When the trust nodes are connected to each other, the decentralized trust machine technology (the basic technology of the referenced patent application number: 2020111511913) is used to dynamically generate detectors and verifiers autonomously. The detector is sent to the other host for operation. If the operation result is completely consistent with the execution result of the local verifier, it means that the system environment of the other party has passed the verification and can be trusted. Usually, there is a very big risk challenge in detecting whether a node system environment is trustworthy, which is that it is extremely susceptible to deception and interference by Trojan hackers, especially rootkit deception, because before you execute the detector, you cannot predict whether there is a driver layer Trojan virus in the system environment. If there is a driver layer Trojan virus, whether the current detector can absolutely identify the existence of such a Trojan virus is an uncertain problem. The present invention is a method to achieve such absolute and accurate verification of whether the system environment of the other node is trustworthy. Once this verification method is established, it will be a huge contribution to the blockchain main network technology. The blockchain main network will be able to run in an absolutely trustworthy privacy network environment.

[0007] In order to solve the above technical problems, the technical solution of the present invention is as follows: A method for a trusted node to remotely verify a system environment of another node, comprising the following steps: The system environments of two nodes A and B in the trust network are known to both parties, and mutual authentication is performed when connecting.

[0008] Node A authenticates node B. Node A will use the security model and node B's system environment information to dynamically generate the corresponding detector and verifier. The detector is executed by the other party, and the verifier is executed locally. The two results are matched to confirm whether they are credible. The detector includes application layer module a, driver layer module b and boot layer module c. Application layer module a will return the final execution result of the detector to node A.

[0009] After receiving the detector sent by node A, node B starts the detector application layer module a.

[0010] The application layer module a will automatically load the driver layer module b and interact with each other.

[0011] When the driver layer module b is started, it will detect whether the current system environment is consistent with the system environment expected by node A. If there is a discrepancy, it will exit directly and the verification will fail. If all pass, node B will be immediately closed from the three dimensions of network, process and file at the driver layer, and the loading of all unknown modules will be prohibited.

[0012] While the driver layer b detects the system environment, it needs to identify the local rootkit-type malicious Trojan software. Once found, it will directly return failure. Considering that it may not be possible to completely identify the malicious hidden software, the boot layer c is injected afterwards, such as modifying track 0 and sector 0, and restarting node B at the same time. In this way, the boot layer module c can accurately detect and identify the static system environment. Because when the boot layer module c is running, the operating system has not yet started, so it will not be deceived or interfered by any malicious software.

[0013] After the boot layer module c completes the detection, it will save the result and hand over the control to the operating system. After the operating system is started, the driver layer b will be automatically loaded, so that its own detection results and the boot layer c results will be sent to the application layer a together. With the cooperation of the boot layer module c, even if the rootkit escapes the recognition of the driver layer module b, it cannot escape the detection of the boot layer module c, thus absolutely ensuring the accurate identification of the system environment.

[0014] After node A receives the detector result sent back by node B, it executes the verifier program locally. If the verifier output result is consistent with the result returned by node B, it means that the system environment of node B is trustworthy, otherwise the verification fails.

[0015] The process of node B verifying node A is completed by referring to the same logic as above.

[0016] In this way, the detector can absolutely accurately identify the system environment of the current node through the combination of the driving layer b and the guiding layer c, and will not be deceived or interfered by any known or unknown rootkits. The present invention realizes a method for a trusted node to remotely verify the other party's environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 Node A verifies Node B system environment flow chart. Implementation

[0018] The following is based on the attached Figure 1 Preferred embodiments of the present invention are given and described in detail to enable a better understanding of the implementation methods, functions and features of the present invention.

[0019] When node A verifies the system environment of node B, it first dynamically generates a verifier and a detector. The detector includes three modules: application layer module a, driver layer module b and boot layer module c. The detector is sent to node B.

[0020] After receiving the detector, node B first starts the detector application layer module a, and the application layer module a loads the driver layer module b. The driver layer module b detects the system environment at the system layer. If it finds that the system environment is inconsistent with what node A expects or that a rootkit-type program is running, it exits directly and the detection fails. If no problem is found, the system environment is blocked. In order to prevent the existence of unrecognized rootkit programs, it is necessary to continue to load the boot layer module c.

[0021] Loading the boot layer module c has two functions: 1) thoroughly verifying whether the system environment is clean, and 2) ensuring that the system runs in a real machine environment.

[0022] The reason why the detection result of the boot layer module c cannot be forged is that the driver layer module b has blocked the system environment. Therefore, if the boot layer module c detects that the system environment is clean, there is no way to get this result through hacking after starting the system. Only the application layer module a can send the results of the driver layer module b and the boot layer module c to node A.

[0023] After node A receives the detection result returned by the detector, it executes the verifier and compares it with the verifier result. If they match, it means that the system environment of node B is credible, otherwise the verification fails.

[0024] In this way, node A can remotely verify the system environment of node B. The driver layer module b and the boot layer module c guarantee each other, eliminating all possibilities of deception. The present invention realizes a method for absolutely accurately verifying whether the system environment of the other node is credible.

[0025] Obviously, numerous modifications and variations of the present invention are possible in light of the above teachings and, within the scope of the appended claims, the invention may be practiced otherwise than as specifically described.

Claims

1. A method for a trusted node to remotely verify the system environment of another party, comprising the following steps: (1-1) Node A and Node B trust each other and know each other's system environment; (1-2) When the node verifies node B, it first dynamically generates a detector and a verifier; (1-3) The detector is sent to node B and executed by node B. The detector includes three modules: application layer module a, driver layer module b, and boot layer module c; (1-4) Application layer module a loads driver layer module b, and finally collects the detection results of driver layer module b and boot layer module c and sends them to node A; (1-5) Driver layer module b detects whether the system environment matches and identifies whether rootkit-type malicious programs exist, and determines whether it is necessary to continue loading boot layer module c; (1-6) When driver layer module b passes the detection, it blocks the system environment and loads boot layer module c to continue system environment detection; (1-7) Detector application layer module a sends the detector result to node A; (1-8) After receiving the detector result, node A executes the verifier locally. If the verifier result is consistent with the received detector result, it means that the system environment of node B is trustworthy.

2. In the method as claimed in claim 1, the system environment refers to all processes running on a node, including an operating system and application programs.

3. According to the method of claim 1, blocking the system environment means that the driver layer module b filters files, processes and networks, prohibiting the loading of all unknown modules and the connection of unknown network terminals.

4. According to the method described in claim 1, the boot layer module c is loaded to continue the system environment detection. The driver layer module b and the boot layer module c complement each other. The boot layer module c can ensure that the driver layer module b is not missed and deceived, and the driver layer module b can ensure that the detection result of the boot layer module c cannot be forged. This method is absolutely safe and accurate to realize a method in which a trusted node remotely verifies the other party's system environment.

Images