WO2008083628A1

WO2008083628A1 - A authentication server and a method,a system,a device for bi-authenticating in a mesh network

Info

Publication number: WO2008083628A1
Application number: PCT/CN2008/070064
Authority: WO
Inventors: Hao Huang; Junping Zhang; Liangyue Mo; Huimin Zhang; Danfeng Feng
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2007-01-09
Filing date: 2008-01-09
Publication date: 2008-07-17
Also published as: CN101222331B; CN101222331A

Abstract

An authentication server and a method, a system, a device for bi-authenticating in a mesh network are provided. The said authentication server includes: a credit degree distributing module for determining the security degree of the node based on the received node information of the node which requests for authenticating, and generating a credit degree time stamp after successful authenticating, then signing it and sending it down to the node which requests for authenticating with the identifier of sign arithmetic; a credit degree management module for storing the users identity information of all successful authentication nodes in mesh and the credit degree, signature and time stamp information which are certificated by the authentication server. The authentication server further includes a node status detecting module for detecting whether the nodes in mesh are attacked; a credit degree reducing/depriving module for reducing/depriving the credit degree of the notes when receives a disconnection information or after being attacked. The present invention realizes that each node in Mesh net can select the associated node based on the credit degree, and once realizes bi-authenticating by validating the credit degree signature which is feedback from the associated node.

Description

Method, system and device for mutual authentication in authentication server and mesh network

The embodiments of the present invention relate to the field of network communication technologies, and in particular, to a method, system, and device for authenticating a server and a two-way authentication in a mesh network. Background technique

The wireless Mesh network, also known as the "multi-hop" network, is a new wireless network technology that is completely different from traditional wireless networks. Traditional wireless networks must first access a centralized AP (Access Point) to make a wireless connection. Thus, even if two nodes are adjacent, they must communicate through the access point. In a wireless mesh network, any wireless device node can act as an AP or router at the same time. Each node can send and receive data, and can directly communicate with one or more peer nodes.

The role of the wireless Mesh network is different from that of the traditional BSS (Basic Service Set). Only the STA (Station, Site or Terminal), AP, and AS (Authentication Server) roles are included in the BSS domain. At the time of authentication, the AS forces the STA to act as the requester, and the AP acts as the authenticator.

The main features of Mesh include:

(1) Transport: Transfers non-Mesh application data to and from neighbor nodes. Only send, receive, and not forward.

(2) Internal Routing: A forwarding path is established between Mesh devices.

(3) External Routing: Establish a forwarding path with the Mesh external device. (4) Forwarding: Send the frames generated by other devices received.

(5) Access point: Allows a STA to connect to the Mesh through the AP.

The basic hierarchy of Mesh is shown in Figure 1. The functions performed by various devices in Mesh are different. The roles according to the above functions are:

MAP (Mesh Access Point): Transmission + Internal Routing + Forwarding + Access; MPP (Mesh Point Collocated With a Mesh Portal): Mesh and External Network Gateway: Transmission + internal routing + forwarding + external routing, not shown in Figure 1;

MP (Mesh Point, Mesh node): transmission + internal route + forwarding;

LWMP (Light Weight Mesh Point): Transmission, not shown in Figure 1;

STA: Data source.

It can be seen that the role division in Mesh is very different from the BSS domain. Currently, the definition and implementation of roles in 802.11s only have a more comprehensive definition of STA and MAP, while LWMP, MP, and MPP authentication have the following problems:

(1) Each MP in the negotiation may have three roles to complete: Supplicant, Authenticator, and AS. Therefore, there are issues of how to negotiate and determine the joint security roles and security policies of both parties.

(2) A management action is required to assign roles to individual devices and select an associated MP to securely complete authentication.

At present, the main idea of the role negotiation proposal is: In the RSN IE (Robster Security Network Information Element), a reachable element "AS Reach ability" is used as the basis for measuring the negotiation role. , As shown in Table 1.

Table 1

The specific implementation process is shown in Figure 2.

First, in the discovery phase, the nodes that need to be associated send reachability to the AS through Beacon or probe response. Then negotiate the role of authentication through reachability: (1) If only one of the parties is reachable to the AS, then the reachable party is the authenticator and the other party is the requester.

(2) If both parties are reachable or unreachable, the party with the larger MAC address is selected as the certifier and the other party as the requester.

After the role is determined, the 802.1x method is used to complete the authentication and access the Mesh network.

In the process of implementing the present invention, the inventors have found that the prior art has at least the following disadvantages: When only one party in the authentication is reachable to the AS, the situation is similar to that of the ordinary BSS, but there is still a problem of switching the authentication point when the malicious MP attacks. Moreover, unlike the asymmetric structure of BSS, the original 802. lx authentication can only complete the authentication of the requester, which is a one-way authentication. Now the hierarchical structure of the MP in the Mesh is symmetric and equal, and the two-way authentication is required. Two rounds of 802.1x authentication not only wastes time, but in most cases the second round of authentication is not what MPs have access to Mesh.

In addition, there is no intermediate road selection problem for BSS authentication, and the AP is directly connected to the AS. For Mesh, it is relatively complicated. The choice of authentication intermediate nodes must also consider security. It is necessary to establish a secure path (or the security that users want most). However, the following conditions may make the reachability unreliable: The routing performance of an intermediate MP is the best. In this case, no matter how the MP that wants to join the Mesh chooses the authentication point, the authentication data will be forwarded to the MP for forwarding, but if this is the case, If the intermediate MP is attacked and destroyed, the attacker may obtain a large amount of user authentication information and return it to the EAP-Success (Extensible Authentication Protocol Success Message) message for the purpose of plain text or a failure message. The certifier, the certification result is a failure. The certifier is not reliable because it does not know which place is wrong and only re-switches the authentication point repeatedly. Summary of the invention

The embodiments of the present invention provide a method, a system, and a device for authenticating a two-way authentication in an authentication server and a Mesh network, which solve the disadvantages of the unreliable intermediate node of the Mesh network and the single authentication.

To achieve the above objective, an embodiment of the present invention provides a method for bidirectional authentication in a mesh network, including: a node in a mesh network Mesh selects an association node based on a trust degree, and the association node authenticates the node, and The trust signature is fed back to the node, and the node is based on the trust degree The signature authenticates the associated node.

The embodiment of the present invention further provides a mesh network system, including: at least one AS and multiple nodes, where the AS is configured to authenticate the node according to the received information of the node that is requested to be authenticated, to determine the node. a security level, and a trust time stamp is generated after the authentication succeeds, and the signature is sent to the node requesting the authentication together with the signature algorithm identifier;

The node in the Mesh selects an association node for authentication based on the trust degree sent by the AS, and verifies the identity of the associated node according to the trust degree signature fed back by the associated node.

The embodiment of the present invention further provides an authentication server, including: a trust distribution module, configured to determine a security level of the node according to the received node information of the request authentication, and generate a trust time stamp after the authentication succeeds, after signing And the signature algorithm is sent to the node that is requested to be authenticated. The trust management module is configured to store user identity information of all successfully authenticated nodes in the Mesh and the trust degree, signature, and timestamp information recognized by the authentication server.

Compared with the prior art, the embodiment of the present invention has the following advantages: The embodiment of the present invention provides a node that selects an access point according to the degree of trust when the node initially accesses the Mesh network, and then both parties negotiate the authentication role and pass the verification of the authenticator. The trust signature verifies the legal identity of the authenticator, and realizes the two-way authentication that the original 802. lx needs to complete in two rounds.

In the meantime, the embodiment of the present invention implements the AS to manage the identity of the requester, manages the trust degree, and classifies the trust degree of the user and the device, and then distributes the corresponding signature message to implement centralized authentication management. When any node accesses the authentication, the best authentication path can be selected to complete the authentication and is independent of the routing mechanism. The authentication security will not be changed as the route changes. It also reduces the trust of certain points when detecting an attack, thereby reducing the risk of being attacked. DRAWINGS

1 is a schematic diagram of a basic hierarchical structure of a prior art Mesh network;

2 is a schematic diagram of a method for selecting a prior art authentication role;

3 is a flowchart of an embodiment of an access authentication process of the method according to the present invention; FIG. 4 is a flowchart of a flowchart of Embodiment 1 of an AS sending trust and authentication process according to the present invention; Flow chart of the second embodiment of the trust and authentication process; FIG. 6 is a schematic diagram of an embodiment of an authentication server according to the present invention. detailed description

The embodiment of the present invention selects an associated node based on the degree of trust, and achieves the purpose of mutual authentication between the requester and the authenticator by verifying the signature of the trust. Unified management of trust by the AS. The requester is authenticated by the AS and then sends the trust and related signature information, which is used as the basis for accessing the Mesh network. When a node leaves the Mesh network or is attacked, the AS is responsible for the deprivation or reduction of trust.

The following example illustrates the two-way authentication process by taking the node access authentication process in the Mesh network as an example. The specific implementation process is as follows:

Step 1: The requester selects an intermediate node that interacts with the AS, that is, selects an authenticated access node as an intermediate querier to access the AS:

When an MP, MAP, or STA initially wants to access a mesh network, it sends a probe request to all neighbors, and the neighbors feed back the message with a beacon or probe response.

When the node (MP, MAP, or STA) receives the trust carried in the Beacon or the probe response sent by all neighboring nodes, it selects the node that most wants to associate according to its own policy. For example, the trust degree can be selected. The node that is the largest or meets the MPP global policy performs 802.1x authentication. For example, a certain Mesh network has previously agreed to a certain range of trust to complete the access, and other ranges to forward or other functions. In this case, the selected access node needs to satisfy the pre-agreed policy.

The trust degree is uniformly distributed and managed by the AS, and can be implemented by modifying the format of the current RSN IE. The current RSN IE format is as shown in Table 1, and the capability information Capabilities can be modified, where before and after the modification. The Capabilities information is shown in the following table:

before fixing:

Pre-Auth No Pairwise PTKSA GTKSA Reserved Mesh Auth Always PeerKey

Replay Replay Default Possible Enabled

Counter Counter After modification:

The two fields added in the embodiment of the present invention include: Role Type and Trust Degree. Role Type indicates the trust role type, which occupies one bit. When the value is 0, it indicates the user type trust degree, such as STA trust degree. When the value is 1, it indicates that the Mesh device node, such as MP or MAP trust degree, guarantees that most of the STAs will not pass the STA as the authenticator. The Mesh device node is used as an authenticator, such as MP, MAP, etc. as the authenticator, and the role of the authentication intermediary is completed.

The Trust Degree indicates the degree of trust, which occupies four bits. The user or device that passes the authentication will obtain the trust issued by the AS. The default is 0, which means that the certificate is not authenticated or the trust level is the lowest.

Each node selects the relatively secure authenticated access node based on the existing trust information, so the authentication path of any node is the most reliable. For data transmission, it can be encrypted according to the key negotiated by the authentication, and the route with the best route can be selected for forwarding.

Step 2: After the intermediate authenticator selects, the requester (MP, MAP or STA) is associated with the selected intermediate authenticator;

The specific process is shown in Figure 3, including the following steps:

Step S301: First, the requester sends an authentication request to the selected intermediate authenticator;

Step S302: The intermediate authenticator feeds back the security parameter supported by itself, the public key and signature algorithm used by the AS, and the signature of the trust degree to the requester.

The requester checks whether the signature algorithm is supported, and whether the signature algorithm of the entire Mesh network is consistent. If the signature algorithm fed back by the authenticator is not supported, or the signature algorithm of the entire Mesh network is inconsistent, the authenticator is considered invalid, otherwise it is valid. Then, according to the information of the AS, it is verified whether the trust signature is legal and valid. The specific verification method is described later; the signature algorithm is represented by an identifier bit, and different values represent different algorithms, for example: When set to 1, the default is Public Key Algorithm RSA (Integer Factorization Based Public Key System); Set to 2 to indicate DSS (Digital Signature) Standard, digital signature standard); when set to 3, represents ECM (Elliptic Curves Cryptography) of WAPI (Wireless Local Area Network Authentication and Privacy Infrastucity); When set to 0, it indicates other signature algorithms that support scalability. All authentication-related messages sent by the requester to the AS can then be encrypted using the AS's public key, and subsequent symmetric key negotiation can guarantee transparency to the authenticator.

Step S303: Perform open or pre-shared key authentication between the requester and the intermediate authenticator;

The open system authentication belongs to non-cryptographic authentication, which is also called "zero authentication". The node requesting access only needs to use an empty string as the SSID (Service Set Identifier) to respond. The intermediate certifier establishes an association.

The pre-shared key authentication is based on a "request/response" mechanism with a shared key. The node requesting access first sends an authentication request to the intermediate authenticator, and then the intermediate authenticator generates a random number response to the node requesting authentication, and the node requesting authentication then encrypts the random number response to the intermediate authenticator through the shared key. After the intermediate authenticator decrypts the comparison, the final confirmation message is sent.

Step S304, the intermediate authenticator returns an authentication result.

Step S305: The requester sends the required security parameter combination according to the security parameter supported by the intermediate authenticator;

Step S306, the authenticator returns an association success or failure result.

Step 3: After the requester associates with the intermediate authenticator, the requester accesses the AS, and the AS completes the 802. lx authentication and distribution trust of the requester;

The requester performs port-based 802.1x access control authentication according to the existing 802.11 standard. The authentication related message is transmitted between the requester and the authenticator via a LAN (Local Area Network), that is, using an EAPOL (Extensible Authentication Protocol over LAN) technology, and the EAPOL is supported by the EAPOL. The general protocol of the authentication mechanism, the types of EAP that can be used mainly include: EAP-TLS (Extensible Authentication Protocol - Transport Layer Security, Extended Authentication Protocol based on Transport Layer Security), EAP-TTLS .ayer Security, extended authentication protocol based on tunnel transport layer security), PEAP (Protected Extensible Authentication Protocol), LEAP (Lightweight Extensible Authentication Protocol), EAP-MD5 (Extensible Authentication Protocol-Message Digest Algorithm 5, extended authentication protocol based on message digest algorithm) and EAP-SIM (Extensible Authentication Protocol-Subscriber Identification Module based on user identity module) combined with mobile communication.

EAP-TLS can allocate the session ID for the data exchange between the client and the server, select the appropriate integrity protection encryption mechanism, assign the dynamic session key, and effectively protect the security of the interactive message during the 802.1x authentication process. It is transparent to the intermediate certifier, ie the authenticated access point does not see any certified content. Therefore, EAP-TLS can be used to complete the trust delivery and the AS authentication to the requester.

In order to reduce the overhead of the terminal or device during the deployment of the Mesh, the AS can have only one certificate and the public key to provide the authentication of the AS identity, while other nodes can have no X.509 certificate.

A flow chart of Embodiment 1 of the AS sending trust and authentication process, as shown in FIG. 4, includes the following steps:

Step S401: After receiving the identity verification request of the intermediate authenticator (not shown in FIG. 4, because the subsequent interaction is transparent for it, so need not be considered), the requester sends an identity-related response, and the intermediate authentication is performed. Sent to the AS;

Step S402: After receiving the response, the AS sends a TLS (Transport Layer Security) start request to the requester.

Step S403, the requester feeds back TLS to start responding to the AS;

Step S404: After receiving the response, the AS sends its identity information, including the certificate and the public key, to the requester.

Step S405, the requester verifies the legality of the AS identity. After the verification is passed, the requester officially submits its own user, password, and the like to the AS for authentication, and the requester can fully recognize the authenticity of the AS; The verification method may be based on a specific TLS negotiation verification method. If it is a user password MD5 method, it only needs to be compared; if it is a public key certificate verification, both parties need a certificate interaction certificate and a counterpart public key encryption. .

Step S406, the AS may determine the security level of the requester by the security capability information of the requester node, the user service level, or the policy of the centralized access control server. Successful authentication will result in a trust timestamp TimeStamp (the AS can guarantee the uniqueness of the timestamp), and the signature is sent to the requester along with the signature algorithm identifier used by the AS.

The signature sent by the AS includes the following parameters:

RoleType: Role type. If the value is 0, the node is a user type. For example, if the value is 1, the node is a Mesh network device type, such as MP or MAP.

TrustDegree: indicates the trust of the user or device;

ID _AS , IDsupHcant: AS, the identity identifier of the requester, such as the respective MAC address;

SK _AS , PK _AS : the public key and private key of the AS;

TimeStamp: The timestamp of the success of the authentication, with a unique '1'.

The signature algorithm is as follows:

S = Sig _SKAs ( oleTypell TrustDegres || ID _AS || ID _SupHcant || TimeStamp) . The signature algorithm is sent to the requester along with the trust degree TrustDegree.

Step S407, the requester checks whether the signature algorithm is the same as the algorithm used by the authentication access point, that is, whether it is the same as the signature algorithm used by the intermediate authenticator, and after verifying the uniformity, verifying the trust signature and sending the verification feedback response. Message to AS.

First judge the legality of trust;

Including: Determine whether the value of RoleType is 0 or 1, and a value of 1 indicates that the node is a device. The role of this is that the user will not be the Authenticator. The authentication is based on the method chosen by the user to determine whether it is legal, because some nodes only need to be authenticated by the device, and the terminal is not allowed to be the Authenticator. ID _AS and ID _Supllcant ;

Then judge the validity of trust;

The validity is determined mainly based on the TrustDegree and TimeStamp obtained from the verification. TrustDegree is mainly used to determine whether to accept the new trust value instead of the original trust value. Because every time The association must be performed once for 802. lx authentication, but there are multiple associations in the Mesh. It is not necessary to obtain new trust when the two nodes that have been connected are associated, but only to judge the mutual legality of trust. .

The TimeStamp judgment is mainly used to verify the trustworthiness of the authenticator and to resist the replay attack of trust. If TimeStamp reuse is detected, the authenticator can be considered to be a counterfeiter; if there is no duplication, the unique designation of trust can be judged by interaction with the AS, and the AS is also recorded in the authentication phase. All other nodes.

Step S408: The AS sends an authentication success or failure message to the node requesting access.

Through such a process, a device (MP or MAP) or a user (STA) obtains the AS's approval, and the trust degree can be used to access the Mesh network. The authenticated device can be used as a new authenticator to authenticate other nodes.

The flowchart of the second embodiment of the AS sending trust and authentication process is shown in FIG. 5, and includes the following steps:

Step S501: After receiving the identity verification request of the intermediate authenticator (not shown in the figure, because the subsequent interaction is transparent for it, so need not be considered), the requester sends an identity-related response, including the time of the authenticator. Stamping and random number encrypted with the AS public key, sent by the intermediate authenticator to the AS;

Step S502, after receiving the response, the AS detects that the requester is not replayed (not stolen), and then unpacks the random number, and then sends a TLS start request to the requester after signing;

Step S503, the requester feeds back TLS to start responding to the AS;

Step S504, after receiving the response, the AS sends its identity information, including the certificate and the public key, to the requester.

Step S505: The requester verifies the legality of the AS identity. After the verification is passed, the requester officially submits the user, the password, and the like to the AS for authentication, and the requester can completely recognize the authenticity of the AS;

Step S506, the AS verifies the identity information of the requester node, and then sends an authentication end message to the requester.

Not limited to EAP-TLS, but also includes other protocols that use certificates for authentication. EAP-PEAP, EAP-TTLS, etc. (the total number of steps can also be different). For the MD5 method, you only need to compare it. If it is a public key certificate verification, both parties need the certificate's interactive risk certificate and the other party's public key encryption.

Step S507: After receiving the authentication end message, the requester feeds back a response message to the AS, and when the trust time stamp needs to be acquired, sends a requesting AS to issue a signature of the signature to become a new legal authenticator.

The AS will generate a trust timestamp TimeStamp (the AS can guarantee the uniqueness of the timestamp), and determine the security level of the requester by the security capability information of the requester node, the user service level, or the policy of the centralized access control server. The signature and signature method are the same as in the first embodiment.

Step S508, the AS sends an authentication success (or failure message) message together with the signature S, the signature algorithm identifier, and the trust degree TmstDegree—to the requester to the requester.

The requester checks whether the signature algorithm is the same as the algorithm used by the authenticated access point, that is, whether it is the same as the signature algorithm used by the intermediate authenticator. After confirming the uniformity, the trustworthiness signature is verified and verified to be accepted. The judgment method used is the same as that of the first embodiment.

Step 4: After a node wants to leave the Mesh network or the AS detects that a node receives an attack, the AS reduces or deprives the node of the trust degree;

The reduction or deprivation of trust by AS includes the following two situations:

(1) When a node actively wants to leave the Mesh network: The node informs all other nodes associated with it and unicast to the AS by broadcasting before ending the association, and the message uses a unified GTK (group temporary key) or The PMK (negotiated symmetric master key) encryption of the AS ensures the reliability of the message source. At this time, two messages are sent mainly before the deassociation frame (disconnected frame): Sending a disconnect message with GTK broadcast encryption for all associated nodes; sending a disconnect message to the AS with PMK unicast. After that, the AS deletes the trust of the timestamp associated with it and the information of other associated nodes, indicating that the trust is no longer available. Other nodes can also record timestamp obsolete information to ensure backward security of trust.

(2) When the AS detects that some nodes are maliciously attacked: The AS forcibly deprives them of trust, and the AS sends a forced disconnection, trust timestamp invalidation message to the attacked node by unicast. All nodes associated, at this time mainly send a message before the deassociation frame: Send a disconnect message to each node that has been associated with the attacked node with its own PMK broadcast. After verifying the identity reliability of the AS, the node receiving the message actively disconnects the attacked node and records a timestamp obsolete message. At the same time, the AS notifies the attacked node that if it wants to continue access, it must be reconfigured and then authenticated again. At this time, AS can also reduce its trust, reduce the risk of attack, and ensure the security of the entire network.

The trust is uniformly distributed and managed by the AS. The AS uses the dynamic directory mechanism for the management and transmission of trust. In the Mesh network running, as the node joins, leaves, or forces offline, the AS will be updated and saved. The AS stores the user identity information of all the nodes successfully authenticated in the Mesh network and the AS-approved trust, signature, and timestamp information. The dynamic directory can be defined by using a triplet: TD_Mesh<M, td r , TimeStamp> where:

M contains all nodes that have been successfully authenticated;

Td_r marks the trust relationship between all associated nodes;

The timestamp contains a timestamp of all distributed trusts, the timestamps being unique and the trustworthiness being reusable. The timestamp and the trust signature are one-to-one correspondences.

A policy definition language in the following format can be used in the AS's policy library:

{RolesID} IF {conditions} THEN {actions}

Among them, the M policy library can be managed based on roles, and is divided into two categories:

(1) Trust of the device role: It only indicates the security level of the device or the difficulty of being attacked, mainly the trust degree of MP or MAP;

(2) The trust degree of the user role: not only can represent the security level of the node, but also the user service can be graded to adjust the level-based fairness or the user's access control, etc., mainly for the trust degree of the STA.

In practice, users can add more functions to extend the policy library according to actual needs, including the corresponding user-based load balancing, etc., and the condition (condition field) and action (execution field) need to be continuously expanded.

The definition of a security policy depends mainly on the actual network situation and the service class that you want to provide. Types and other parameters to determine, the granularity of the strategy needs to be further refined to meet the requirements of different user levels. The above embodiment is described by taking access authentication as an example. In actual operation, when any two MPs want to establish an association, the requester and the authenticator may also be selected according to the size of the trust. The smaller party is the requester and the larger party is the certifier. If both parties have trust, it means that the two just want to establish an association and have nothing to do with access authentication. In this case, the association can be established through the 802.1x method, without accepting the newly issued trust, or only the mutual trust. The degree and signature can be associated, then the association can be established more quickly, so that the process of interaction can be completed faster, which mainly includes the following steps:

(1) The requester submits his own trust signature information to the authenticator for verification;

(2) After the authenticator has successfully verified, respond to the requester with his own trustworthiness signature;

(3) After the requester successfully verifies, a success or failure message is returned;

(4) Use the original 802.11i mechanism for key management.

If both parties do not have trust, a local database is required to complete the authentication, and the result may fail. You need to wait for other nodes that can complete the authentication to access the Mesh network. An embodiment of the present invention provides a two-way authentication system in a Mesh network, where the system includes at least one AS and multiple nodes, and the nodes include: MP, MAP, and STA. The AS is used to distribute the trust degree to each node in the Mesh network, and the trust degree is uniformly managed. A schematic diagram of an embodiment of the module is shown in FIG. 6, and includes:

The message receiving module is configured to receive a message sent by the node in the Mesh network, including: an authentication request message, a disconnect message, and the like;

The trust distribution module is configured to determine the security level of the node according to the security capability information of the node that is authenticated according to the received request, the user service level, or the policy of centrally accessing the controller, and distribute the authentication message to the requester. The authentication message includes: a trust time stamp, an authenticator signature, a used signature algorithm, and the like. The requester includes: MP, MAP or STA;

a node status detecting module, configured to detect whether a node (MP, MAP, or STA) in the Mesh network is attacked;

Trust reduction/deprivation module, used to receive a disconnect message or detect a node being attacked Reduce/deprive the trust of the node;

The trust management module is configured to store user identity information of all successfully authenticated nodes in the mesh network and the trust degree, signature, and timestamp information recognized in the system.

The plurality of nodes in the Mesh network perform association authentication based on the trust degree of the AS distribution, and further includes the following modules:

The authenticator authentication module is configured to verify whether the identity of the authenticator is legal according to the identity of the authenticator in the received authentication message.

Each device node in the Mesh network includes an MP or a MAP, and after being authenticated, can be used as an authenticator to authenticate other nodes.

In summary, the embodiment of the present invention proposes that when a node initially accesses a Mesh network, the access point is selected according to the trust degree of the neighbor, and then both parties negotiate the authentication role, and verify the authenticator's trust by verifying the authenticity of the authenticator. Legal identity, one-time authentication that requires two rounds to complete the original 802.1x.

Through the description of the above embodiments, those skilled in the art can clearly understand that the present invention can be implemented by means of software plus a necessary general hardware platform, and of course, can also be through hardware, but in many cases, the former is a better implementation. the way. Based on such understanding, the technical solution of the present invention, which is essential or contributes to the prior art, may be embodied in the form of a software product stored in a storage medium, including a plurality of instructions for making a A computer device (which may be a personal computer, server, or network device, etc.) performs the methods described in various embodiments of the present invention.

In summary, the above description is only the preferred embodiment of the present invention and is not intended to limit the scope of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and scope of the invention are intended to be included within the scope of the invention.

Claims

Rights request

A method for mutual authentication in a mesh network, characterized in that it comprises:

The node in the mesh Mesh selects the associated node based on the trust degree, the associated node authenticates the node, and feeds back its own trust degree signature to the node, and the node signs the associated node according to the trust degree signature. Certify.

2. The method according to claim 1, wherein the trust degree is issued and managed by the authentication server AS.

The method according to claim 2, wherein the method for the AS to use the mutual authentication to deliver the trust degree comprises:

The node in the Mesh sends a probe request to the neighboring node, and selects an intermediate authenticator that interacts with the AS according to the trust degree carried in the message fed back by each neighbor node;

The node is associated with the selected intermediate authenticator, and the validity of the intermediate authenticator is verified according to the trust degree signature issued in the intermediate authenticator association process, and after obtaining the authentication of the intermediate authenticator, The node is connected to the AS;

The AS authenticates the node that requests the access, and sends a trust degree to the node that requests the access.

The method according to claim 3, wherein the method for selecting an intermediate authenticator by each node in the Mesh includes:

The node with the highest degree of trust or meeting the pre-agreed trust degree is selected as the intermediate Authenticator among the neighbor nodes of all the feedback messages.

The method according to claim 3, wherein the method for associating the node in the Mesh with the selected intermediate authenticator comprises:

The node in the Mesh sends an authentication request to the selected intermediate authenticator;

The intermediate authenticator feeds back the security parameters supported by itself, the public key and signature algorithm used by the AS, and the signature of the trust degree to the node;

The node verifies the validity of the intermediate authenticator and performs open or pre-shared key authentication with the intermediate authenticator;

The intermediate authenticator returns an authentication result; The node sends a security parameter combination required by the node to the intermediate authenticator according to the security parameter supported by the intermediate authenticator;

The intermediate authenticator returns an association success or failure result to the node.

6. The method of claim 5, wherein the method for verifying the legitimacy of the intermediate authenticator by the node comprises:

Each node checks whether the signature algorithm is supported, and whether the signature algorithm of the entire Mesh is consistent. If the signature algorithm fed back by the authenticator is not supported, or the signature algorithm of the entire Mesh is inconsistent, the authenticator is considered invalid, otherwise it is valid.

The method according to claim 3, wherein the method for the AS to authenticate the node that requests access includes:

The node verifies the legality of the AS identity;

After the verification is passed, the node submits its own information to the AS for authentication; the AS determines the security level of the node by the information of the node, and generates a trust time stamp, and the signature algorithm used after the signature together with the AS The identifier is sent to the node;

The node verifies the legality of the AS, and the node obtains the trust degree when the AS is legal.

The node verifies the legality of the AS identity;

After the verification is passed, the node submits its own information to the AS for authentication; after the AS authenticates the node, sends an authentication end message to the node; the node receives the authentication end message. After sending a response message, requesting the AS to issue the authentication signature;

After receiving the request, the AS generates the trust time stamp, and the signature algorithm identifier used after the signature is used in the authentication success or failure message sent to the node;

9. The method according to claim 2, wherein the method for managing trust by the AS comprises:

Reduce or strip when a node wants to leave the Mesh or the AS detects that a node is under attack.

2 Take the trust of the node.

The method of claim 2, wherein the AS uses a dynamic directory to deliver and manage trust, and the dynamic directory includes user identity information of all nodes successfully authenticated in the Mesh and AS-approved trust. Degree, signature, and timestamp information.

A mesh network system, comprising: at least one AS and a plurality of nodes, wherein the AS is configured to authenticate the node according to the information of the node that is requested to be authenticated to determine the node. a security level, and a trust time stamp is generated after the authentication succeeds, and the signature is sent to the node requesting the authentication together with the signature algorithm identifier;

The system according to claim 11, wherein the AS further comprises: a trust distribution module, configured to determine a security level of the node according to the received node information of the request authentication, and after the authentication succeeds Generating a trust time stamp, which is sent to the node requesting the authentication together with the signature algorithm identifier;

The trust management module is configured to store user identity information of all successfully authenticated nodes in the Mesh, and AS-approved trust, signature, and timestamp information.

The system according to claim 11, wherein the nodes in the Mesh are provided with:

The authenticator authentication module is configured to verify the identity of the associated node according to the trust signature returned by the associated node.

14. An authentication server, comprising:

a trust distribution module, configured to determine a security level of the node according to the received node information of the request authentication, and generate a trust time stamp after the authentication succeeds, and send the signature to the node requesting the authentication together with the signature algorithm identifier ;

The trust management module is configured to store user identity information of all successfully authenticated nodes in the mesh and the trust degree, signature, and timestamp information recognized by the authentication server.

The authentication server according to claim 14, further comprising:

a node state detecting module, configured to detect whether a node in the mesh is attacked; and/or,

3 The trust reduction/deprivation module is configured to reduce/deprive the node's trust after receiving the disconnection message or detecting that the node is attacked.

4