WO2008034368A1

WO2008034368A1 - A method, system, mobile node and correspondent node for generating the binding management key

Info

Publication number: WO2008034368A1
Application number: PCT/CN2007/070453
Authority: WO
Inventors: Chunqiang Li
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2006-09-18
Filing date: 2007-08-10
Publication date: 2008-03-27
Also published as: CN101150849B; CN101150849A

Abstract

A method for generating the binding management key, comprises: mobile node (MN) and correspondent node calculate respective public key according to an used key switching algorithm and exchange the public key; MN calculates a binding management key using the public key from CN and owned private key based on the key switching algorithm, generates the binding authorization data using the binding management key, and sends the binding authorization data carried in the binding update BU message to CN; CN calculates a binding management key using the public key from MN and owned private key based on the key switching algorithm, and authenticates the binding authorization data in the received BU message using the owned calculating binding management key. A system, MN and CN are also provided. The security of the binding management key generating process can be enhanced.

Description

Method, system, mobile node and communication node for generating binding management key

The present invention relates to mobile network technologies, and in particular, to a method, system, mobile node and communication node for generating a binding management key in a mobile IPv6 network. Background of the invention

At present, with the rapid development of computer network technology and mobile communication computing, there is a demand for network mobility. Mobile IPV6 is a solution for mobility at the network layer.

There are three basic network entities in a mobile IPv6 network: a mobile node (MN, Mobile Node), a communication node (CN, Correspondent Node), and a home agent (HA, Home Agent). The mobile IPv6 specification requires that the mobile node moves from one link to another without interrupting the ongoing communication using the Home Address (HoA), the mobility of the node to the transport layer and other high-level protocols. It is transparent, and a mobile node can be uniquely identified by its home address. When the mobile node roams to the foreign network, it will generate a care-address (CoA, Care of Address) in a certain way, and notify the home agent through the binding update message, and the home agent intercepts the report sent to the mobile node's home network and the mobile node. Then, the packet is forwarded to the mobile node through the tunnel mode. When the mobile node sends a packet to the CN, the packet needs to be sent to the home agent through the tunnel mode. The home agent decapsulates the tunnel packet and forwards the packet to the CN. The MN referred to herein refers to the mobile node of IPv6.

The communication method in which the mobile node and the communication peer transit through the home agent is called a triangle routing mode, which obviously increases the communication delay, and there is a large header cost such as communication with the mobile node, and the mobile node is added to the hometown. Link burden, routing may not be optimized enough. Therefore, if the current location information (ie, the care-of address) of the mobile node is notified to the communication peer, the communication between the communication peer and the mobile node can be transferred without going through the home agent. The method in which such a communication peer directly communicates with the mobile node is called a route optimization mode. The route optimization mode of mobile IPv6 can avoid the above problems in the triangular routing mode. In order for the CN to send the message directly to the mobile node, the mobile node needs to advertise its current location information to the CN through a Binding Update (BU, Binding Update) message, which requires protection of the BU message, otherwise the mobile node and Communication between peers is vulnerable. For example: An attacker replaces Co A in a BU message with a forged Co A, and the mobile node cannot receive the message sent by the CN.

At present, the industry proposes a method of generating a binding management key (Kbm, binding management key) by using a Return Routability Procedure (RRP), and using the Kbm to protect the BU and binding between the UI and the CN. Confirm (BA, Binding Acknowledge) message. FIG. 1 is a schematic diagram of a process of using a return route reachability in the prior art. As shown in Figure 1, when the mobile node attempts to communicate with the CN using the route optimization mode, it sends a Home Test Init (HoTI, Home Test Init) and a Care Test Init (CoTI) message to the CN. Setting CN can support and allow communication with mobile nodes using route optimization mode.

When CN receives the ΗοΉ message, it calculates the home secret generation token according to the following method: Home secret, secret generation token = First ( 64, HMAC-SHA1 ( Ken, HoA I Nonce I

0 ) )

When the CN receives the CoTI message, it calculates the handover secret generation token as follows: Hand over the secret generation token = First ( 64, HMAC-SHA1 ( Ken, CoA I Nonce II ) ) where Ken is known only to CN. The key, Nonce is a random number generated by the CN, and HMAC-SHA1 is an algorithm for generating a Hash Message Authentication Code (HMAC) using the SHA1 with a key. The CN sends the generated home secret generation token to the mobile node in the HoT message, and places the generated handover secret generation token in the CoT message and sends it to the mobile node. After receiving the HoT and CoT messages sent by the CN, and checking the cookies, the mobile node retrieves the home secret generation token and the handover secret generation token, and can calculate Kbm = SHA1 (home secret generation token I transfer) Secret generation token). When the mobile node deregisters the binding relationship with the CN, Kbm = SHA1 (Home Secret Generation Token) is used to generate a message authentication code (MAC, Message Authentication Code) in the BU message.

The implementation of the method requires that the attacker cannot simultaneously spoof two CoT and HoT messages on the two links between the HA and the CN and between the MN and the CN. In fact, the attacker can eavesdrop on the CoT or HoT message by selecting the appropriate location. The following is an example of the network diagram of the mobile node in Figure 2 to illustrate the situation. In Figure 2, the two links between the HA and the MN and between the MN and the CN have a common link, and the C link, the eavesdropper can audate both CoT and HoT at any position on the C link. Message. In addition, CoT and HoT messages are easily available for node cooperation on two different links. After obtaining CoT and HoT, the attacker can calculate Kbm and naturally forge a BU message.

When a malicious node selects an appropriate location, such as on the link between the HA and the CN, the analog MN sends CoTI and HoTI messages to the CN through the RRP. Because of the lack of necessary identity authentication information, CN naturally cannot distinguish this. Whether the CoTI and HoTI messages are messages sent by the fake MN, it is also difficult to generate a suitable binding entry. In particular, when a BU is unbound, if a malicious node steals a HoT message, Kbm = SHAl (Home Secret Generation Token) can be used to generate the MAC in the BU message. When the CN receives the BU message, Kbm = SHAl (home secret generation token) is used to verify the BU message, and the corresponding binding entry is canceled after the verification is passed, which may cause overload of the home network.

In summary, the existing methods of generating Kbm through RRP are very limited. Summary of the invention

In view of this, the main object of the present invention is to provide a party that generates a binding management key. The method and system can provide a more secure binding management key generation mechanism and implement more effective protection of BU messages.

Another main object of the present invention is to provide a mobile node and a communication node, which are capable of generating a binding management key by exchanging keys to provide a more secure protection function for BU messages.

In order to achieve the above object, the technical solution of the present invention is achieved as follows:

The present invention discloses a method for generating a binding management key. When the MN initiates communication with the CN, the method includes:

The MN and the CN calculate their respective public keys according to the key exchange algorithm used and exchange the public keys with each other;

The MN uses the public key from the CN and its own private key, calculates the binding management key according to the key exchange algorithm, uses the binding management key to generate binding authorization data, and carries the binding authorization data in the binding update. Send to the CN in the BU message;

The CN uses the public key from the MN and its own private key, calculates the binding management key according to the key exchange algorithm, and uses the binding management key calculated by itself to perform the binding authorization data in the received BU message. verification.

The method further includes: setting a key exchange algorithm in the MN and the CN in advance.

The method further includes: MN and CN negotiate to obtain a currently used key exchange algorithm. In the foregoing solution, the MN and the CN negotiate to obtain a currently used key exchange algorithm, including:

The MN sends the information of the key exchange algorithm supported by itself to the CN, and the CN determines the currently used key exchange algorithm according to the information of the key exchange algorithm supported by the MN and the key exchange algorithm supported by the MN.

In the above solution, the MN sends the information of the key exchange algorithm supported by the MN to the CN, including: The MN carries the information of the key exchange algorithm supported by itself in the initial HOTI message or/and the handover test initial CoTI message sent to the home of the CN.

In the above solution, the MN and the CN calculate the respective public keys according to the key exchange algorithm used and exchange the public keys with each other, including:

CN refers to the public key cryptosystem of the key exchange algorithm that both the MN and the MN can support.

The CN's public key is sent to the MN; the MN generates its own private key based on the public key cryptosystem parameters from the CN, calculates its own public key, and sends the calculated public key to the CN.

In the above solution, the CN sends the public key and the public key cryptosystem parameter to the MN, including: the CN carries the public key in the home test HoT message sent to the MN, and carries the public key in the handover test CoT message sent to the MN. Key cryptosystem parameter; or, CN carries the public key cryptosystem parameter in the home test HoT message sent to the MN, and carries the public key in the handover test CoT message sent to the MN.

In the above solution, the CN sends the public key and the public key cryptosystem parameter to the MN, including: the CN carries the public key and the public key cryptosystem parameter in the home test HoT message sent to the MN; or, the CN is sent to The MN's handover test CoT message carries the public key and the public key cryptosystem parameters.

In the above solution, the system further includes: an entity for providing an authentication function; when the CN sends the public key calculated by itself to the MN, the CN further adds a digital signature to the message carrying the public key; After the message carrying the public key of the CN, accessing the entity for providing the authentication function, and performing identity authentication on the CN according to the digital signature in the message;

When the MN sends the self-calculated public key to the CN, the MN further adds a digital signature to the message carrying the public key; after receiving the message carrying the public key of the MN, the CN accesses the information for providing the authentication function. The entity authenticates the MN according to the digital signature in the message. The method further includes: the CN generates the binding authorization data by using the binding management key calculated by the CN, and carries the binding authorization data in the binding confirmation BA message to be sent to the MN; the MN uses the binding management calculated by itself. The key verifies the binding authorization data in the received BA message.

In the above solution, when the MN's care-of address CoA is unchanged and still communicates with the CN, and a new binding management key is needed, the MN and the CN's original binding management key are calculated to obtain a new binding management. Key, including:

Next_Kbm = PRF ( Kbm, Expression )

Next_Kbm is a new binding management key, Kbm is the original binding management key, and Expression is composed of any one or more of CN, home address Ho A , CoA, Nonce, Cookies, and pseudo. The random function PRF ( ) represents a function that pseudo-randomizes Expression under the action of Kbm.

In the above solution, when the MN still communicates with the CN, but the link of the MN is switched to change the CoA, the HoTI message and the HoT message need not be sent between the MN and the CN, and the CN's public key for key exchange is The bearer is carried in the CoT message and sent to the MN. As long as the public key and/or the private key are still in the lifetime, the CN and the MN no longer update the public key and/or private key used for the key exchange.

In the above solution, when a plurality of MNs initiate communication with the same CN, the CN uses the same private key as each MN uses the key exchange to generate the binding management key.

In the above solution, when the lifetime of the binding management key is about to expire but is still not leaked, and the CN and the MN calculate a new public key, the message authentication code MAC is used to protect the binding management key that is still valid. The message carrying the new public key.

The invention discloses a system for generating a binding management key, the system comprising: a MN and a CN; the CN pre-storing its own private key;

The CN sends its own public key and system parameters of the key exchange algorithm to the MN, and uses the public key from the MN and the private key pre-stored by itself, and calculates the binding tube according to the key exchange algorithm. The authentication key is used to verify the binding authorization data in the received BU message by using the binding management key calculated by itself;

The MN generates a private key and calculates its own public key according to the key exchange algorithm system parameters sent by the CN, and sends the calculated public key to the CN, using the public key from the CN and its own private key, pressing the key The switching algorithm calculates the binding management key, generates the binding authorization data by using the binding management key, and carries the binding authorization data in the BU message and sends it to the CN.

In the foregoing solution, the CN is further used to generate the binding authorization data by using the binding management key calculated by the self, and the binding authorization data is carried in the binding confirmation BA message and sent to the MN; The binding authorization data in the received BA message is verified by using the binding management key calculated by itself.

In the above solution, the system further includes: a home agent HA; the MN carries the information of the key exchange algorithm supported by the MN in the HoTI message and the CoTI message sent to the CN, and sends the HoTI message to the CN by using the HA The CN W HoTI message and the information of the key exchange algorithm carried in the CoTI message determine the currently used key exchange algorithm.

In the above solution, the system further includes: HA; the CN carries the public key calculated by the CN in the HoT message or the CoT message sent to the MN, and carries the public key cryptosystem parameter corresponding to the key exchange algorithm in the sending To the MN's HoT message or CoT message, and send the HoT message to the MN through the HA.

In the above solution, the system further includes: HA; the MN carries the information of the key exchange algorithm supported by itself in the HoTI message and the CoTI message sent to the CN; and uses the public key cryptosystem parameter from the CN to generate its own private Key, and the public key is calculated, and the calculated public key and the generated binding authorization data are carried in the BU message and sent to the CN; the CN is based on the received HoTI message and the key in the CoTI message. The information of the exchange algorithm determines the currently used key exchange algorithm; uses the HoT message according to the predetermined public key cryptosystem parameter corresponding to the key exchange algorithm and the public key calculated by the self-preserved private key And the CoT message carries the public key and the public key cryptosystem parameter respectively and sends them to the MN; using the public key in the BU message and its own private key, and calculating the binding management key according to the key exchange algorithm; The HA is used to forward HoTI messages and HoT messages between the MN and the CN.

In the above solution, the system further includes: an entity for providing an authentication function, configured to save the trusted data and provide an identity authentication function; the CN is further configured to carry the public key calculated by the self to the MN Adding a digital signature to the message of the public key; after receiving the message carrying the public key of the MN, accessing the entity for providing the authentication function, performing identity authentication on the MN according to the digital signature in the message; When the public key calculated by the user is sent to the CN, the digital signature is added to the message carrying the public key; after receiving the message carrying the public key of the CN, accessing the entity for providing the authentication function, according to the The digital signature in the message authenticates the CN.

The present invention also discloses a MN for transmitting a BU message to the CN when initiating communication with the CN; the MN includes:

a key exchange unit, configured to receive a public key from the CN, calculate a public key, and send the public key to the CN, use a public key from the CN and its own private key, calculate a binding management key according to a key exchange algorithm, and use the tied The management key generates the binding authorization data, and carries the binding authorization data in the BU message sent to the CN.

In the above solution, the MN further includes: a verification unit, configured to receive the BA message from the CN, and use the binding management key generated by the key exchange unit to verify the binding authorization data of the CN carried in the BA message.

The present invention further discloses a CN for receiving a BU message from a MN when the MN initiates communication with the CN; the CN includes:

a key exchange unit, configured to receive a public key and a BU message from the MN, calculate the public key, and send the public key to the MN, using a public key from the MN and its own private key, and calculating according to a key exchange algorithm Get the binding management key;

The verification unit is configured to receive the BU message from the MN, and use the binding management key generated by the key exchange unit to verify the binding authorization data of the MN carried in the BU message.

In the above solution, the key exchange unit is further configured to generate the binding authorization data by using the binding management key calculated by the self, and carry the binding authorization data in the BA message sent to the MN.

Therefore, the method, system, mobile node and communication node for generating a binding management key provided by the present invention can combine a key exchange and a return route reachability process to generate a binding management key, and use the generated binding. The management key is used to protect the binding update message of the mobile IPv6, and the attack initiated by the third party to calculate the Kbm by eavesdropping on the HoT and CoT messages can be avoided, and the security of the communication in the mobile IPv6 route optimization mode is improved. BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic diagram of a return route reachable process in the prior art.

FIG. 2 is a networking diagram of communication performed by a mobile node.

FIG. 3 is a schematic diagram of a process flow of a preferred embodiment of the method of the present invention.

FIG. 4 is a schematic diagram of a specific structure of a binding management key system according to the present invention. FIG. 5 is a schematic diagram of a specific structure of a mobile node device according to the present invention.

FIG. 6 is a schematic diagram of a specific structure of a communication node device according to the present invention. Mode for carrying out the invention

The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. The present invention provides a method for combining a key exchange and a return route reachability procedure (RRP) to generate a binding management key, and a method for how to update the binding management key subsequently.

The main processing of the present invention includes: When the MN and the CN communicate using the route optimization mode At the same time, the MN first initiates registration with the peer. At this time, the two negotiate the key exchange algorithm used, such as: an elliptic curve key exchange algorithm or a Diffie-Hdlman key exchange algorithm. After determining the key exchange algorithm used, the CN sends the public key cryptosystem parameter and the public key PKcn used for key exchange to the MN, and the MN generates its own private according to the public key cryptosystem parameters sent by the CN. The key is used to calculate the corresponding public key PKmn, and the binding management key (Kbm) is calculated by the key exchange algorithm using the received public key PKcn and its own private key, and the binding update message (BU) is generated by using the Kbm. Binding authorization data such as MAC. The MN sends a BU message carrying the binding authorization data and the public key PKmn to the CN, and then the CN calculates the binding management key using the public key PKmn and the self-preserved private key, and then uses the binding management key to verify the BU message. Further, the CN generates the binding authorization data by using the generated binding management key and carries it in the binding confirmation message (BA) message, and returns it to the MN, and the MN uses the binding management key generated by the MN to verify the BA. Message.

The MN may carry the information of the key exchange algorithm that can be supported by the MN when transmitting the HoTI and the CoTI message, and the CN determines the currently used key exchange algorithm according to the HoTI and the CoTI message; and the CN can calculate the obtained public key system by itself. The parameters and the public key PKcn are respectively carried in the HoT and CoT messages and sent to the MN.

FIG. 3 is a schematic diagram of a process flow of a preferred embodiment of the method of the present invention. As shown in Figure 3, the specific processing steps include:

Step 301: The MN sends a HoTI message to the CN through the HA, where the HoTI message carries information of a key exchange algorithm supported by the MN.

Step 302: The MN sends a CoTI message to the CN, where the CoTI message carries information of a key exchange algorithm supported by the MN.

Step 303: The CN determines the currently used key exchange algorithm according to the received information of the HoTI message and the key exchange algorithm in the CoTI message. Then, using the determined key exchange algorithm, using a preset private Key 1 and the public key cryptosystem corresponding to the key exchange algorithm The public key 1 is calculated by the system parameters.

Step 304: The CN sends a HoT message to the MN through the HA, where the HoT message carries the public key 1.

Step 305: The CN sends a CoT message to the MN, where the CoT message carries the public key cryptosystem parameter described in step 303.

Here, the CN sends the public key 1 and the public key cryptosystem parameters to the MN through the HoT message and the CoT message respectively. Therefore, the HoT message may also carry the public key cryptosystem parameter in step 304, and the CoT message is performed in step 305. Carry the public key 1. In addition, the public key 1 and public key cryptosystem parameters may also be included in the same message and sent to the MN, such as a HoT message or a CoT message.

Step 306: The MN extracts the public key 1 and the public key cryptosystem parameters from the received HoT message and the CoT message; uses the public key cryptosystem parameter to generate its own private key 2 and calculates the public key 2; uses the public key 1 And the private key 2 calculates the binding management key according to the key exchange algorithm; and then uses the calculated binding management key to generate the binding authorization data.

Step 307: The MN sends a BU message to the CN, where the BU message carries the binding authorization data and the public key 2 calculated by the MN.

Step 308: The CN extracts the public key 2 from the received BU message, calculates the Kbm by using the public key 2 and the pre-stored private key 1 according to the key exchange algorithm, and uses the Kbm to verify the binding carried in the BU message. Authorize the data to verify the MN. Here, if the Kbm generated by the CN is the same as the Kbm generated by the MN, the binding authorization data carried in the BU message can be verified, that is, the MN can pass the CN verification; otherwise, the MN cannot pass the CN verification.

After the CN completes the verification of the BU message of the MN, the method further includes: Step 309: The CN calculates the Kbm generated binding authorization data by using step 308. Step 310: The CN sends a BA message to the MN, where the BA message carries the binding authorization data generated by the CN step 309. Step 311: The MN uses the Kbm calculated by itself to verify the binding authorization data in the BA message to implement verification of the CN. Similarly, if the Kbm generated by the CN is the same as the Kbm generated by the MN, the CN can pass the verification by the MN; otherwise, the CN cannot pass the verification by the MN.

In the foregoing embodiment, the information of the key exchange algorithm, the public key 1, the public key 2, the public key cryptosystem parameter, the binding authorization data, and the like are carried in the existing HoTI, HoT, CoTI, CoT in the return route reachable process. In the BU, BA or BA message, but the present invention does not limit the specific message carrying the information, and the solution of the present invention can also carry other information to carry the information, and the object of the present invention can be achieved.

The invention can be implemented by various key exchange algorithms. The two most common algorithms are the elliptic curve key exchange algorithm and the Diffie-Hdlman key exchange algorithm. To further explain the implementation principle of the present invention in detail, the binding management key generation method of the present invention will be described in detail below in conjunction with an elliptic curve key exchange algorithm and a Diffie-Hdlman key exchange algorithm.

1. Mechanism based on elliptic curve key exchange algorithm

Setting: The equation of elliptic curve (EC, Elliptical Curve) is y ² = x ³ +ax+b, and the parameters of the public key cryptosystem of elliptic curve are (p, a, b, G, n ), the public key cryptosystem The parameters are pre-calculated and set in the CN. Where p is a positive integer, Fp is a finite field, a and b are positive integers on Fp, G is the base point on the elliptic curve E ( Fp ), and n is a prime number and is the order of the base point G.

After receiving the HoTI and CoTI messages sent by the MN, the CN calculates the pre-computed (p, a, b, G, n) and the calculated public key 1, R = rG (where r < n, is CN The securely stored private key 1) is divided into two parts and sent to the MN in a HoT message and a CoT message, respectively. After receiving the HoT and CoT messages, the MN checks the cookies in the message. After checking, the MN calculates the public key 2, R, = r according to the (p, a, b, G, n) extracted from the HoT message and the CoT message. G ( r, <n, is the private key 2 calculated by the MN based on the public key cryptosystem parameters from the CN), And use the public key 1 and private key 2 to calculate the binding management key, Ks = r'R = r'rG or K = PRF ( Ks , Expression ). Among them, Ks can be used, or K can be used as the binding management key (Kbm). Expression can be composed of CN, Ho A, Co A, Nonce, Cookies, etc., or it can be empty; PRF ( Ks , Expression ) A function that performs pseudo-random processing on Expression under the action of the key Ks, which can be used for message authentication and derivation of a key. It can be a function such as HMAC_MD5, HMAC-SHA1, HMAC-SHA256.

Then, the MN generates the binding authorization data by using the calculated Kbm, sends a BU message carrying the binding authorization data, carries the Nonce option in the BU message, and places the public key 2 (ie, R,) in the BU option to send to the BU. CN. After receiving the BU message, the CN checks the Nonce option. After checking, the CN uses the public key 2 and the private key 1 to calculate the binding management key. Ks = rR, = rr'G = r, rG, in the same way as the MN. The Kbm is calculated, and the binding authorization data carried in the BU message is verified by using Kbm. Further, the CN may also use Kbm to generate binding authorization data and carry it in the BA message and return it to the MN, and the MN uses the Kbm generated by itself to verify the binding authorization data in the BA message.

In order to prevent a denial of service (DOS) attack, the CN uses the same private key when performing route optimization with multiple MNs, that is, when multiple MNs initiate communication to the same CN, the CN and each When the MN interacts to generate a binding management key, the private key used is the same.

2. Mechanism based on Diffie-Hdlman key exchange algorithm

Setting: In the Diffie-Hdlman key exchange algorithm, the public key cryptosystem parameter to be selected is (p, g), where p is a prime number, g is a finite field F _p generator, and g < p.

After receiving the HoTI and CoTI messages sent by the MN, the CN calculates the pre-computed public key cryptosystem parameters (p, g) and the public key 1 and X = g calculated using the public key cryptographic parameters and the private key 1. ^x mod p (where X is the private key 1 saved by the CN) is divided into two parts and placed in the HoT and CoT messages and sent to the MN. The MN checks the message after receiving the HoT message and the CoT message. Cookies in , and after the check is passed, the public key 2, Y=g ^y mod p is calculated according to (p, g) and private key 2 (where y is calculated by the MN based on the public key system cryptographic parameters from the CN The private key 2), and then use the public key 1 and the private key 2 to calculate the binding management key (Kbm), Ks = X ^y mod p = g ^xy mod p or K = PRF ( Ks I Expression ). Where Ks and K both represent the binding management key, and the meanings of PRF and Expression are as described above.

Then, the MN generates the binding authorization data by using the calculated Kbm, sends a BU message carrying the binding authorization data, needs to carry the Nonce option in the BU message, and sends the public key 2 (ie, Y) in the option of the BU message. To CN. The CN checks the Nonce option after receiving the BU message, and calculates Kbm, Ks=Y ^x mod p = g ^yx mod p after the check is passed, and uses Kbm to verify the binding authorization data in the BU message. Further, the CN may also use Kbm to generate binding authorization data and carry it in the BA message and return it to the MN, and the MN uses the Kbm generated by the MN to verify the binding authorization data in the BA message.

Here, in order to prevent DOS attacks, multiple MNs can use the same private key when performing route optimization with the same CN.

After the above embodiment is applied, the attacker cannot extract the Kbm used by the MN and the CN even if the public key and the public key cryptosystem parameters in the HoT and CoT messages are intercepted, and the MN can not be sent to the CN to generate the binding authorization data. BU messages to implement the attack.

In addition, in the case that the public key cannot be securely obtained, that is, the authentication entity capable of providing the authentication function with the trusted data is not set in the network, the present invention may generate the binding management key by using an anonymous key exchange method. That is, the digital signature is not included in the message involving the key exchange. In this mechanism, the time stamp mechanism can be used to provide the protection function. For example, when a message carrying a key exchange carries a timestamp, when the MN does not receive the message carrying the public key within a certain time limit, the MN determines that the CN is attacked and discards the message from the CN.

In the case that the public key can be obtained securely, that is, the entity that provides the authentication function with the trusted data is set in the network, and the message related to the key exchange (such as: HoT message, CoT) Digital signatures are added to messages, etc. for identity authentication. At this time, when receiving the message related to the key exchange, the CN or the MN may use the data signature in the message to access the entity providing the authentication function to complete the identity verification.

When the MN's CoA is unchanged and still communicates with the original CN and needs to use the new Kbm to protect the BU message, it involves updating the binding management key. In order to avoid excessive cryptographic operations, a new binding management key can be calculated using a predetermined algorithm using a predetermined binding management key. For example: Use the following method to generate a new binding management key, which can be called Next_Kbm, and can be expressed as Next_Kbm = PRF ( Kbm, Expression ). Among them, Expression can be a combination of CN, Ho A, CoA, Nonce, Cookies, etc. PRF ( Ks, Expression ) represents a function of pseudo-random processing of Expression under the action of key Ks, which can be used for message authentication and The derivation of the key, which can be HMAC_MD5, HMAC-SHA1, HMAC-SHA256 and other functions.

When the MN still communicates with the original CN, but the link of the MN is switched to change the Co A, the RRP in this time does not have to interact with the ΗοΉ/ΗοΤ message, only the CoTI/CoT message is reserved, and the CN is used for the key. The exchanged public key will be placed in the CoT message and sent to the MN. As long as the key is still in the lifetime, the CN and MN may not have to update the public-private key pair used for the key exchange. In the case that the Ks lifetime generated by the key exchange is about to expire but still not leaked, the CN and the MN will generate a new public key using the message involving the key exchange, and may generate a message authentication code using Ks (MAC, Message Authentication). Code) to protect the integrity of the message involving the key exchange, so that in the case of the combination of the anonymous key exchange method and the RRP, as long as the first execution of the key exchange is not protected by the "man in the middle", then the subsequent Key exchanges are also not subject to "man in the middle" attacks.

Based on the above method of the present invention, the present invention also discloses a system for generating a binding management key. Figure 4 is a specific embodiment of the system. The system includes: MN and CN. When the MN and the CN negotiate a key exchange algorithm through a HoTI message, and/or through HoT When the public key is transmitted, the HoTI message and the HoT message need to be forwarded by the HA, and the system may further include: HA. In addition, when the MN and the CN exchange their respective public keys through HoT messages, BU messages, etc., the digital signature may be further added to the message carrying the public key for the message receiving end to authenticate the message sending end. In the system of the present invention, an entity for providing an authentication function needs to be further configured as shown in FIG. 4, and an end of the MN and the CN accesses an entity for providing an authentication function after receiving the message carrying the public key, according to the entity The digital signature carried in the message authenticates the other end of the MN and the CN.

Since the working principle of each entity in the system of the present invention is the same as that described in the previous method, the processing of each entity in the system will not be repeatedly described herein.

The invention also discloses a mobile node (MN) device. Figure 5 is a specific embodiment of the MN. The MN is configured to send a BU message to the CN when initiating communication with the CN; the MN includes: a key exchange unit, configured to receive a public key from the CN, calculate the public key, and send the message to the CN, using the public from the CN The key and the private key of the key are calculated by the key exchange algorithm, and the binding management key is generated by using the binding management key, and the binding authorization data is carried in the BU message sent to the CN. The MN may further include: a verification unit, configured to receive the BA message from the CN, and use the binding management key generated by the key exchange unit to verify the binding authorization data of the CN carried in the BA message. The detailed working principle of the MN is described in the previous method embodiments, and will not be repeated here.

Furthermore, the present invention discloses a communication node (CN). Figure 6 is a specific embodiment of the CN. The CN is configured to receive a BU message from the MN when the MN initiates communication with the CN; the CN includes: a key exchange unit, configured to receive a public key and a BU message from the MN, calculate the public key, and send the public key to the MN, Using the public key from the MN and the private key pre-stored by itself, the binding management key is calculated according to the key exchange algorithm; the verification unit is configured to receive the BU message from the MN, and use the binding management key generated by the key exchange unit. BU message The binding authorization data of the MN carried in the verification is performed. The key exchange unit is further configured to generate the binding authorization data by using the binding management key calculated by the self, and carry the binding authorization data in the BA message sent to the MN.

The invention combines the key exchange and the return route reachability process to generate a binding management key, and uses the generated binding management key to protect the binding update message of the mobile IPv6, thereby preventing the third party from eavesdropping on the HoT and CoT messages. The attack initiated by Kbm is calculated to improve the security of communication in the mobile IPv6 route optimization mode.

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

Claims

Claim

A method for generating a binding management key, characterized in that, when the mobile node MN initiates communication with the communication node CN, the method comprises:

2. The method according to claim 1, wherein before the MN and the CN calculate respective public keys, the method further comprises: setting a key exchange algorithm in the MN and the CN in advance.

The method according to claim 1, wherein before the MN and the CN calculate the respective public keys, the method further comprises: the MN and the CN negotiate to obtain a currently used key exchange algorithm.

The method according to claim 3, wherein the MN and the CN negotiate to obtain a currently used key exchange algorithm, including:

The method according to claim 4, wherein the MN sends the information of the key exchange algorithm supported by the MN to the CN, including:

The MN tests the initial HoTI message or/and the handover test initial CoTI in the hometown sent to CN. The message carries the information of the key exchange algorithm supported by itself.

The method according to claim 1, wherein the MN and the CN calculate the respective public keys according to the key exchange algorithm used and exchange the public keys with each other, including:

The CN calculates its own public key according to the key exchange algorithm used, and sends the public key cryptosystem parameters of the key exchange algorithm supported by itself and the MN and the public key of the CN to the MN;

The MN generates its own private key based on the public key cryptosystem parameters from the CN, calculates its own public key, and sends the calculated public key to the CN.

The method according to claim 6, wherein the CN sends the public key cryptosystem parameter and the public key of the CN to the MN, including:

The CN carries the public key in the home test of the MN, and carries the public key cryptosystem parameter in the handover test CoT message sent to the MN; or

The CN carries the public key cryptosystem parameter in the home test of the MN, and carries the public key in the handover test CoT message sent to the MN; or

The CN carries the public key along with the public key cryptosystem parameters in the Home Test HoT message or the Care Test CoT message addressed to the MN.

The method according to claim 6, wherein the CN calculates its own public key according to the key exchange algorithm used, and includes:

The CN calculates its own public key according to the public key cryptosystem parameters of the key exchange algorithm and the private key pre-stored by itself.

The method according to claim 6, wherein the MN sends the calculated public key to the CN, including:

The MN carries the calculated public key in the BU message and sends it to the CN.

The method according to any one of claims 6 to 9, wherein the system further comprises: an entity for providing an authentication function;

When the CN sends the public key calculated by itself to the MN, the CN further carries the public Adding a digital signature to the message of the key; after receiving the message carrying the public key of the CN, the MN accesses the entity for providing the authentication function, and performs identity authentication on the CN according to the digital signature in the message;

When the MN sends the self-calculated public key to the CN, the MN further adds a digital signature to the message carrying the public key; after receiving the message carrying the public key of the MN, the CN accesses the information for providing the authentication function. The entity authenticates the MN according to the digital signature in the message.

The method according to any one of claims 6 to 9, wherein one of the CN and the MN is further in the message carrying the public key when transmitting the public key calculated by itself to the other end. Add a timestamp, judge whether the other end returns the message within the preset duration according to the timestamp in the message, and if so, further process the message from the other end; otherwise, discard the message from the other end.

The method according to any one of claims 1 to 9, wherein after the CN verifies the binding authorization data, the method further includes:

The CN generates the binding authorization data by using the binding management key calculated by itself, and carries the binding authorization data in the binding confirmation BA message and sends it to the MN;

The MN uses the binding management key calculated by itself to verify the binding authorization data in the received BA message.

The method according to claim 1 or 9, wherein when the care-of address CoA of the MN is unchanged and still communicating with the CN, and a new binding management key is needed, the method further comprises: MN And the CN calculates a new binding management key Next_Kbm = PRF ( Kbm, Expression ) according to the original binding management key.

Next_Kbm is a new binding management key, Kbm is the original binding management key, and Expression is composed of any one or more of CN, home address Ho A , CoA, Nonce, Cookies, and pseudo. The random function PRF ( ) indicates that under the action of Kbm Expression performs pseudo-random processing of functions.

The method according to claim 13, wherein the PRF ( ) is: HMAC_MD5, HMAC_SHA1 or HMAC_SHA256.

The method according to any one of claims 1 to 9, characterized in that, when the MN still communicates with the CN, but the link of the MN is switched to change the CoA, the HoTI does not need to be sent between the MN and the CN. Message and HoT message, CN's public key for key exchange is carried in the CoT message and sent to the MN. As long as the public key and/or private key are still in the lifetime, CN and MN are no longer updated for key exchange. Public key and / or private key.

The method according to claim 1 or 9, wherein when the plurality of MNs initiate communication with the same CN, the private use of the binding management key is generated by the CN and each MN using a key exchange. The keys are the same.

The method according to any one of claims 6 to 9, characterized in that, when the lifetime of the binding management key is about to expire but is still not leaked, and the CN and the MN calculate a new public key, the use is still The binding management key of the validity period generates a message authentication code MAC to protect the message for carrying the new public key.

The method according to any one of claims 1 to 9, wherein the key exchange algorithm is an elliptic curve key exchange algorithm or a Diffie-Hellman key exchange algorithm.

A system for generating a binding management key, the system comprising: a MN and a CN; wherein the CN pre-stores its own private key;

The CN sends its own public key and system parameters of the key exchange algorithm to the MN, and uses the public key from the MN and the private key pre-stored by itself, and calculates the binding management key according to the key exchange algorithm, and uses the self-calculation. The binding management key verifies the binding authorization data in the received BU message;

The MN generates a private key and calculates its own public key according to the key exchange algorithm system parameters sent by the CN, and sends the calculated public key to the CN, using the public key from the CN and the self. The private key of the body is calculated by the key exchange algorithm to obtain the binding management key, and the binding authorization data is generated by using the binding management key, and the binding authorization data is carried in the BU message and sent to the CN.

20. The system of claim 19, wherein:

The CN is further configured to generate the binding authorization data by using the binding management key calculated by the self, and the binding authorization data is carried in the binding confirmation BA message and sent to the MN; the MN is further used to calculate by using the self. The obtained binding management key verifies the binding authorization data in the received BA message.

The system of claim 19, wherein the CN and the MN are further used to negotiate a currently used key exchange algorithm.

The system according to claim 21, wherein the system further comprises: a home agent HA;

The MN carries the information of the key exchange algorithm supported by the MN in the HoTI message and the CoTI message sent to the CN, and sends the HoTI message to the CN through the HA;

The CN determines the currently used key exchange algorithm according to the information of the key exchange algorithm carried in the HoTI message and the CoTI message.

The system according to claim 19, wherein the system further comprises two HAs;

The CN carries the public key calculated by the CN in the HoT message or the CoT message sent to the MN, and carries the public key cryptosystem parameter corresponding to the key exchange algorithm in the HoT message or the CoT message sent to the MN, and The HoT message is sent to the MN through the HA.

The system according to claim 21, wherein the system further comprises two HAs;

The MN carries the information of the key exchange algorithm supported by itself in the HoTI message and the CoTI message sent to the CN; uses the public key cryptosystem parameter from the CN to generate its own private key, calculates the public key, and calculates The obtained public key and the generated binding authorization data Carry in the BU message and send to the CN;

Determining, by the CN, the currently used key exchange algorithm according to the information of the received HoTI message and the key exchange algorithm in the CoTI message; according to a predetermined public key cryptosystem parameter corresponding to the key exchange algorithm, and itself The public key calculated by the pre-stored private key, using the HoT message and the CoT message to carry the public key and the public key cryptosystem parameter respectively and send it to the MN; using the public key in the BU message and its own private key, pressing The key exchange algorithm calculates the binding management key;

The HA is used to forward HoTI messages and HoT messages between the MN and the CN.

25. A system according to claim 23 or 24, wherein the system further comprises:

An entity for providing an authentication function for storing trusted data and providing identity authentication function. The CN is further configured to add a digital signature to a message carrying the public key when transmitting the public key calculated by the user to the MN; After receiving the message carrying the public key of the MN, accessing the entity for providing the authentication function, and performing identity authentication on the MN according to the digital signature in the message;

The MN is further configured to: when transmitting the public key calculated by the self to the CN, adding a digital signature to the message carrying the public key; after receiving the message carrying the public key of the CN, accessing the information for providing the authentication function The entity authenticates the CN based on the digital signature in the message.

26. A mobile node MN, the MN, configured to send a BU message to the CN when initiating communication with the CN; wherein the MN includes:

a key exchange unit, configured to receive a public key from the CN, calculate a public key, and send the public key to the CN, use a public key from the CN and its own private key, calculate a binding management key according to a key exchange algorithm, and use the tied The management key generates binding authorization data, and carries the binding authorization data. In the BU message sent to the CN.

27. The MN of claim 26, wherein the MN further comprises:

The verification unit is configured to receive the BA message from the CN, and use the binding management key generated by the key exchange unit to verify the binding authorization data of the CN carried in the BA message.

A communication node CN, the CN is configured to receive a BU message from the MN when the MN initiates communication with the CN, and the CN includes:

a key exchange unit, configured to receive a public key and a BU message from the MN, calculate the public key, and send the public key to the MN, and use the public key from the MN and the private key thereof to calculate the binding management key according to the key exchange algorithm;

29. The CN of claim 28, wherein

The key exchange unit is further configured to generate the binding authorization data by using the binding management key calculated by the self, and carry the binding authorization data in the BA message sent to the MN.