A cross-non-collaborative domain identity authentication method
By negotiating the router key and MAC address lists within the core network, an anonymous identity is generated, and combining the address hopping engine and hashing algorithm, the problem of incomplete privacy protection and cross-non-cooperative domain authentication in source address verification is solved, and the user identity and the packet source address are strongly bound, which is suitable for multiple non-cooperative domain scenarios.
Patent Information
- Application Number
- CN202411626585.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-14
- Publication Date
- 2025-08-12
- Estimated Expiration
- 2044-11-14
AI Technical Summary
The prior art does not consider privacy protection in source address verification. The introduction of new identifiers leads to difficulty in deployment, incomplete privacy protection, and does not support identity authentication across non-collaborative domain scenarios.
By negotiating the router key and MAC address lists within the core network, an anonymous identity is generated, combining the address hopping engine and hashing algorithm, strong binding between the user identity and the packet source address is realized, and cross-non-collaborative domain authentication is used using the global group key.
It realizes strong binding between user identity information and data packet source address, protects user privacy, is suitable for cross-non-collaborative domain scenarios, and does not affect the normal operation of the existing network protocol stack.
Smart Images

Figure CN119449442B_ABST
Abstract
Description
Technical Field
[0001] The present invention belongs to the technical field of network security, and in particular relates to a cross-non-collaborative domain identity authentication method. Background Art
[0002] With the rapid development of computer technology, more and more users are joining the internet. These users can be divided into different user groups based on the scope of resources they can access and the services they use, thus being assigned user identities. This increasing number of users puts network access authentication and authorization technologies under a new challenge. Not only must user identity information be secure and reliable, but resource access restrictions must also be granted only to authenticated and legitimate users, preventing third-party attackers or other unauthorized users from circumventing authentication mechanisms and gaining access to network resources and services. For example, attackers could potentially exploit authenticated user identities to communicate on the network. Furthermore, ensuring the privacy of authenticated users within the system is crucial. Address hopping has emerged as a key requirement. While an ideal address hopping system can trace each data packet back to its sender, the sender's identity and the content of the transmission must remain private. Therefore, building a unified and reliable authentication and privacy protection solution is essential. A robust authentication system can effectively prevent unauthorized access and identity theft, ensuring the security of sensitive data. In terms of user experience, seamless authentication mechanisms such as Single Sign On (SSO) allow users to access multiple applications after passing authentication on an authentication server once, without having to provide identity information credentials again, thus reducing the user's operational burden without compromising security.
[0003] The existing technology has the following disadvantages:
[0004] (1) Source address verification does not take privacy protection into consideration: The data collected during the source address verification process may not be properly encrypted and protected, which increases the risk of data leakage. If this data falls into the hands of malicious third-party attackers, the user's privacy may be seriously threatened.
[0005] (2) The new identifiers introduced for privacy protection reduce deployability: Although common address hopping schemes protect user privacy, the process of introducing new identifiers involves a series of changes to existing Internet infrastructure and protocols. This includes not only software and hardware updates for network devices such as routers and switches, but may also involve large-scale modifications to DNS, routing protocols, and various network management and security protocols. These changes require the collaborative participation of multiple parties, including network operators and standardization organizations, to ensure that the new identifiers can be applied in existing networks.
[0006] (3) Insufficient privacy protection: Although measures have been taken to protect the privacy of IP addresses, the existing mechanism is not comprehensive because it only focuses on anonymity at the network layer and fails to extend to MAC address protection at the link layer. In some attack scenarios, attackers can still track and identify users through MAC addresses in data packets.
[0007] (4) Does not support cross-non-cooperative domain scenarios: A non-cooperative domain is an autonomous domain in the network, as opposed to a cooperative domain. Within a cooperative domain, specific systems or services are typically deployed, and the nodes within the cooperative domain can coordinate to achieve the intended functionality of the system. In a non-cooperative domain, these systems or services are not deployed, and the nodes within the non-cooperative domain neither participate in nor cooperate with operations or behaviors within the cooperative domain. When a data packet with an address hopping needs to cross a non-cooperative domain where the aforementioned systems are not deployed during transmission, it may not be correctly routed to a designated host in another cooperative domain. Summary of the Invention
[0008] The purpose of the present invention is to provide a cross-non-collaborative domain identity authentication method to solve the problems existing in the above-mentioned prior art.
[0009] To achieve the above object, the present invention provides a method for cross-non-cooperative domain identity authentication, comprising:
[0010] Negotiate the first symmetric key and corresponding MAC address list of each router using adjacent routers in the same autonomous domain in the core network, and negotiate the global group key using border routers in each cooperative domain in the core network to complete system initialization;
[0011] After the system initialization is completed, the registration server in the core network verifies the validity of the network user who sends the identity registration request. After the verification is passed, the registration server is used to generate a digital identity and an anonymous identity corresponding to the network user, and a MAC address list is configured for the network user. The registration server is used to build a mapping relationship between the digital identity, the anonymous identity and the MAC address list. The constructed mapping relationship is saved in the distributed infrastructure in the core network and sent to the network user to complete the user identity registration;
[0012] After the user identity registration is completed, the network user performs symmetric key negotiation with the adjacent router in the corresponding autonomous domain to generate a second symmetric key, and associates the second symmetric key with the MAC address list of the network user;
[0013] After the association is completed, the network user obtains the MAC information of the adjacent node based on the neighbor discovery protocol, determines the third symmetric key based on the obtained MAC information, encrypts the anonymous identity based on the address hopping engine in the network user in combination with the third symmetric key, obtains the private information and embeds it into the source IP address of the data packet, randomly selects a MAC address from the MAC address list of the network user as the source MAC address of the data packet, calculates the integrity check code of the data packet through the hash algorithm, and embeds the integrity check code into the data packet to complete the construction of the data packet;
[0014] The data packet is uploaded to each router in the core network, and during the uploading process, the data packet is authenticated within the collaborative domain and across non-collaborative domains.
[0015] Optionally, the negotiation process of the first symmetric key of each router and the corresponding MAC address list specifically includes:
[0016] Negotiating the first symmetric key between adjacent routers in the same autonomous domain through a secure channel and a key exchange protocol;
[0017] After the first symmetric key negotiation is completed, each router saves the first symmetric key and the corresponding MAC address list.
[0018] Optionally, after the system is initialized, the registration server in the core network verifies the validity of the user who sent the identity registration request, including:
[0019] The user submits identity information to the registration server through a secure channel for identity registration, and the registration server verifies the validity of the user's identity. If there is a duplicate registration, the identity information is invalid and the registration request is rejected;
[0020] If there is no duplicate registration, the identity information is valid, and the registration server is used to generate a digital identity and an anonymous identity corresponding to the network user, and a MAC address list is configured for each interface of the network user device.
[0021] Optionally, the address hopping engine based on the network user encrypts the anonymous identity in combination with the third symmetric key, and the specific calculation formula is:
[0022] (EID||AVD)=E SK (AID||TS||IP dst )
[0023] Where, EID is Embedded Identifier, AVD is Additional ValidationData, AID is Anonymous Identifier, TS is Timestamp, IP dst is the destination network layer IP address, E SK A symmetric key encryption algorithm using an SK key.
[0024] Optionally, calculating the integrity check code of the data packet by using a hash algorithm specifically includes:
[0025] Based on the link address, network address, additional information and payload of the data packet, an integrity check code of the data packet is obtained in combination with a hash operation.
[0026] Optionally, the authentication process of the collaborative domain authentication specifically includes:
[0027] When a router within a single collaborative domain receives the data packet, it performs integrity verification on the integrity check code of the data packet. After the integrity verification is passed, it searches for the corresponding third symmetric key based on the source MAC address of the data packet. If the third symmetric key is not found, an error message is sent to the distributed infrastructure. If the third symmetric key is found, the anonymous identity and destination IP address are decrypted based on the obtained third symmetric key, the destination IP address of the data packet is compared with the decrypted IP address, and the distributed infrastructure is used to verify the authenticity of the decrypted anonymous identity and the corresponding source IP address. If the destination IP address is inconsistent or the anonymous identity cannot be queried in the distributed infrastructure, the data packet is discarded and malicious information is reported. If the destination IP address is consistent and the anonymous identity is queried in the distributed infrastructure, the authenticity verification is passed and the identity authentication is completed.
[0028] Optionally, the performing integrity verification on the integrity check code of the data packet specifically includes:
[0029] A current integrity check code of the data packet is calculated based on a hash operation. If the current integrity check code is consistent with the original integrity check code of the data packet, the integrity verification is passed; if the current integrity check code is inconsistent with the original integrity check code of the data packet, the data packet is discarded.
[0030] Optionally, the cross-non-collaborative domain authentication process specifically includes:
[0031] When a data packet passes through several non-cooperative domains from the source cooperative domain and finally reaches the destination cooperative domain, the user's identity information is encrypted using the global group key to obtain privacy information and embed it into the source IP address of the data packet. A MAC address is randomly selected from the MAC address list of the networked user as the source MAC address of the data packet, the integrity check code of the data packet is calculated by a hash algorithm, and the integrity check code is embedded in the data packet. The data packet is uploaded to the non-cooperative domain. When the destination cooperative domain receives the data packet, the integrity check code of the data packet is verified. After the integrity verification passes, the source MAC address of the data packet is searched. The corresponding global group key. If the global group key is not found, an error message is sent to the distributed infrastructure. If the global group key is found, the anonymous identity and destination IP address are decrypted based on the obtained global group key, the destination IP address of the data packet is compared with the decrypted IP address, and the distributed infrastructure is used to verify the authenticity of the decrypted anonymous identity, that is, the corresponding source IP address. If the destination IP address is inconsistent or the anonymous identity cannot be queried in the distributed infrastructure, the data packet is discarded and malicious information is reported. If the destination IP address is consistent and the anonymous identity is queried in the distributed infrastructure, the authenticity verification is passed and the identity authentication is completed.
[0032] The technical effects of the present invention are:
[0033] The present invention strongly binds user identity information with the source address of a data packet, and simultaneously realizes source address verification and user identity authentication.
[0034] The present invention considers the protection of user privacy information from multiple perspectives of link address and network address, and does not introduce new identifiers, and will not affect the normal operation of the existing network protocol stack.
[0035] The present invention considers performing source address authentication in scenarios across non-cooperative domains, allowing data packets carrying user privacy information to cross multiple non-cooperative domains, and is more applicable to different scenarios. BRIEF DESCRIPTION OF THE DRAWINGS
[0036] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.
[0037] The accompanying drawings, which constitute part of this application, are intended to provide a further understanding of this application. The exemplary embodiments and descriptions of this application are intended to explain this application and do not constitute an improper limitation on this application. In the accompanying drawings:
[0038] Figure 1 This is a diagram illustrating an example of application of an embodiment of the present invention in a single collaboration domain;
[0039] Figure 2 This is a diagram illustrating an example of an application of an embodiment of the present invention in cross-collaboration domain communication;
[0040] Figure 3 This is an example diagram of an application of an embodiment of the present invention in an attacker forging identity information;
[0041] Figure 4 This is an example diagram of an application of an embodiment of the present invention in which an attacker tampered with a data packet;
[0042] Figure 5 This is an authentication flow chart in an embodiment of the present invention. DETAILED DESCRIPTION
[0043] Various exemplary embodiments of the present invention will now be described in detail. This detailed description should not be considered as limiting the present invention, but rather as a more detailed description of certain aspects, features, and embodiments of the present invention.
[0044] It should be understood that the terms described herein are intended only to describe particular embodiments and are not intended to limit the present invention. In addition, for numerical ranges herein, it should be understood that each intermediate value between the upper and lower limits of the range is also specifically disclosed. Each smaller range between any intermediate value within a stated value or stated range and any other stated value or intermediate value within the stated range is also encompassed by the present invention. The upper and lower limits of these smaller ranges may be independently included or excluded within the scope.
[0045] Unless otherwise indicated, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art. Although only preferred methods are described herein, any method similar or equivalent to that described herein may also be used in the practice or testing of the present invention. All documents mentioned in this specification are incorporated by reference to disclose and describe the methods associated with the documents. In the event of any conflict with any incorporated document, the contents of this specification shall prevail.
[0046] It will be apparent to those skilled in the art that various modifications and variations may be made to the specific embodiments of the present invention without departing from the scope or spirit of the invention. Other embodiments will be apparent to those skilled in the art from the present invention. The present description and examples are intended to be illustrative only.
[0047] The words “include,” “including,” “have,” “contain,” etc. used in this article are open-ended terms, meaning including but not limited to.
[0048] It should be noted that, in the absence of conflict, the embodiments and features of the embodiments in this application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.
[0049] Example 1
[0050] like Figure 1 - Figure 5 As shown, this embodiment provides a cross-non-collaborative domain identity authentication method, including:
[0051] Negotiate the first symmetric key and corresponding MAC address list of each router using adjacent routers in the same autonomous domain in the core network, and negotiate the global group key using border routers in each cooperative domain in the core network to complete system initialization;
[0052] After the system initialization is completed, the registration server in the core network verifies the validity of the network user who sends the identity registration request. After the verification is passed, the registration server is used to generate a digital identity and an anonymous identity corresponding to the network user, and a MAC address list is configured for the network user. The registration server is used to build a mapping relationship between the digital identity, the anonymous identity and the MAC address list. The constructed mapping relationship is saved in the distributed infrastructure in the core network and sent to the network user to complete the user identity registration;
[0053] After the user identity registration is completed, the network user performs symmetric key negotiation with the adjacent router in the corresponding autonomous domain to generate a second symmetric key, and associates the second symmetric key with the MAC address list of the network user;
[0054] After the association is completed, the network user obtains the MAC information of the adjacent node based on the neighbor discovery protocol, determines the third symmetric key based on the obtained MAC information, encrypts the anonymous identity based on the address hopping engine in the network user in combination with the third symmetric key, obtains the private information and embeds it into the source IP address of the data packet, randomly selects a MAC address from the MAC address list of the network user as the source MAC address of the data packet, calculates the integrity check code of the data packet through the hash algorithm, and embeds the integrity check code into the data packet to complete the construction of the data packet;
[0055] The data packet is uploaded to each router in the core network, and during the uploading process, the data packet is authenticated within the collaborative domain and across non-collaborative domains.
[0056] Existing address hopping authentication schemes have some unresolved problems, such as difficulty in deployment on the existing network architecture after introducing new identifiers, insufficient privacy protection, and unsuitability for cross-non-collaborative domain scenarios.
[0057] To address the above issues, this embodiment proposes the following solutions:
[0058] First, a lightweight address labeling framework is designed to modify the link-layer and network-layer addresses. After obtaining the hopping parameters from the registration management server, the hopping engine performs anonymization and generates new network-layer and link-layer addresses. This strongly binds user identity information to the source address, ensuring the privacy of data packets during network transmission. After decrypting the identity information carried in the source network-layer address in the data packet using a symmetric key algorithm, the distributed infrastructure server performs authentication and confirmation, simultaneously achieving source address verification and identity authentication. A hash algorithm is then used to verify data packet integrity, promptly detecting any tampering by third-party attackers during transmission.
[0059] Secondly, it is proposed to use the global group key to encrypt the identity information of the egress router in the cooperative domain in the cross-non-cooperative domain scenario and decrypt it by the ingress router of the data packet carried to another cooperative domain to achieve cross-non-cooperative domain communication.
[0060] In summary, this embodiment introduces address hopping into the identity authentication system, realizes a strong binding relationship between the source address and the user identity, and realizes source address identity authentication. This embodiment designs a lightweight address label framework, completes authentication and identity privacy protection during network transmission through network layer address and link layer address hopping, and uses integrity verification and distributed infrastructure servers for authentication confirmation, meeting the security and reliability requirements of data. This solution uses group keys across non-collaborative domains to achieve secure communication between different collaborative domains, while ensuring the security of data transmission, it also takes into account the practicality of network communication.
[0061] This embodiment is applicable to various industries and fields that require enhanced network security and protection of identity privacy and data integrity during data transmission, including but not limited to enterprises, financial services, cloud services, the Internet of Things, government, healthcare, e-commerce, smart cities, military and defense, education and research, cross-domain communications, and mobile devices and remote work environments. It has the following advantages:
[0062] 1) This embodiment strongly binds user identity information to the source address of the data packet, thereby simultaneously implementing source address verification and user identity authentication.
[0063] 2) This embodiment considers the protection of user privacy information from multiple perspectives, including link addresses and network addresses, and does not introduce new identifiers, thus not affecting the normal operation of the existing network protocol stack.
[0064] 3) This embodiment considers performing source address authentication in scenarios across non-cooperative domains, allowing data packets carrying user privacy information to cross multiple non-cooperative domains, which is more applicable to different scenarios.
[0065] The authentication scheme provided in this embodiment is divided into five stages.
[0066] The first phase is the system initialization phase, during which the key negotiation process between routers is mainly performed.
[0067] The second stage is that the user submits identity information to the registration server for registration and obtains a legal user identity.
[0068] The third stage is the symmetric key negotiation between the user who has obtained the legal identity and the adjacent router in the autonomous domain.
[0069] The fourth stage is the data packet sending stage, where the address jump engine performs necessary operations to ensure that the data packet behavior complies with the authentication process.
[0070] The fifth stage is the router's verification of the packet's identity. This stage can be divided into two situations. The first situation is that the egress router within a single collaborative domain authenticates the packet. The successfully authenticated packet can be sent to the external network. The second situation is cross-non-collaborative domain authentication, mainly in which the ingress router of other domains verifies the packet.
[0071] Phase 1: System initialization.
[0072] During this phase, adjacent routers within the same autonomous domain must negotiate symmetric keys in advance. Symmetric key negotiation requires establishing a secure channel between routers. Typically, a pair of symmetric keys is generated without exchanging keys through a key exchange protocol such as the Diffie-Hellman algorithm. The negotiation process must ensure the randomness and unpredictability of the keys. After negotiation, each router obtains the symmetric key and a list of MAC addresses (usually consecutive) maintained by the distributed infrastructure. When a data packet needs to be sent for communication, the communicating user randomly selects an entry from this list as the source MAC address, ensuring that the source MAC address of packets sent from the same host remains within a certain range. It's important to note that the MAC list doesn't necessarily have to be consecutive, but it's relatively easy to maintain. To ensure that MAC addresses used by different users don't conflict, the distributed infrastructure must manage and maintain the association between the MAC list and user devices, and keep it updated promptly. The router then maintains the mapping between the MAC list of the communicating peer and the key.
[0073] In addition, a global group key will be negotiated between the border routers in all cooperative domains. This key is used to establish trust relationships between different cooperative domains and is the basis for data exchange across non-cooperative domains.
[0074] Phase 2: Identity registration phase.
[0075] During this stage, the user who joins the network submits his identity information to the Registration Server (RSs) through a secure channel for registration. RSs checks and verifies the validity of the user's identity, such as whether there is a duplicate registration. If the identity information is invalid, the registration request will be rejected. If valid, RSs generates a digital identity identifier DID associated with the user's identity for the user, and uses a hash function to generate an anonymous identity identifier AID = hash (DID). In order to achieve link layer address hopping, each interface of the user's device who joins the network will also obtain a set of MACList. When sending a data packet for communication, it will randomly select an item from the MACList as the source MAC address of the data packet. Afterwards, RSs saves the {DID, AID, MACList} mapping relationship in the distributed infrastructure. To further enhance security, both AID and MACList can have an expiration time, and the AID and MACList will be updated when a security threat is detected or the life cycle ends.
[0076] Finally, RSs returns {DID, AID, MACList} to the registered user. When the user receives the successful registration response, it will maintain a bidirectional mapping table between the real IP address and the AID to restore the real source IP address of the data packet.
[0077] Phase 3: Symmetric key negotiation phase.
[0078] A user who has obtained a legitimate identity will negotiate a symmetric key with an adjacent router within their autonomous domain. This process is similar to the key negotiation process between adjacent routers in the first phase. The user and the adjacent router must generate a symmetric key through a secure channel. This key is used to encrypt and decrypt subsequent identity privacy information. Only the two parties involved in the negotiation possess the corresponding key. The key negotiated between adjacent entities must be associated with the MACList of the negotiation object, with multiple MAC addresses in the MAC list mapped to the symmetric key. The symmetric key mapped to the MACList ensures that the user identity information required for authentication carried in the data packet can be encrypted and authenticated using the correct key even when the source MAC address changes.
[0079] Phase 4: Communication initiation phase.
[0080] Before sending a data packet, the user device first obtains the MAC information of the adjacent node through the neighbor discovery protocol NDP, and uses the next-hop MAC to determine the symmetric key SK used for this decryption. When the discovered next-hop MAC address cannot be matched with any MAC address in the currently saved neighbor MACList, different performances may occur depending on the different functions of the network, such as sending according to the original data packet processing flow. Normally, when the neighbor's MAC address is not included in any MACList, it will be considered that the current user has not completed the registration phase or the symmetric key negotiation phase, and all packet sending behaviors of the user should be blocked. This is because the lack of a symmetric key means that the user's privacy cannot be hidden from attackers who maliciously capture the data packet through encryption and decryption. Once the data packet is transmitted on the network, even if the domain border gateway router does not allow the data packet to be exported, it cannot guarantee that the user's identity information will not be leaked.
[0081] After obtaining the symmetric key SK, the address hopping engine on the user device needs to encrypt the user's AID, timestamp information and destination IP address with the symmetric key to generate private information that can be embedded in the data packet, that is, (EID||AVD)=E SK (AID||TS||IP dst ), where EID is Embedded Identifier and AVD is Additional Validation Data. The timestamp is used to ensure that different encryption results can be obtained when the same AID is used, so as to ensure that the source IP address of each data packet is different. The EID will be embedded in the last few bits of the source IP address of the data packet. Usually, in order to achieve a balance between the network prefix and the number of hosts, a 64-bit EID is used. The remaining part of the encryption result is AVD. The length of AVD will depend on the specific symmetric encryption algorithm. It is added to the data packet extension field together with other additional information for identity authentication by the router. These additional information do not contain plaintext information of the user's identity and are only transmitted as necessary information required for authentication. Even if an attacker captures the data packet, they cannot steal the privacy information of the data sender through this information.
[0082] The successful embedding of the EID means that the network address jump is successful. Next, the user device will randomly select an item from the MACList maintained by itself as the source MAC address of the data packet and write it into the corresponding field of the data packet.
[0083] Finally, based on the link address, network address, additional information and payload of the data packet, a hash operation is performed to obtain the data packet integrity check code ICC (Integrity Checksum Code). The data packet carrying the additional authentication information and ICC is then sent to the network for transmission.
[0084] Phase 5: Identity authentication phase.
[0085] The authentication phase requires routers along the packet transmission path to verify the identity information carried by the packet. This is done to prevent malicious traffic from spreading across the network and impacting system operation, and to verify that user identity information is protected. The authentication phase is divided into two scenarios. The first involves authentication within a single collaborative domain, primarily performed by the egress router at the domain boundary. Successfully authenticated packets are allowed onto the network. The second involves cross-domain authentication, requiring coordination between the egress router in the source domain and the ingress router in the destination domain to perform authentication.
[0086] ① Authentication within a single collaborative domain:
[0087] When a router in a single collaborative domain receives a data packet sent by a user host, it first performs an integrity check ICC. Based on the link address, network address, additional information other than the ICC, and payload of the data packet, the current ICC of the data packet is obtained through a hash operation. n , and the original ICC carried by the data packet o If the results are inconsistent, the data packet is considered to have been tampered with by a malicious middleman and should be discarded. If the results are consistent, the data packet passes the integrity check and subsequent identity authentication can proceed.
[0088] Identity authentication first requires finding the corresponding symmetric key SK based on the source MAC address of the data packet. It is worth noting that the source MAC in the data packet is not the real MAC address of the previous hop router / user host, but a randomly selected item from its corresponding MACList. Since the mapping table between MACList and symmetric key is established in advance during the system initialization and symmetric key negotiation phase, the SK can still be found from the source MAC of the data packet. If the SK is not found, it is assumed that the previous hop in the data packet transmission path used a false MAC address or an error occurred during key negotiation, and the error needs to be reported to the distributed infrastructure.
[0089] After getting SK, use it to decrypt the EID and AVD embedded in the data packet (AID||TS||IP dst )=D SK(EID||AVD). The router then compares the packet's destination IP address with the decrypted IP address, verifies the authenticity of the AID through the distributed infrastructure, and restores the original source IP address. If the destination IP address is inconsistent or the AID's user identity cannot be retrieved from the distributed infrastructure, the packet may have been sent by a forged user identity. In this case, the packet is discarded and reported as malicious. Otherwise, the packet is authenticated. Because this embodiment strongly binds user identity information to the IP address, the completion of this step means that both source address verification and user identity authentication are achieved.
[0090] ② Authentication across non-collaborative domains:
[0091] When the data packet needs to be transferred from the source cooperative domain CS s Pass through several non-cooperative domains NCS and finally reach the destination cooperative domain CS d The process of forwarding data packets to NCS is similar to the communication initiation phase. The difference is that due to the CS s There is no symmetric key negotiated between the egress router and the next-hop device in NCS, and the SK cannot be found through the next-hop MAC address. Therefore, the user identity information can only be encrypted using the global group key negotiated during the system initialization phase. After encryption, the ICC is calculated and the information required for authentication is embedded in the data packet. Finally, an item is randomly selected from the MACList as the source MAC address of the data packet, and the data packet is forwarded to NCS. The network devices in NCS will neither authenticate the data packet nor modify the additional information in the data packet. They will only perform normal routing and forwarding based on the destination address. It should be noted that CS s The ICC in the data packet sent by the egress router to the NCS no longer needs to include the link address check, because regardless of whether the link address changes, the source MAC address will change during the transmission process within the NCS. d CS is no longer available s MAC address used.
[0092] In CS d When the ingress router receives a data packet forwarded by the NCS, it first performs an integrity check, performs a hash operation on the network address, additional information other than the ICC, and the payload in the data packet, and then compares the result with the ICC field carried in the data packet. If the results are inconsistent, the data packet is considered to have been tampered with and should be discarded. Otherwise, it is considered to have passed the integrity check.
[0093] After CS dThe ingress router no longer matches the corresponding MACList based on the previous hop MAC address, but instead uses the global group key to decrypt the AID and then determines the user's true identity through the distributed infrastructure.
[0094] Example description:
[0095] Example 1:
[0096] Application of this embodiment in a single collaboration domain:
[0097] ① The system is first initialized. The users in the terminal group send a request to the registration server for legal registration to obtain the necessary user identity information and MACList, and then negotiate a symmetric key with the border router through a secure channel.
[0098] ② When a user sends a data packet trying to enter the core network, the symmetric key is first searched for based on the MAC address of the border router. After finding the symmetric key, it is used to encrypt the anonymous identity information, which is then embedded into the source IP address portion of the data packet. An item in the MACList is randomly selected as the source MAC address of the data packet, and the ICC is calculated before sending it to the border router.
[0099] ③ The border router first verifies the ICC. Once it determines that the packet has not been tampered with, it then uses the packet's source MAC address to find the symmetric key used to encrypt the packet's identity information and decrypts it, obtaining the sender's private user identity information. The router then verifies the user's identity authenticity from the infrastructure server. The specific authentication process is detailed in the previous embodiment and will not be repeated here.
[0100] Example 2:
[0101] Application of this embodiment in cross-cooperation domain communication:
[0102] ① The system is first initialized, and a global group key is negotiated between the egress router of the source collaborative domain and the ingress router of the destination collaborative domain. Users in the terminal group send a request to the registration server for legal registration to obtain the necessary user identity information and MACList, and then negotiate a symmetric key with the border routers in their respective domains through a secure channel.
[0103] ② A user sends a data packet attempting to traverse a non-cooperative domain. The packet is encrypted with a symmetric key and follows the process detailed in the preceding embodiment before arriving at the egress router of the domain. To coordinate with the destination cooperative domain, the egress router encrypts the user's identity information using the global group key and sends the packet to the non-cooperative domain.
[0104] ③ The packet's additional information remains unchanged while traversing the non-cooperative domain. Upon reaching the ingress router in the destination cooperative domain, the ingress router decrypts the identity information using the global group key and verifies the user's authenticity. The specific authentication process is detailed in the preceding embodiment and will not be repeated here.
[0105] Example 3:
[0106] Application of this embodiment in attackers forging identity information
[0107] ① The system is first initialized. Users in the terminal group and third-party attackers send requests to the registration server for legal registration to obtain the necessary user identity information and MACList, and then negotiate a symmetric key with the border router through a secure channel.
[0108] ② A third-party attacker uses forged identity information to encrypt and modify the source address of the outgoing packet. Upon receiving the packet, the border router decrypts it using the previous hop address and verifies it with the infrastructure server. If the infrastructure server responds that the user identity information does not exist, the border router immediately discards the packet and reports an error. The specific authentication process is detailed in the above embodiment and will not be repeated here.
[0109] Example 4:
[0110] Application of this embodiment in the case of an attacker tampering with a data packet
[0111] ① The system is initialized. Users in the terminal group send a request to the registration server to register legally, obtaining the necessary user identity information and MAC list. Then, a symmetric key is negotiated with the border router over a secure channel. Third-party attackers cannot interfere with the symmetric key negotiation during this phase.
[0112] ② A user sends a data packet attempting to enter the core network. After address hopping and ICC calculation, the data packet carrying private information is sent to the network for transmission and is captured by a third-party attacker. The third-party attacker modifies some fields in the data packet without modifying the source address information and then forwards it to the border router.
[0113] ③ The border router performs an integrity check and finds that the ICC calculated based on the packet information is inconsistent with the ICC carried in the packet itself. It discards the packet and reports the error to the infrastructure server. The specific authentication process has been described in detail in the above embodiment and will not be repeated here.
[0114] The lightweight address label framework designed in this embodiment directly modifies the source address, making it appear to change randomly on a hop-by-hop basis. This conceals user privacy information and enables incremental deployment on existing network architectures, increasing deployability. The strong binding between network-layer addresses and user identities satisfies both identity authentication and source address authentication, enhancing system security.
[0115] This embodiment uses authentication methods across non-cooperative domain scenarios, improving the system's ability to be applied to different scenarios.
[0116] The above description is merely a preferred embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in the present application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.
Claims
1. A cross-non-cooperative domain identity authentication method, characterized in that: include: Negotiate the first symmetric key and corresponding MAC address list of each router using adjacent routers in the same autonomous domain in the core network, and negotiate the global group key using border routers in each cooperative domain in the core network to complete system initialization; After the system initialization is completed, the registration server in the core network verifies the validity of the network user who sends the identity registration request. After the verification is passed, the registration server is used to generate a digital identity and an anonymous identity corresponding to the network user, and a MAC address list is configured for the network user. The registration server is used to build a mapping relationship between the digital identity, the anonymous identity and the MAC address list. The constructed mapping relationship is saved in the distributed infrastructure in the core network and sent to the network user to complete the user identity registration; After the user identity registration is completed, the network user performs symmetric key negotiation with the adjacent router in the corresponding autonomous domain to generate a second symmetric key, and associates the second symmetric key with the MAC address list of the network user; After the association is completed, the network user obtains the MAC information of the adjacent node based on the neighbor discovery protocol, determines the third symmetric key based on the obtained MAC information, encrypts the anonymous identity based on the address hopping engine in the network user in combination with the third symmetric key, obtains the private information and embeds it into the source IP address of the data packet, randomly selects a MAC address from the MAC address list of the network user as the source MAC address of the data packet, calculates the integrity check code of the data packet through the hash algorithm, and embeds the integrity check code into the data packet to complete the construction of the data packet; The data packet is uploaded to each router in the core network, and during the uploading process, the data packet is authenticated within the collaborative domain and across non-collaborative domains.
2. A cross-non-cooperative domain identity authentication method according to claim 1, characterized in that: The negotiation process of the first symmetric key of each router and the corresponding MAC address list specifically includes: Negotiating the first symmetric key between adjacent routers in the same autonomous domain through a secure channel and a key exchange protocol; After the first symmetric key negotiation is completed, each router saves the first symmetric key and the corresponding MAC address list.
3. A cross-non-cooperative domain identity authentication method according to claim 1, characterized in that: After the system is initialized, the registration server in the core network verifies the validity of the user who sent the identity registration request, including: The user submits identity information to the registration server through a secure channel for identity registration, and the registration server verifies the validity of the user's identity. If there is a duplicate registration, the identity information is invalid and the registration request is rejected; If there is no duplicate registration, the identity information is valid, and the registration server is used to generate a digital identity and an anonymous identity corresponding to the network user, and a MAC address list is configured for each interface of the network user device.
4. A cross-non-cooperative domain identity authentication method according to claim 1, characterized in that: The address jump engine based on the network user encrypts the anonymous identity in combination with the third symmetric key. The specific calculation formula is: (EID||AVD)=E SK (AID||TS||IP dst ) Where, EID is Embedded Identifier, AVD is Additional Validation Data, AID is Anonymous Identifier, TS is Timestamp, IP dst is the destination network layer IP address, E SK A symmetric key encryption algorithm using an SK key.
5. A cross-non-cooperative domain identity authentication method according to claim 1, characterized in that: Calculating the integrity check code of the data packet by using a hash algorithm specifically includes: Based on the link address, network address, additional information and payload of the data packet, an integrity check code of the data packet is obtained in combination with a hash operation.
6. A cross-non-cooperative domain identity authentication method according to claim 1, characterized in that: The authentication process of the collaborative domain authentication specifically includes: When a router within a single collaborative domain receives the data packet, it performs integrity verification on the integrity check code of the data packet. After the integrity verification is passed, it searches for the corresponding third symmetric key based on the source MAC address of the data packet. If the third symmetric key is not found, an error message is sent to the distributed infrastructure. If the third symmetric key is found, the anonymous identity and destination IP address are decrypted based on the obtained third symmetric key, the destination IP address of the data packet is compared with the decrypted IP address, and the distributed infrastructure is used to verify the authenticity of the decrypted anonymous identity and the corresponding source IP address. If the destination IP address is inconsistent or the anonymous identity cannot be queried in the distributed infrastructure, the data packet is discarded and malicious information is reported. If the destination IP address is consistent and the anonymous identity is queried in the distributed infrastructure, the authenticity verification is passed and the identity authentication is completed.
7. A cross-non-cooperative domain identity authentication method according to claim 6, characterized in that: The integrity verification of the integrity check code of the data packet specifically includes: A current integrity check code of the data packet is calculated based on a hash operation. If the current integrity check code is consistent with the original integrity check code of the data packet, the integrity verification is passed; if the current integrity check code is inconsistent with the original integrity check code of the data packet, the data packet is discarded.
8. A cross-non-cooperative domain identity authentication method according to claim 1, characterized in that: The cross-non-collaborative domain authentication process specifically includes: When a data packet passes through several non-cooperative domains from the source cooperative domain and finally reaches the destination cooperative domain, the user's identity information is encrypted using the global group key to obtain privacy information and embed it into the source IP address of the data packet. A MAC address is randomly selected from the MAC address list of the networked user as the source MAC address of the data packet, the integrity check code of the data packet is calculated by a hash algorithm, and the integrity check code is embedded in the data packet. The data packet is uploaded to the non-cooperative domain. When the destination cooperative domain receives the data packet, the integrity check code of the data packet is verified. After the integrity verification passes, the source MAC address of the data packet is searched. The corresponding global group key. If the global group key is not found, an error message is sent to the distributed infrastructure. If the global group key is found, the anonymous identity and destination IP address are decrypted based on the obtained global group key, the destination IP address of the data packet is compared with the decrypted IP address, and the distributed infrastructure is used to verify the authenticity of the decrypted anonymous identity, that is, the corresponding source IP address. If the destination IP address is inconsistent or the anonymous identity cannot be queried in the distributed infrastructure, the data packet is discarded and malicious information is reported. If the destination IP address is consistent and the anonymous identity is queried in the distributed infrastructure, the authenticity verification is passed and the identity authentication is completed.