Methods for protecting critical information during the mobile IPv6 return path reachability process

Abstract

This invention discloses a method for protecting critical information during the return path reachability process in Mobile IPv6. It primarily addresses the security issue of the original return path reachability mechanism's lack of encryption of critical information. The implementation involves introducing a new method where both parties calculate the same hash value using publicly transmitted information. During the return path reachability process, identity-based, unpaired two-party authentication key negotiation is performed, enabling the mobile node and its communication peer to negotiate and share a session key when exchanging messages. Critical information is then symmetrically encrypted. A portion of the mobile node's temporary public key is used as both the home initial cookie value and the handover initial cookie value, respectively, to intuitively verify message matching while ensuring randomness. This invention improves upon the original return path reachability mechanism, circumvents the computationally complex bilinear pairing operations of existing technologies, significantly improves computational and communication efficiency, and provides strong security. It can be used for routing optimization in Mobile IPv6.

Description

Technical Field

[0001] This invention belongs to the field of information security technology, and specifically relates to a method for protecting critical information using authentication key negotiation technology during the return path reachability process of Mobile IPv6, which can be used for routing optimization of Mobile IPv6. Background Technology

[0002] With the development of network technology and the arrival of the high-tech information age, Mobile IPv6, as a guiding document proposed by the IETF to solve mobile connectivity problems in the IPv6 environment, is regarded as the fundamental theory for next-generation Internet mobile communication. Mobile IPv6 is built on the IPv6 protocol architecture and is an extension of the IPv6 protocol, providing support for next-generation network mobility. Its aim is to ensure that mobile nodes (MNs) can always maintain uninterrupted network connectivity or access the Internet anytime, anywhere, regardless of whether they are on their home network or a foreign network, using their globally unique home address, thus guaranteeing smooth communication for mobile terminals during Layer 3 network handover processes.

[0003] One of the key processes in Mobile IPv6 is communication between the MN (Network Node) and its communication peer (CN). Since the CN communicating with the MN could be a fixed device or a mobile device, the MN advertises its care-of address to the CN, thus establishing a binding between the MN's home address and the care-of address. This is called peer binding update. Mobile IPv6's support for peer binding update optimizes data packet routing, allowing the CN to communicate directly with the MN without going through the home agent (HA). This reduces the processing burden on the HA, significantly conserves network resources, avoids the impact of HA and home link failures, enhances network reliability and scalability, and improves communication efficiency.

[0004] However, route optimization, as a mandatory part of the Mobile IPv6 protocol, while improving communication efficiency, also introduces certain security risks. Considering the need for node authentication to ensure the security of binding update messages, the MN needs to initiate a path reachability return process before starting the peer binding update management process. This process involves two steps: firstly, requesting the CN to test whether it can be accessed through the MN's claimed home address and care-of address; secondly, the MN generates a binding management key based on the received critical information, used for authenticating binding update management messages. If the path reachability return process fails, peer binding updates cannot be performed, the CN will not receive the mobile host's binding update message, and will not be able to directly send data packets using its care-of address.

[0005] The return path reachability procedure plays a crucial role in the binding update and confirmation between MN and CN. After the return path reachability procedure is completed, MN is certain that CN can access it through either the home address or the care-of address, and uses the obtained key information to calculate the binding management key for authentication between nodes in subsequent binding management processes. However, the security of the return path reachability procedure relies on the assumption that messages transmitted on the two paths, CN and MN, and HA and MN, cannot be intercepted simultaneously. Therefore, if an attacker can monitor these paths and eavesdrop on communications to obtain the necessary information, the protection of the return path reachability procedure becomes ineffective. If an attacker can capture or monitor the Home Test Initial Message (HoTI) and Home Test Message (HoT) and Care-of Test Initial Message (CoTI) and Care-of Test Message (CoT) pairs involved in the entire process, since the two key pieces of information for generating the binding management key—the Home Key Generation Token (HoKT) and the Care-of Key Generation Token (CoKT)—are sent in plaintext in the HoT and CoT messages, the attacker can easily generate MN's binding management key based on the intercepted key information. This allows the attacker to impersonate MN and initiate an illegal binding update management process, thereby deceiving the communication peer.

[0006] Specifically, the main security issues and vulnerabilities in the return path reachability process are:

[0007] (1) When the attacker is on the CN’s local link, he can intercept the HoT message and CoT message, and then successfully construct the binding management key, and then send the forged binding update message to the CN to perform incorrect binding management.

[0008] (2) When the attacker is on the local link of HA, he can intercept and maliciously tamper with the HoTI messages sent by MN, via HA and sent back by CN, thus interfering with normal communication between nodes.

[0009] (3) When the attacker is on the MN's local link, they can forge the target address as a care-of address and send two test initial messages using their legitimate home address. After the CN completes processing, the attacker receives the HoT message and simultaneously eavesdrops on the CoT message, generating a binding management key and continuously sending binding update messages to the CN. The CN confirms the attacker's legitimate ownership of the claimed care-of address and continuously sends binding confirmation messages back to the care-of address, enabling the attacker to achieve their goal of launching a denial-of-service attack on the target address.

[0010] Existing technologies primarily combine identity-based public-key cryptography to ensure that the return path reachability process meets the requirements of traditional security protocols, in order to provide identity authentication services and encryption services for critical information.

[0011] The paper "Secure framework for the return routability procedure in MIPv6" utilizes Boneh and Franklin's identity-based encryption scheme BF-IBE, and based on the bilinear property of modified Weil pairs on supersingular elliptic curves, proposes a secure framework for the return path reachability procedure, aiming to enhance the security of the return path reachability mechanism without affecting the performance of mobile nodes. The security framework designed in this paper includes two security primitives: encryption and signature, and introduces a private key generation center (PKG) in the return path reachability process. However, this paper only presents the framework design and does not provide a specific implementation scheme.

[0012] The paper "Integrating identity-based encryption in the return routability protocol to enhance signal security in mobile IPv6" designs a complete return path protocol, called RR-IBEP, that enables strong security and authentication between MN and CN. It performs three identity-based encryption operations during the return path reachability process, expanding the original two message pairs (HoTI and CoTI, HoT and CoT) into five messages for direct interaction between MN and CN. In this scheme, MN needs to perform one symmetric bilinear pairing operation, three modular exponentiation operations on the multiplicative group, and three pairing-based doubling operations, while CN needs to perform two symmetric bilinear pairing operations. Since bilinear pairing is a computationally very complex cryptographic operation, taking at least 3 to 20 times longer than doubling operations on elliptic curve point groups, RR-IBEP does not have an efficiency advantage. Furthermore, the scheme itself cannot resist man-in-the-middle attacks on the MN-CN path and cannot guarantee data integrity.

[0013] The paper "A certificateless public key encryption based return routability protocol for next-generation IP mobility to enhance signalling security and reduce latency" considers the problems of the RR-IBEP mechanism, such as key escrow and key revocation, as well as its high computational overhead and latency. Based on the RR-IBEP protocol, it designs a next-generation mobile IP return path protocol based on certificateless public key encryption. However, the construction process of the certificateless public key cryptosystem is much more complex than that of the identity-based public key cryptosystem, and it cannot solve the problems of efficiency and security very well.

[0014] Patent document CN105119832B discloses a MIPv6 secure mobile management system and mobile authentication method based on identity cryptography. It performs three identity-based encryption operations and two identity-based signature operations during the return path reachability process, establishing a shared key through a single round of Diffie-Hellman key exchange. However, similar to the shortcomings of the RR-IBEP protocol, it suffers from high computational overhead and communication bandwidth due to the involvement of multiple complex symmetric bilinear pairing operations, resulting in less than ideal practical efficiency. Summary of the Invention

[0015] The purpose of this invention is to address the shortcomings of the prior art by proposing a method for protecting critical information during the reachability of the mobile IPv6 return path based on authentication key negotiation. This method achieves authentication and strong security during the reachability of the return path while ensuring low computational cost and low communication bandwidth, thus ensuring the data integrity and confidentiality of critical information.

[0016] The technical approach to achieving the objective of this invention is as follows: Based on identity-based public-key cryptography, an identity-based two-party authentication key negotiation method is introduced into the original return path reachability mechanism, enabling MN and CN to negotiate a session key with implicit identity authentication. This session key is then used with a symmetric encryption algorithm to encrypt HoKT and CoKT, thereby protecting critical information during the return path reachability process and preventing adversaries from obtaining this information and generating the correct binding management key through various attacks. Based on elliptic curve cryptography, a lightweight unpaired two-party authentication key negotiation method based on doubling operations on elliptic curve addition groups is introduced, thereby improving both computational and communication efficiency.

[0017] Based on the above ideas, the implementation steps of the present invention include the following:

[0018] (1) During the process of mobile IPv6 returning the path reachability, an identity-based public key cryptosystem is established through the key generation center KGC to extract the long-term private key pair between the mobile node MN and the communication peer node CN.

[0019] (2) The mobile node MN sends a Home Trial Initialization Message (HoTI) and a Handover Trial Initialization Message (CoTI) to the communication peer node CN:

[0020] (2a) MN obtains the publicly available system parameters published by KGC and verifies that KGC is the long-term private key pair {s} it extracted. MN ,R MN To determine if a key is legal and valid, randomly select a temporary key 'a' and calculate the temporary public key 'T'. MN Using T MN Generate the initial home cookie value for subsequent verification. and transfer the initial cookie value

[0021] (2b) MN sends a HoTI message to CN via the home agent HA to request the home key to generate the token KoKT;

[0022] (2c) MN simultaneously sends a CoTI message to CN, requesting to obtain the handover key to generate the token CoKT;

[0023] (3) The communication peer node CN receives the HoTI and CoTI messages, generates a shared session key negotiated with the mobile node MN, encrypts key information, and sends the Home Test Message HoT and Handover Test Message CoT to the mobile node MN:

[0024] (3a) The CN receives the HoTI and CoTI messages sent by the MN and obtains the MN's identity ID. MN Restore public key parameter R MN and temporary public key T MN And then use T MN Generate the initial home cookie value HoI for subsequent verification. ck With the initial cookie value CoI transferred ck ;

[0025] (3b) CN obtains the publicly available system parameters published by KGC and verifies that KGC is the long-term private key pair {s} extracted by it. CN ,R CN To determine if a key is legal and valid, randomly select a temporary key b and calculate the temporary public key T. CN Then calculate the hash value l CN-MN and session key negotiation parameter K CN-IDAKA Generate session key sk CN ;

[0026] (3c) The CN generates a 64-bit home key token HoKT using the negotiated session key sk. CN Symmetric encryption yields 64-bit ciphertext.

[0027] (3d) CN generates a 64-bit handover key and a token CoKT, using the negotiated session key sk. CN Symmetric encryption yields 64-bit ciphertext.

[0028] (3e)CN sends a HoT message to MN via the home agent HA in response to the HoTI message;

[0029] (3f) CN simultaneously sends a CoT message to MN in response to the CoTI message;

[0030] (4) The mobile node MN receives the HoT message and the CoT message, and generates a shared session key negotiated with the communication peer node CN to decrypt and obtain key information:

[0031] (4a) The MN receives the HoT and CoT messages sent by the CN and verifies them. and Is it true or false?

[0032] If the equation is not true, MN will silently ignore the received message;

[0033] Otherwise, MN obtains the CN's identity ID from the received message. CN Public key parameter R CN and temporary public key T CN To calculate the hash value l MN-CN and session key negotiation parameter K MN-IDAKA Generate session key sk MN ;

[0034] (4b) MN uses session key sk MN Decrypt the two received ciphertexts and The plaintext HoKT and CoKT are recovered, and key decryption information and temporary random number index information contained in the received message are recorded.

[0035] Compared with the prior art, the present invention has the following advantages:

[0036] Firstly, it has stronger session key security.

[0037] The shared session key negotiated between MN and CN in this invention depends not only on the long-term private key and temporary key of both parties, but also on the same hash value calculated by both parties. Therefore, it satisfies security properties such as known key security, perfect forward security, KGC forward security, anti-key leakage spoofing, anti-man-in-the-middle attack, and anti-temporary key leakage, and has strong security.

[0038] Secondly, it offers stronger data confidentiality.

[0039] This invention achieves stronger data confidentiality for key information by having the CN use a negotiated session key to symmetrically encrypt the critical information HoKT and CoKT respectively before sending the HoT and CoT messages, and the MN decrypts them using the session key after receiving the messages. This ensures that the critical information HoKT and CoKT are no longer transmitted in plaintext, and adversaries cannot decrypt and obtain the critical information in any way.

[0040] Third, it has stronger data authentication and integrity.

[0041] In this invention, MN and CN have achieved implicit identity authentication through an identity-based authentication key negotiation process. Therefore, when MN is unable to decrypt the information encrypted by CN with the session key, or when the information decrypted by MN is invalid, MN will realize that the identity of the peer entity communicating with it may be impersonated by an adversary, and the exchanged messages may have been forged and tampered with. CN will also realize these problems, thus achieving stronger data authentication and integrity of key information.

[0042] Fourth, it has stronger anti-denial-of-service attributes.

[0043] In this invention, the KGC authenticates the MN and CN before extracting the long-term private key pair, ensuring that unauthenticated attackers cannot obtain legitimate long-term private key pairs for the session key negotiation process. Therefore, when an attacker is on the MN's local link, even if they can use the MN's legitimate home address to send a HoTI message with a forged care-of address, they still cannot launch a denial-of-service attack without knowing the session key, thus achieving stronger anti-denial-of-service properties.

[0044] Fifth, it has stronger anti-deception properties.

[0045] In this invention, MN calculates the temporary public key T using a randomly selected temporary key a. MN It can be made via T MNThe initial home cookie value and the initial handover cookie value generated by the x and y coordinates are fresh random numbers. These two fresh values ​​will be sent back in the HoT and CoT messages to facilitate the MN's intuitive verification of whether the HoTI and HoT messages and the CoTI and CoT messages match. This effectively prevents nodes that have not received the HoTI and CoTI messages from giving a deceptive response to the MN.

[0046] Sixth, it has higher computational efficiency.

[0047] In negotiating the session key for encrypting key information, this invention avoids the computationally complex bilinear pairing operation and the complex hash operation mapped to the elliptic curve point group in the prior art, since MN and CN only perform 4 doubling operations on the elliptic curve addition group, 2 hash operations mapped to the modulo large prime multiplication group, and 1 hash operation mapped to the fixed-length bit string. This results in less computation time, smaller key size, and lower processing complexity, thus improving computational efficiency.

[0048] Seventh, it has higher communication efficiency.

[0049] This invention combines two pairs of messages in the return path reachability process to exchange key negotiation information. The HoTI and CoTI messages each transmit only the x and y coordinates of a point element on an elliptic curve addition cyclic group G. The HoT and CoT messages each transmit only a 64-bit cookie value, a 64-bit ciphertext, a 16-bit temporary random number index, and a point element on one group G. This achieves lower message size and communication bandwidth, and improves communication efficiency.

[0050] Eighth, it has lower storage requirements.

[0051] In this invention, MN and CN only need to calculate one session key negotiation parameter, and the same hash value pre-calculated by both parties is used when generating the final session key, so that MN and CN no longer need to store each other's temporary public key, reducing the requirements for device storage capacity. Attached Figure Description

[0052] Figure 1 This is a scene diagram of the present invention;

[0053] Figure 2 This is a flowchart illustrating the implementation of the present invention;

[0054] Figure 3 This is a schematic diagram of the key generation center KGC extracting long-term private key pairs in this invention;

[0055] Figure 4 This is a schematic diagram illustrating how the mobile node MN calculates negotiation information and sends HoTI and CoTI messages in this invention;

[0056] Figure 5 This is a schematic diagram illustrating the generation of a shared session key by the communication peer node CN in this invention;

[0057] Figure 6 This is a schematic diagram illustrating how the communication peer node (CN) encrypts key information and sends HoT and CoT messages in this invention.

[0058] Figure 7 This is a schematic diagram illustrating how the mobile node MN generates a shared session key and decrypts it to obtain key information in this invention. Detailed Implementation

[0059] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, other embodiments obtained by those skilled in the art without creative effort should all fall within the protection scope of the present invention.

[0060] Reference Figure 1 In the scenario of this invention, four functional entities are included: mobile node MN, communication peer node CN, home agent HA, and key generation center KGC. Among them:

[0061] Mobile Node (MN): As a host or router in the network, it is a mobile IPv6-enabled device that can roam between different networks;

[0062] Communication peer node CN: As a host or router in the network, it is a mobile or fixed device that can communicate with MN and is responsible for maintaining the binding update list;

[0063] Home Agent (HA): As a router in the MN's home link, it is a mobile IPv6-enabled device that can handle addressing and packet forwarding. It is used to intercept and encapsulate data packets sent to the MN's home address and use tunnels to transmit them to the MN's registered care-of address.

[0064] Key Generation Center (KGC): As an introduced trusted third party, it is responsible for establishing an identity-based public-key cryptosystem, extracting long-term private key pairs of MN and CN, and completing the secure distribution of long-term private key pairs.

[0065] Reference Figure 2 The implementation steps of this invention are as follows:

[0066] Step 1: KGC establishes an identity-based public-key cryptosystem.

[0067] 1.1) Given system security parameters k∈N, KGC selects a large prime number q with k bits to generate system parameters that meet the security requirements. in:

[0068] It is a prime field of order q. It is defined in the prime field Elliptic curve on, It is an elliptic curve The abelian group formed by point-to-point addition operations on G is the elliptic curve group. An additive cyclic subgroup of order p, where p is a generator of the subgroup G;

[0069] 1.2) KGC selected the following three collision-resistant cryptographic hash functions:

[0070]

[0071]

[0072]

[0073] Where: {0,1} * Represents a bit string of arbitrary length, {0,1} k This represents a bit string of length k. Denotes the multiplication group modulo p;

[0074] 1.3) KGC randomly selects the system master key Computing system public key:

[0075] P pub =s·P;

[0076] 1.4) KGC publishes system parameters And save the master key s as a secret parameter.

[0077] Step 2: KGC extracts the long-term private key pair of MN and CN.

[0078] Reference Figure 3 The implementation of this step is as follows:

[0079] 2.1) MN and CN each initiate a registration request to KGC using their respective identity identifiers, requesting to obtain a long-term private key pair for session key negotiation, wherein MN's identity identifier ID... MN It is its globally unique home address, the CN identity ID. CN It is its IP address;

[0080] 2.2) KGC authenticates the MN that initiated the registration request:

[0081] If authentication fails, KGC ignores the registration request;

[0082] Otherwise, KGC selects a random number. Calculate the public key parameter R of MN MN and hash value h MN Generate the long-term private key s of MN. MN Obtain the long-term private key pair {s} of MN. MN ,R MN}:

[0083] R MN =r MN ·P

[0084] h MN =H1(ID) MN ||R MN )

[0085] s MN =r MN +h MN ·s

[0086] Where: || represents concatenation, P and H1 are the generator and hash function in the system parameters, respectively, and s is the system master key;

[0087] 2.3) KGC transmits the long-term private key pair {s} through a secure channel. MN ,R MN Send a registration response to MN;

[0088] 2.4) KGC authenticates the CN that initiates the registration request:

[0089] If authentication fails, KGC ignores the registration request;

[0090] Otherwise, KGC selects a random number. Calculate the public key parameter R of CN CN and hash value h CN This generates the long-term private key s of CN. CN Obtain CN's long-term private key pair {s CN ,R CN}:

[0091] R CN =r CN ·P

[0092] h CN =H1(ID) CN ||R CN );

[0093] s CN =r CN +h CN·s

[0094] 2.5) KGC transmits the long-term private key pair {s} through a secure channel. CN ,R CN Send it to CN to receive a registration response.

[0095] Step 3: MN calculates the negotiation information and sends HoTI and CoTI messages to CN.

[0096] Reference Figure 4 The implementation of this step is as follows:

[0097] 3.1) MN obtains the publicly available system parameters param published by KGC, including the elliptic curve additive cyclic subgroup G, the order p of group G, the generator P of group G, and the KGC system public key P. pub Hash function H, hash function H1, and hash function H2;

[0098] 3.2) MN receives the long-term private key pair {s} MN ,R MN}, through equation s MN ·P=R MN +H1(ID MN ||R MN )·P pub Verify that the received private key is valid:

[0099] If the equation is not true, MN will resubmit the registration request to KGC;

[0100] Otherwise, MN obtains a valid long-term private key s. MN and public key parameter R MN And according to the public key parameter R MN Obtain its x-coordinate With y coordinate

[0101]

[0102]

[0103] Where: getX(R) MN ) and getY(R MN ) respectively represent taking R MN x and y coordinates;

[0104] 3.3) MN randomly selects a temporary key. Calculate the temporary public key Y MN And based on the temporary public key T MN Obtain its x-coordinate With y coordinate

[0105] T MN =a·s MN ·P

[0106]

[0107]

[0108] Where: getX(T) MN ) and getY(T MN ) respectively represent taking T MN x and y coordinates;

[0109] 3.4) MN is taken The first 64 bits are used to generate the initial home cookie value for subsequent verification.

[0110]

[0111] in: Function representation of taking The first 64 bits;

[0112] 3.5) MN take The first 64 bits are used to generate the initial cookie value for subsequent verification.

[0113]

[0114] in: Function representation of taking The first 64 bits;

[0115] 3.6) MN sends a HoTI message to CN via its home proxy HA, with the source address being MN's home address and the destination address being CN's IP address. The message parameters are... Request to obtain the Home Key to generate a token HoKT;

[0116] 3.7) MN simultaneously sends a CoTI message to CN, with its source address being MN's care-of address and its destination address being CN's IP address. The message parameters are... Request to obtain the handover key to generate the token CoKT.

[0117] Step 4: After receiving the message, CN generates a shared session key negotiated with MN.

[0118] Reference Figure 5 The implementation of this step is as follows:

[0119] 4.1) CN recovers MN's public key parameter R from the received HoTI and CoTI message parameters. MNand temporary public key T MN :

[0120]

[0121]

[0122] in: and R respectively MN x and y coordinates and T represents respectively MN x and y coordinates;

[0123] 4.2) CN is taken The first 64 bits are used to generate the initial home cookie value HoI for subsequent verification. ck :

[0124]

[0125] 4.3) CN The first 64 bits are used to generate the initial cookie value CoI for subsequent verification. ck :

[0126]

[0127] 4.4) CN obtains the publicly available system parameters paran published by KGC, including the elliptic curve additive cyclic subgroup G, the order p of group G, the generator P of group G, and the KGC system public key P. pub Hash function H, hash function H1, and hash function H2;

[0128] 4.5) CN receives long-term private key pair {s CN ,R CN After that, through equation s CN ·P=R CN +H1(ID CN ||R CN )·P pub Verify that the received private key is valid:

[0129] If the equation is not true, CN will resubmit the registration request to KGC;

[0130] Otherwise, CN obtains a legitimate long-term private key s CN and public key parameter R CN ;

[0131] 4.6) CN randomly selects a temporary key b and calculates the temporary public key T. CN Then calculate the hash value l CN-MNand session key negotiation parameter K CN-IDAKA Generate a session key sk for symmetric encryption. CN :

[0132] T CN =b·s CN ·P

[0133] l CN-MN =H2(ID) MN ||ID CN ||R MN ||R CN ||T MN ||T CN )

[0134] K CN-IDAKA =(b·l CN-MN +1)·s CN ·(l CN-MN ·T MN +R MN +H1(ID MN ||R MN )·P pub )

[0135] sk CN =H(ID) MN ||ID CN ||l CN-MN ||K CN-IDAKA )

[0136] Among them: ID MN With ID CN These are the identity identifiers for MN and CN, respectively.

[0137] Step 5: CN encrypts key information and sends a Home Test Message (HoT) and a Handover Test Message (CoT) to MN.

[0138] Reference Figure 6 The implementation of this step is as follows:

[0139] 5.1) Following the original return path reachability process, CN generates a 64-bit home key generation token HoKT:

[0140] HoKT = First(64, HMAC_SHA1(K CN ,(HoA||nonce||0)))

[0141] Where: K CN It is the node key generated locally by CN, nonce represents a temporary random number generated periodically by CN, HoA represents the home address of MN, and HMAC_SHA1(K CNThe function (HoA||nonce||0) indicates that the SHA1 algorithm and key K are used. CN Calculate the message authentication code (HoA||nonce||0) for the message. The First function means to take the first 64 bits of the message authentication code.

[0142] 5.2) CN uses the negotiated session key sk CN The generated HoKT is symmetrically encrypted to obtain 64-bit ciphertext.

[0143]

[0144] Where: Encrypt(sk CN The `HoKT` function indicates the use of the shared session key `sk`. CN Symmetric encryption of plaintext HoKT;

[0145] 5.3) Following the original return path reachability process, CN generates a 64-bit home key generation token (CoKT):

[0146] CoKT = First(64, HMAC_SHA1(K CN ,(CoA||nonce||1)))

[0147] Where: CoA represents the handover address of MN, HMAC_SHA1(K CN The function (CoA||nonce||1) indicates that the SHA1 algorithm and key K are used. CN Calculate the message authentication code (CoA||nonce||1);

[0148] 5.4) CN uses the negotiated session key sk CN The generated CoKT is symmetrically encrypted to obtain 64-bit ciphertext.

[0149]

[0150] Where: Encrypt(sk CN The `CoKT` function indicates the use of the shared session key `sk`. CN Symmetric encryption of plaintext CoKT;

[0151] 5.5) CN sends a Hot message to MN via its home proxy HA, with the source address being CN's IP address and the destination address being MN's home address. The message parameters are... This message responds to the HoTI message, where: Ho nonce_index It is the index of the temporary random number from the home region used by CN to generate HoKT;

[0152] 5.6) CN simultaneously sends a CoT message to MN, with its source address being CN's IP address, its destination address being MN's care-of address, and its message parameters being... This message responds to the CoTI message, where: Co nonce_index It is the index of the temporary random number used by CN to generate CoKT.

[0153] Step 6: After receiving the message, the mobile node generates a shared session key negotiated with the communication peer node, and decrypts it to obtain the key information.

[0154] Reference Figure 7 The implementation of this step is as follows:

[0155] 6.1) The MN receives the HoT and CoT messages sent by the CN and verifies them. and Is it true or false?

[0156] If the equation is not true, MN will silently ignore the received message;

[0157] Otherwise, MN obtains the CN's identity ID from the received message. CN Public key parameter R CN and temporary public key T CN Calculate the hash value l MN-CN and session key negotiation parameter K MN-IDAKA Generate session key sk MN :

[0158] l MN-CN =H2(ID) MN ||ID CN ||R MN ||R CN ||T MN ||T CN )

[0159] K MN-IDAKA =(a·l MN-CN +1)·s MN ·(l MN-CN ·T CN +R CN +H1(ID CN ||R CN )·P pub )

[0160] sk MN =H(ID) MN ||ID CN ||l MN-CN ||K MN-IDAKA )

[0161] Among them: ID MN With ID CN These are the identity identifiers for MN and CN, respectively.

[0162] 6.2) MN uses session key sk MN Decrypt the two received ciphertexts and The plaintext key information HoKT and CoKT are recovered, and the decrypted key information and the two temporary random number indexes Ho contained in the received message are recorded. nonce_index and Co nonce_index The steps to decrypt and obtain key information are as follows:

[0163]

[0164]

[0165] in: The function indicates the use of the key sk MN For ciphertext Decryption is required. The function indicates the use of the key sk MN For ciphertext Decryption is performed.

[0166] Because CN and MN use the negotiated session key to symmetrically encrypt and decrypt the two critical messages HoKT and CoT respectively during the return path reachability process, the critical information is no longer sent in plaintext during communication. Furthermore, because the session key negotiated by MN and CN satisfies strong security, even if an attacker eavesdrops on the HoT and CoT messages, they still cannot calculate the session key in any way, and therefore cannot decrypt it to obtain the two keys to generate tokens, thus achieving protection of the critical information during the return path reachability process.

[0167] The effectiveness of this invention can be theoretically proven by calculating the session key sk using MN. MN Session key sk calculated with CN CN The consistency further illustrates:

[0168] Because MN calculates the session key negotiation parameter K MN-IDAKA At that time, the temporary public key used by the peer is:

[0169] T CN =b·s CN ·P

[0170] And it calculates R CN +H1(ID CN ||R CN )·P pub With s CNThe values ​​of P are equal, so k MN-IDAKA It can be represented as:

[0171] K MN-IDAKA =(a·l MN-CN +1)·s MN ·(l MN-CN ·b·s CN ·P+s CN ·P)

[0172] =(a·l MN-CN +1)·s MN ·(b·l MN-CN +1)·s CN ·P

[0173] Where: b and s CN These are the temporary key and long-term private key for CN, respectively, and P is the generator in the system parameters.

[0174] Similarly, since CN calculates the session key negotiation parameter K CN-IDAKA At that time, the temporary public key used by the peer is:

[0175] T MN =a·s MN ·P,

[0176] And it calculates R MN +H1(ID MN ||R MN )·P pub With S MN The values ​​of P and K are equal, therefore K CN-IDAKA It can be represented as:

[0177] K CN-IDAKA =(b·l CN-MN +1)·s CN ·(l CN-MN ·a·s MN ·P+s MN ·P)

[0178] =(a·l CN-MN +1)·(b·l CN-MN +1)·s CN ·s MN ·P

[0179] Where: a and s MN These are MN's temporary key and long-term private key, respectively.

[0180] And because of participating in K MN-IDAKA Calculated hash value l MN-CN With participation K CN-IDAKA Calculated hash value l CN-MNGenerate them in the following ways respectively:

[0181] l MN-CN =H2(ID) MN ||ID CN ||R MN ||R CN ||T MN ||T CN )

[0182] l CN-MN =H2(ID) MN ||ID CN ||R MN ||R CN ||T MN ||T CN )

[0183] Then it is obvious that l MN-CN =l CN-MN Therefore, K MN-IDAKA and K CN-IDAKA satisfy:

[0184] K MN-IDAKA =K CN-IDAKA

[0185] That is, the session key negotiation parameter K calculated by MN. MN-IDAKA Session key negotiation parameter K calculated with CN CN-IDAKA It satisfies consistency.

[0186] Furthermore, since MN and CN use the same identity identifier, hash value, and session key negotiation parameters to generate the session key, the session key calculated by both is also the same, i.e., sk. MN =sk CN .

[0187] Based on the principle of encryption / decryption consistency in symmetric cryptography, since the session key used by CN to encrypt the key information is the same as the session key used by MN for decryption, MN can use the decryption algorithm and the negotiated session key to decrypt and obtain the correct plaintext key information HoKT and CoKT.

[0188]

[0189]

[0190] This achieves the protection of critical information during the return path reachability process.

[0191] It should be noted that the step numbers in the specification and claims of this invention are only for the purpose of clearly describing the embodiments of this invention and facilitating understanding, and their order is not limited.

Claims

1. A method for protecting critical information during the mobile IPv6 return path reachability process, characterized in that, The method does not employ bilinear pairing operations, but instead uses doubling operations of elliptic curve additive groups to achieve identity-based two-party authentication key negotiation; it employs a collision-resistant cryptographic hash function that does not map to elliptic curve point groups; specifically, it includes the following steps: (1) During the process of mobile IPv6 returning the path reachability, an identity-based public key cryptosystem is established through the key generation center KGC to extract the long-term private key pair between the mobile node MN and the communication peer node CN; (2) The mobile node MN sends the Home Trial Initialization Message (HoTI) and the Handover Trial Initialization Message (CoTI) to the communication peer node CN: (2a) MN obtains the publicly available system parameters published by KGC, including the elliptic curve addition cyclic subgroup. ,group The level ,group generator KGC's system public key Hash function Hash function and hash function Verify that KGC is the long-term private key pair it extracted. Whether it is legal and valid, a temporary key is randomly selected. Calculate the temporary public key ,use Generate the initial home cookie value for subsequent verification. and transfer the initial cookie value ; ； (2b) MN sends a HoTI message to CN via the home agent HA to request the home key to generate a token. ; (2c) MN simultaneously sends a CoTI message to CN, requesting to obtain the handover key to generate a token. ; (3) The communication peer node CN receives the HoTI and CoTI messages, generates a shared session key negotiated with the mobile node MN, encrypts key information, and sends the Home Test Message HoT and the Handover Test Message CoT to the mobile node MN: (3a) The CN receives the HotI message and CoTI message sent by the MN and obtains the identity of the MN. Restore public key parameters and temporary public keys And then use Generate the initial home cookie value for subsequent verification. With transfer of initial cookie value ; (3b) CN obtains the publicly available system parameters published by KGC and verifies that KGC is the long-term private key pair it extracted from. Whether it is legal and valid, a temporary key is randomly selected. Calculate the temporary public key Then calculate the hash value. and session key negotiation parameters Generate session key The implementation is as follows: (3b1) The communication peer node CN obtains the publicly available system parameters published by KGC, including the elliptic curve addition cyclic subgroup. ,group The level ,group generator KGC's system public key Hash function Hash function and hash function ; (3b2) CN receives long-term private key pair Then, through equations Verify that the received private key is valid: If the equation is not true, CN will re-initiate the registration request; Otherwise, CN obtains a legitimate long-term private key. and public key parameters ; (3b3) CN randomly selected Calculate the temporary public key : ； (3b4) CN calculates hash value and session key negotiation parameters Generate session key The formulas are as follows: ； ； ； in: and These are the identity identifiers for MN and CN, respectively. (3c) CN generates a 64-bit home key to generate a token. Use the negotiated session key Symmetric encryption yields 64-bit ciphertext. ; (3d) CN generates a 64-bit handover key and generates a token. Use the negotiated session key Symmetric encryption yields 64-bit ciphertext. ; (3e) CN sends a Hot message to MN via the home agent HA in response to the Hot message; (3f) CN simultaneously sends a CoT message to MN in response to the CoTI message; (4) The mobile node MN receives the HoT message and the CoT message, and generates a shared session key negotiated with the communication peer node CN to decrypt and obtain key information: (4a) The MN receives the HoT message and CoT message sent by the CN and verifies them. and Is it true or false? If the equation is not true, MN will silently ignore the received message; Otherwise, MN obtains the identity identifier of CN from the received message. Public key parameters and temporary public key To calculate hash value and session key negotiation parameters Generate session key ; (4b) MN uses session keys Decrypt the two received ciphertexts and To recover the plaintext and It also records key information about decryption and temporary random number index information contained in the received message.

2. The method according to claim 1, characterized in that, Step (1) Establish an identity-based public-key cryptosystem through the Key Generation Center (KGC), as follows: (1a) Given system security parameters KGC selected Large prime numbers Generate system parameters ,in Is the order as The elemental domain, It is defined in Elliptic curve on, yes The abelian group formed by point-to-point addition operations on the point, yes The upper level is The addition cyclic subgroup, It is a group A generator; (1b) KGC selected three collision-resistant cryptographic hash functions: , , ,in Represents a bit string of arbitrary length. Indicates length is bit string, Modulus The multiplication group; (1c) KGC randomly selects the system master key public key of computing system ; (1d) KGC publishes system parameters Store the master key As a secret parameter.

3. The method according to claim 1, characterized in that, In step (1), the long-term private key pair between the mobile node MN and the communication peer node CN is extracted through the key generation center KGC, as follows: (1e) The mobile node MN and the communication peer node CN respectively initiate a registration request to KGC, requesting to obtain a long-term private key pair for session key negotiation, wherein the identity identifier of MN is... It is its globally unique home address, the CN identifier. It is its IP address; (1f) KGC authenticates the MN that initiated the registration request: If authentication fails, KGC ignores the registration request; Otherwise, KGC selects a random number. Calculate the public key parameters of MN. and hash value Generate the long-term private key for MN. and with Form a long-term private key pair ,in Indicates cascading; (1g) KGC transmits long-term private key pairs via a secure channel Send a registration response to MN; (1h) KGC authenticates the CN that initiated the registration request: If authentication fails, KGC ignores the registration request; Otherwise, KGC selects a random number. Calculate the public key parameters of CN. and hash value This generates a long-term private key for the CN. and with Form a long-term private key pair ; (1i) KGC transmits long-term private key pairs through a secure channel Send to CN to receive a registration response.

4. The method according to claim 1, characterized in that, Step (2a) is implemented as follows: (2a1) The mobile node MN obtains the publicly available system parameters published by KGC, including the elliptic curve addition cyclic subgroup. ,group The level ,group generator KGC's system public key Hash function Hash function and hash function ; (2a2) MN receives the long-term private key pair Through equation Verify that the received private key is valid: If the equation is not true, MN will re-initiate the registration request; Otherwise, MN obtains a valid long-term private key. and public key parameters And based on the public key parameter Obtain its x-coordinate With y coordinate : ； ； in: They represent taking x and y coordinates; (2a3) MN is randomly selected Calculate the temporary public key And based on the temporary public key Obtain its x-coordinate With y coordinate : ； ； ； in: They represent taking x and y coordinates; (2a4) MN take The first 64 bits are used to generate the initial cookie value for the hometown. : ； in: Function representation of taking The first 64 bits; (2a5) MN take The first 64 bits are used to generate the initial cookie value for handover. : ； in: Function representation of taking The first 64 bits.

5. The method according to claim 1, characterized in that, In step (2b), the HoTI message sent by the mobile node MN to the CN via the home agent HA has its source address as the MN's home address and its destination address as the CN's IP address. The message parameters are as follows: ; In step (2c), the CoTI message sent by the mobile node MN to the CN has its source address as the care-of address of MN and its destination address as the IP address of the CN. The message parameters are as follows: .

6. The method according to claim 1, characterized in that, Step (3a) is implemented as follows: (3a1) CN recovers MN's public key parameters from the received HoTI and CoTI message parameters. and temporary public key : ； ； in: They represent x and y coordinates They represent x and y coordinates; (3a2) CN take The first 64 bits are used to generate the initial cookie value for the hometown. : ； (3a3)CN take The first 64 bits are used to generate the initial cookie value for handover. : 。 7. The method according to claim 1, characterized in that: The 64-bit ciphertext obtained in step (3c) , means as follows: ； The 64-bit ciphertext obtained in step (3d) , means as follows: ； in: The function indicates the use of a shared session key. plaintext Perform symmetric encryption. Function representation uses plaintext Perform symmetric encryption.

8. The method according to claim 1, characterized in that: In step (3e), the communication peer node CN sends a HoT message to MN via the home proxy HA. The source address is CN's IP address, the destination address is MN's home address, and the message parameters are... ； In step (3f), the CoT message sent by the communication peer node CN to MN has the source address being the IP address of CN, the destination address being the care-of address of MN, and the message parameters being... ; in: It is generated by CN during the return path reachability process. The index of the temporary random number used in the hometown. It is generated by CN. The index of the temporary random number used for handover.

9. The method according to claim 1, characterized in that, In step (4a), MN calculates the hash value based on the received message. and session key negotiation parameters Generate session key The formulas are as follows: ； ； ； in: and These are the identity identifiers for MN and CN, respectively.

10. The method according to claim 1, characterized in that: The key information recovered in step (4b) , means as follows: ； The key information recovered in step (4b) , means as follows: ； in: The function indicates the use of a key. For ciphertext Decryption is required. The function indicates the use of a key. For ciphertext Decryption is performed.

Images