The issue of malicious software, e.g., viruses, worms, etc., has become highly prominent along with the informatization development. There have been more than thirty-five thousand kinds of malicious software at present, and more than forty million computers have been infected annually. It is required for inhibition of such attacks to not only address secured transport and a check for data input but also defend from the origin, i.e., each terminal connected to a network. However, traditional security defending approaches have failed to defend against numerous malicious attacks.
The international Trusted Computing Group (TCG) has established specifically for this issue a trusted computing based network connection specification—Trusted Network Connect (TNC)—simply TCG-TNC, which includes an open terminal integrity architecture and a set of standards for guaranteeing secure interoperations. This set of standards can protect a network as demanded for a user to a protection extent self-defined by the user. The TCG-TNC is essentially intended to establish a connection starting with integrity of a terminal. It is required in the TCG-TNC architecture to create a set of policies for the operation condition of a system in the trusted network, so that only if a terminal complying with a policy which is set for the network can access the network, the network can isolate and locate those devices that do not comply with the policy. An attack of root kits can also be blocked due to a Trusted Platform Module (TPM) in use. The root kits are a kind of attack script, a modified system program or a set of attack scripts and kits, which is intended in a target system to acquire illegally a highest control privilege of the system.
In the existing TCG-TNC architecture, complete information transmission on a trusted network connect is as illustrated in FIG. 1. A TNC client shall prepare and submit required platform integrity information to an Integrity Measurement Collector (IMC) prior to establishment of a network connection. In a terminal provided with a Trusted Platform Module (TPM), the foregoing process also means that platform information required for a network policy is hashed and then stored in respective Platform Configuration Registers (PCRs) and a TNC server shall pre-establish and submit a platform integrity verification request to an Integrity Measurement Verifier IMV. A specific process of this method is as follows:    (1) A network access requestor initiates an access request to a policy enforcer.    (2) The policy enforcer transmits a description of the access request to a network access authorizer.    (3) The network access authorizer executes a user authentication protocol with the network access requester upon reception of the description of the access request from the network access requester. The network access authorizer transmits the access request and user authentication success information to a TNC server upon successful user authentication.    (4) The TNC server commences executing bidirectional platform credential authentication with a TNC client, e.g., verifying an Attestation Identity Key (AIK) of a platform, upon reception of both the access request and the user authentication success information transmitted from the network access authorizer.    (5) The TNC client notifies an Integrity Measurement Collector (IMC) about both commencement of a new network connection and a need to execute an integrity handshake protocol upon successful platform credential authentication. The Integrity Measurement Collector (IMC) returns required platform integrity information via an Integrity Measurement Collector Interface IF-IMC. The TNC server submits the platform integrity information to an Integrity Measurement Verifier (IMV) via an Integrity Measurement Verifier Interface IF-IMV.    (6) The TNC client and the TNC server perform one or more exchanges of data during execution of the integrity handshake protocol until the TNC server does not need any more.    (7) The TNC server completes execution of the integrity handshake protocol on the TNC client and transmits a recommendation to the network access authorizer to request for an access to be permitted. As can be appreciated, if there is an additional security consideration, the policy decision point still may not permit any access of the Access Requester.    (8) The network access authorizer passes an access decision to the policy enforcer, and the policy enforcer finally executes the decision to control the access of the access requester.
No matured TCG-TNC architecture product has been put into the market at present. Some important techniques of the TCG-TNC architecture are still in a phase of research and standardization. As can be seen in the method of the prior art, since a predefined secure channel is present between the policy enforcement point and the policy decision point, and the policy decision point possibly manages a large number of policy enforcement points, the policy decision point has to configure a large number of secure channels, thereby causing complicated management and consequential poor expansibility. Moreover, data over a network access layer has to be protected for security, so a secure channel has to be established between the access requester and the policy decision point, that is, session key negotiation has to be performed. However, data protection is also required between the access requester and the policy enforcement point, so session key negotiation has to be performed again between the Access Requester AR and the policy execution point, thus complicating the key negotiation process. Also a primary key resulting from the negotiation between the access requester and the policy decision point is passed from the policy decision point to the policy enforcement point. Passing of the key over the network may introduce a new security attack point to result in lowered security. Moreover, the dual session key negotiation makes use of the same primary key, which may also lower security throughout the trusted network connect architecture. Furthermore, the access requester may be unable to verify an AIK certificate of the policy decision point for validity. During the platform credential authentication process, the access requester and the policy decision point use AIK private keys and certificates for the bidirectional platform credential authentication and both of them shall verify the AIK certificates for validity. If the policy decision point is a network access service provider of the access requester, the access requester can not access any network without a trusted network connect, that is, the AIK certificate of the policy decision point can not be verified for validity, which would be insecure. Finally, platform integrity evaluation is not peer-to-peer. In the TCG-TNC architecture, the policy decision point performs platform integrity evaluation on the access requester, and the policy enforcement point can know from an enforcement decision of the policy decision point whether a platform of the access requester is trusted, but the access requester will not perform platform integrity evaluation on the policy decision point. If the platform of the policy decision point is un-trusted, e.g., due to malicious software, etc., it may be insecure for the access network to be connected with a un-trusted device, and a trustworthiness link from the access requester to the trusted network may be broken at the policy enforcement point, but a peer-to-peer trust is necessary in an Ad Hoc network.
USPTO Backgrounds
USPTO Backgrounds