WO2008074226A1

WO2008074226A1 - A method for negotiating the session secret key between the endpoints across multiple gatekeeper zones

Info

Publication number: WO2008074226A1
Application number: PCT/CN2007/003690
Authority: WO
Inventors: Chen Lu; Yunfeng Wang; Jianyong Chen; Yanlong Hu; Zebao Zhang
Original assignee: Zte Corporation
Priority date: 2006-12-19
Filing date: 2007-12-19
Publication date: 2008-06-26
Also published as: CN101207480A

Abstract

A method for negotiating the session secret key between the endpoint across multiple gatekeeper zones aims to overcome the shortcoming of the low efficiency of negotiating the secret key across multiple gatekeeper zones in endpoint to endpoint calling mode, in which the calling endpoint and called endpoint are located in different gatekeeper management zones. According to the ability of the calling terminal, calling gatekeeper and the called gatekeeper for supporting D-H, the generation and the secret key exchange method which is supported between the gatekeeper and gatekeeper or between the terminal and the gatekeeper consistently, is negotiated dynamically, which increases the efficiency of the secret key exchange, reduces the delay and process load of the gatekeeper, and meanwhile, improves the flexibility of the interconnection and the interworking between the terminals with different secure abilities during the secure communication procedure.

Description

Cross-domain multi-network keeper end-to-end session key negotiation method

Technical field

The invention relates to the field of packet network communication security, in particular to a cross-domain multi-gatekeeper (GK) direct routing call mode, based on different security processing capabilities of the terminal and the gatekeeper, a dynamic negotiation public key system key exchange algorithm and a symmetric encryption key. The key exchange algorithm implements an end-to-end communication session key negotiation method. Background technique

In the field of packet-based network communication security, the key is the most important. The shared or session key obtained by key exchange between H.323 endpoints on the network can signal RAS (Registration, Access and Status). Call signaling, H.245 control signaling, etc. implement identity verification, signaling message integrity check, and security measures such as encryption/decryption of media data streams. At present, the shared or session key exchange method in the multi-gateway routing mode basically adopts pre-configuration and out-of-band methods such as telephone and E-Mail.

Direct Routing Call (DRC) mode is an important method for call setup in H.323 packet-based multimedia communication systems. Due to the DRC mode, it cannot be assumed that there is a pre-shared secret or session key between the two endpoints (the shared secret can be generated by a hash algorithm together with information such as the user ID, password, and random number), therefore, The methods used above are either difficult to deploy or unsafe to apply in practice.

The H.235 standard defines a communication security method based on the H.323 protocol set, including Diffie-Hellman (DH) public key cryptographic key exchange protocol. Random numbers generate shared secrets and are symmetric. The key generation and exchange method for password protection. However, it does not propose a negotiation and key exchange technology for the end-to-end key method of cross-domain multi-gatekeeper. It also does not consider how to fully utilize the processing capabilities of endpoints and gatekeepers, and how to have different key negotiation capabilities. Dynamically negotiate a cryptographic method that both parties support. Especially in the direct routing mode of H.323 multi-gatekeeper environment, existing terminal devices have multiple methods for establishing session keys, and it is impossible to pre-configure the two endpoints of communication, which brings difficulties to the security of interconnection communication. . Summary of the invention

The technical problem to be solved by the present invention is to provide an inter-domain multi-network omitting end-to-end session key negotiation method, which overcomes the current cross-domain multi-network omni-directional end-to-end call mode, and the key negotiation method is based on pre-configuration. The efficiency is not high, and the interconnection is poor.

In order to solve the above technical problem, the present invention provides a cross-domain multi-gateway end-to-end session key negotiation method, in which the primary and the called endpoints are in different gatekeeper management domains, including the following steps:

(1) Before using the direct route to call the called endpoint, the calling endpoint generates an access request message and sends it to the gatekeeper to which it belongs to perform security policy negotiation, and the gatekeeper is the calling gatekeeper;

(2) After receiving the access request message, the calling gatekeeper initiates a location request message to the called gatekeeper to query the called endpoint address and forward the key negotiation method of the calling endpoint;

(3) After receiving the location request message, the called gatekeeper determines a method for generating a session key according to whether the calling endpoint and the called gatekeeper support the DH key exchange algorithm and the security policy, and generates a method according to the method. The shared secret is placed in the location confirmation message for communication between the calling endpoint and the called endpoint, and the location confirmation message is sent to the calling gatekeeper for further key agreement; (4) the calling gatekeeper receives After the location confirmation message is obtained, the shared secret used for the calling endpoint is decrypted according to the determined method for generating the session key, and then the shared secret is directly encrypted or forwarded to the calling endpoint, and the connection is generated accordingly. The incoming confirmation message is sent to the calling endpoint, where the shared secret for the called endpoint is copied in the location confirmation message;

(5) After receiving the access confirmation message, the calling endpoint extracts the secret shared with the called endpoint according to the determined key negotiation method, completes the key negotiation, and obtains the session key.

In the foregoing method, the method for generating a session key may include:

(a) generating a shared secret by the called gatekeeper, the calling gatekeeper and the calling endpoint generating a session key according to the shared secret;

(b) The session key is generated by the calling gatekeeper and the called gatekeeper using a DH key exchange algorithm; or (c) the session key is generated by the calling endpoint and the called gatekeeper using a DH key exchange algorithm. Further, the access request message, the location request message, the location confirmation message, and the access acknowledgement message may all include a plaintext token, and the caller endpoint, the master is represented by different values of the algorithm object identifier in the plaintext token. Whether the gatekeeper or the called gatekeeper supports the DH key exchange algorithm, or It is used to indicate that the plaintext token contains a shared secret and is used by the calling endpoint or the called endpoint.

go a step further:

In the step (1), the calling endpoint may place its D-H public key in the D-H public key field in the plaintext token, and may set a value indicating that the algorithm object identifier supports the D-H key exchange algorithm. Based on:

In the step (2), if the calling endpoint and the called gatekeeper use the DH key exchange algorithm to generate the session key, the plaintext token of the access request message sent by the calling endpoint may be copied to the location request message. in. Based on:

In the step (3), the calling endpoint selects to use the DH key exchange algorithm, and the security policy of the called gatekeeper allows the DH key exchange algorithm to be used, and the DH public key generated by the called gatekeeper can be used and located. Together with the public key obtained in the request message, the DH key exchange algorithm is used to calculate the shared secret and the two plaintext tokens respectively used for the calling gatekeeper and the called endpoint, and placed in the location confirmation message. Based on:

In the step (4), the calling gatekeeper checks to receive the location confirmation message. If the calling endpoint and the called gatekeeper use the DH key exchange algorithm to generate the session key, all the plaintexts in the location confirmation message may be obtained. The token is copied into the access confirmation message. Based on:

In the step (5), the access confirmation message received by the calling endpoint can obtain the DH public key of the called party from the plaintext token of the access confirmation message, and is used together with the DH public key saved by the calling endpoint. The DH key exchange algorithm calculates the shared secret and obtains the session key.

Or even further:

In the step (3), if the called gatekeeper cannot use the DH key exchange algorithm, the called gatekeeper can generate a shared secret with the calling gatekeeper and the called endpoint respectively, and then encrypt the shared secret correspondingly. The post-encryption parameters are respectively placed in the plaintext tokens of the calling gatekeeper and the called endpoint for the location confirmation message. Based on:

In the step (4), after receiving the location confirmation message, the calling gatekeeper may decrypt the shared secret from the location confirmation message, and then encrypt the shared secret, and set the encryption result and the encryption parameter to the access confirmation message. In the plaintext token of the calling endpoint, the plaintext token used for the called endpoint in the location confirmation message is simultaneously copied into the access confirmation message. Based on: In the step (5), the access confirmation message received by the calling endpoint may be based on the encryption parameter of the plaintext token used by the calling endpoint in the access confirmation message, and the calling endpoint and the calling gatekeeper. The shared key decrypts the plaintext token in the access confirmation message to obtain a shared secret, thereby obtaining a session key.

The method of the invention improves the efficiency of the key exchange, reduces the processing load of the delay and the gatekeeper, and increases the flexibility of the terminal interconnection and intercommunication of different security capabilities in the process of implementing the secure communication. In addition, the safety technology adopted by the method of the present invention is compatible with existing standards, and the arrangement of the safety system is relatively simple. BRIEF abstract

Figure 1 shows a multi-gatekeeper direct route call mode scenario;

2 is a flow chart of steps of an embodiment of a method according to the present invention;

FIG. 3 is a negotiation flowchart of an application example of the method of the present invention. Preferred embodiment of the invention

The present invention will be described in detail below with reference to the accompanying drawings and specific embodiments.

In the embodiment of the present invention, the direct routing mode of the H.323 system cross-domain multi-gatekeeper management scope is adopted, and the host/called endpoints are respectively registered on different master/called gatekeepers, and the communication process is without security. The guaranteed IP network is used, and the used scenario is shown in Figure 1.

Figure 1 is a communication scenario diagram in a multi-gateway direct routing mode. The gatekeeper cloud in the figure includes one or more gatekeepers, and the endpoints can be connected to the same or different gatekeepers. In the direct route call model, the gatekeeper does not participate in H.225.0 call control signaling, and therefore does not perform signaling tunneling in H.225.0. Thus, the gatekeeper does not affect the tunnel between the two endpoints supporting the signaling tunnel. In the direct routed call model, the H.245 Control Channel can only be connected directly between endpoints. Real-time Data Streaming Protocol (RTP) is implemented based on the H.245 Control Channel.

In the communication scenario shown in Figure 1, first, on the RAS channel, the endpoint exchanges access messages with the gatekeeper, then exchanges call signaling on the call signaling channel, followed by the establishment of the H.245 control channel. The gatekeeper's response to the access message determines whether the direct routed call mode is used. Although the endpoint can To specify preferences, but mode selection is not controlled by the endpoint.

In the embodiment of the present invention, the gatekeeper performs authentication and integrity check on all RAS messages of the management endpoint, and the endpoint also performs authentication and integrity check on the RAS message of the gatekeeper, so that the endpoint and the affiliated gatekeeper achieve mutual trust. In order to be able to detect fraudulent entities and minimize the possibility of fraud. The gatekeeper and the gatekeeper in the intermediate network cloud also authenticate each other to avoid malicious attacks between the gatekeeper domains. Under the above conditions, the security of the RAS channel between H.323 endpoints can be guaranteed, and the security of call signaling can be realized based on this.

The present invention assumes that the calling endpoint EpA and the called endpoint EpB are in different GK administrative domains. During the key negotiation process, GK will securely generate or forward shared secrets between endpoints and endpoints, and complete security and integrity checks between hops and hops.

According to the different security capabilities of the endpoint and the gatekeeper, the present invention is divided into the following three types of key negotiation and exchange methods in the DRC security application scenario according to whether the D-H support capability and the priority security policy are supported:

Security Application Scenario 1: The calling endpoint does not support the DH key negotiation process. When the calling gatekeeper GkG and the called gatekeeper GkH do not support the DH process, the application scenario generated by the called gatekeeper to generate the session key corresponds to For method 1, the priority is low.

Security application scenario 2: The calling endpoint does not support the Diffie-Hellman process. The active/called GK supports and uses the D-H process to negotiate the session key. The corresponding scenario is Method 2, Priority.

Security Application Scenario 3: The calling endpoint supports the D-H process. The calling endpoint and the called GK use the D-H process to negotiate the session key. The corresponding method is Method 3, and the priority is high.

As shown in FIG. 2, the following describes the dynamic key negotiation procedure of the present invention based on the signaling flow of the H.323 network:

Step 210: Before using the DRC to call the called endpoint, the calling endpoint sends an ARQ message to the home gatekeeper, that is, the calling gatekeeper, which includes the method that is expected to be used for key negotiation, which may be performed by the calling endpoint. The ability to generate, based on the terminal security policy.

Step 220: After receiving the ARQ message, the calling gatekeeper determines, according to the target information of the called endpoint, that the called endpoint is an endpoint in the administrative domain that is not under its jurisdiction, and the gatekeeper of the called endpoint is called the gatekeeper. An LRQ message is initiated to query the called endpoint address. In the LRQ message, the calling network The keeper chooses an optimal key negotiation method (method 1, method 2 or method 3) for the calling endpoint according to its own security capabilities or security policies, and the method that the calling endpoint desires.

Step 230: After receiving the LRQ message, the called gatekeeper determines, according to the method desired by the calling endpoint indicated in the LRQ message, the method that the calling gatekeeper can satisfy, according to its own security capability or security policy. Which key negotiation method to use. The shared secrets generated by the selected method are placed in two separate ClearTokens (clear text tokens) in the LCF message returned to the calling gatekeeper, respectively, for the communication security behind the calling and called endpoints. The shared secrets in these two ClearTokens are protected by the existing security encryption mechanism (symmetric or asymmetric) between the gatekeeper-gatekeeper and the gatekeeper-endpoint to prevent leakage of the delivery process.

Step 240: After receiving the LCF message, the calling gatekeeper determines the negotiated key negotiation method (method 1, method 2 or method 3), and then generates an ACF message to be sent to the calling endpoint. In the ACF message, it is determined according to the method used whether to decrypt the shared secret and then encrypt the forwarding or directly forward the shared secret. At the same time, the ClearToken for the called endpoint in the LCF message is copied and placed in the ACF message.

Step 250: After receiving the ACF message, the calling endpoint extracts the secret shared by the called endpoint according to the method given by the dynamic negotiation.

Through the above ARQ message, LRQ message, LCF message and ACF message signaling flow sequence execution process, according to the calling terminal, the calling gatekeeper and the called gatekeeper have 8 states of DH capability, according to different security capabilities, priority Level and other security policies dynamically negotiate key generation and exchange methods that are consistently supported between the gatekeeper and the gatekeeper or terminal and gatekeeper.

Through the above steps, the communication parties (endpoints) can negotiate a trusted dynamic session key, which is cryptographically bundled with call authentication, including the session key refresh requirement in the call control channel.

The following describes the method of the present invention by referring to the symbols in Table 1 to indicate the capability of the endpoint and the gatekeeper or a combination thereof, or to distinguish the shared secret held by the calling/called endpoint.

Table 1, Endpoint and Gatekeeper Capability Representation Symbols Symbolic meaning

"10" indicates that the calling gatekeeper or called gatekeeper does not support the D-H key exchange algorithm.

"11" is used in the independent ClearToken of the calling endpoint, indicating that this ClearToken contains a shared secret.

"12" is used in the independent ClearToken of the called endpoint, indicating that this ClearToken contains a shared secret.

"14" indicates that the calling endpoint supports the D-H key exchange algorithm, and the called gatekeeper supports the D-H key exchange algorithm. Referring to Figure 3, this application example mainly includes the following stages:

(1) ARQ (Admission Request) stage:

The calling endpoint EpA sends an ARQ message to the home gatekeeper GkG before calling the called endpoint EpB using the direct routed call mode. The ARQ message includes an independent plaintext token ClearToken, which is assumed to be CTa, where tokenOID (algorithm object identifier) Depending on whether the DH key exchange algorithm is supported, different values are taken, which can be set by the user according to the capabilities and security policies of EpA. In this application example, EpA hopes to use DH key exchange algorithm to negotiate secret and secret with the called gatekeeper. Then put its DH public key in the dhkey (DH public key) field of ClearToken, and set a correlation to tokenOID. Identifies "14" and other fields are not used.

(2) LRQ (Location Request) stage:

After receiving the ARQ message sent by EpA, GkG determines that the called endpoint does not belong to the same administrative domain as the calling endpoint, and initiates an LRQ message to query GkH for the address of EpB. GkG generates the LRQ message using Method 3 according to its own security capability or security policy, and the tokenOID of the ClearToken in the ARQ message is "14". The LRQ message contains the ClearToken copied from the ARQ message.

(3) LCF (Location Confirm) stage ··

After receiving the LRQ message, the called gatekeeper GkH identifies the common key negotiation mode (method 1, 2 or 3) supported by EpA and EpB, and can determine the commonly supported key negotiation algorithm according to the tokenOID of the included ClearToken. Based on the defined priority order, different key agreement processes are performed to generate a call-based shared secret (based on the shared secret, which generates a session key when communicating later) Kab and two separate ClearTokens. These two separate ClearTokens, one for the calling gatekeeper GkG, assumed to be called CTg, and the other for the called endpoint EpB, assumed to be called CTb, this Kab will then be pushed to each by using CTg and CTb GkG and EpB. The specific practices for returning LCF messages for different methods are as follows:

The "14" in the LRQ message indicates that GkH also supports the D-H algorithm. In this application example, GkH's security policy allows the use of the D-H key exchange algorithm, and GkH begins to negotiate the session key with EpA (corresponding to Figure 3, labeled 2-3). The specific process is:

GkH generates the desired D-H public key, which is used together with the public key obtained from the LRQ message.

The D-H algorithm calculates the shared secret Kab, and then generates CTb, which can be set to "12". Finally, GkH generates an LCF message containing CTb and another independent ClearToken (the tokenOID can be set to "14") CTg, which has the desired D-H public key set.

(4) ACF (Admissions ConFirmation) phase:

The tokenOID of the ClearToken in the LCF message received by GkG is "14", then GkG generates an ACF message containing all ClearTokens copied from the LCF message (corresponding to Figure 3, labeled 2-3).

(5) Setu stage:

After receiving the ACF message, EpA checks that the tokenOID of the independent ClearToken in the message is "14", and determines that the calling endpoint and the called gatekeeper use the D-H dense copper. The exchange algorithm generates the session key, and uses the D-H algorithm to calculate the session key. The practice is:

The D-H public key of the called party is obtained from the ClearToken, and the shared secret Kab is calculated by using the D-H algorithm together with the D-H public key saved by itself, and the session key can be calculated.

In other cases, CTa is directly extracted, and the key EKag is derived according to the encryption parameter in CTa and its shared key Kag with GkG, and then EKag is used to decrypt the key.

CTa.h235Key.secureSharedSecret. The encryptedSessionKey gets the shared secret and the secret Kab, which can be used to calculate the session key. After calculating the session key, EpA creates a Setup message, copies the CTb in the ACF message to the Setup message, and then uses the session key to set the authentication information of Appendix B/Appendix F of H235V3 to complete the authentication during the call process of the user. EpA sends a call setup request message Setup directly to EpB.

(6) The following call signaling setup phase:

After receiving the Setup message, EpB extracts CTb and based on the information in CTb and EpB and GkH. The shared key Kbh exports the key EKbh, and then uses EKbh to decrypt CTb.h235Key.secureSharedSecret. encr ptedSession ey to get the shared secret and secret Kab; at this time, EpB can use Kab to authenticate the Setup and subsequent call signaling messages. .

In the above LCF stage, in another application example of the present invention, GkH does not support the DH algorithm or the security policy does not allow the use of the DH key exchange algorithm, and the GkH may use the called gatekeeper to generate the session key and generate the LCF message, still referring to the figure. 3, the process is as follows:

GkH randomly generates Kab. To encrypt Kab, first, GkH generates a random challenge and derives a key, such as EKgh, with a pre-configured shared key Kgh and challenge with GkG and a previously configured key derivation algorithm. Then, GkH encrypts Kab with EKgh to get a shared secret, such as EKAbl, and sets EKAbl and encryption parameters (encryption algorithm and encryption initialization vector) to the CTg.li235Key.secureSharedSecret field of the LCF message. Refer to H.235 Appendix I and set the tokenOID of CTg to "10". At the same time, GkH uses a similar process to generate another ClearToken, setting the tokenOID to "12", called CTb. Finally, GkH generates an LCF message (marked 4 in Figure 3) containing CTg and CTb.

Correspondingly, in the ACF stage in the other application example, after receiving the LCF message, the GkG checks that the tokenOID of the CTg in the message is "10" (corresponding to the case of the flag 4 in FIG. 3, the called gatekeeper does not support the return of the DH. First, GkG can derive the key Ekgh through the challenge, IV (initial vector) and the specified key derivation algorithm in CTg. Ekgh can also be derived by other security mechanisms. Then, GkG decrypts EKabl with EKgh. Kab; Finally, CTa is generated, and the tokenOID is set to "Ι.

The CTa is generated as follows: First, GkG derives the key EKag using the challenge between the shared secrets Kag and CTg between GkG and EpA and the specified key derivation algorithm. Then, GkG encrypts Kab with EKag to get EKabl, and sets EKabl and encryption parameters (encryption algorithm and initialization vector used for encryption) together into a separate CTa.h235Key.secureSharedSecret field. Finally, GkG generates an ACF message (corresponding to the case of Figure 5, Figure 5), which contains CTa and the CTb copied from the LCF message.

By dynamically adapting the security capabilities of the terminal and the gatekeeper, the method of the invention can improve the efficiency of key exchange, reduce the processing load of the delay and the gatekeeper, and increase the difference in the process of implementing the secure communication. Security capability Terminal connectivity flexibility.

In the method of the present invention, based on the ARQ/ACF and LRQ/LCF signaling execution flow in the H.323 standard protocol, the terminal and the gatekeeper have the security capabilities and the supported application scenarios, and dynamically negotiate a mutual support. And for the optimal key negotiation method (method 1, method 2 or method 3), the shared secret generation and exchange between the endpoints is completed, a security relationship is established for subsequent call signaling, and signaling and data messages are prevented from being forged. Loss of integrity and possible loss of confidentiality.

The safety techniques employed in the method of the present invention are compatible with existing standards, and the arrangement of the safety system is relatively straightforward, and there is no need to assume any additional safety infrastructure methods. With the deployment and application of large-scale H.323 multimedia communication systems, such as global VoIP networks or national-wide video conferencing/visual telephone systems, in this multi-operator, across multiple management domains In the multi-gate DRC environment, the method provided by the present invention is more convenient and practical.

Industrial applicability

With the deployment and application of large-scale H.323 multimedia communication systems, such as global VoIP networks or national-wide video conferencing/visual telephone systems, in this multi-operator, across multiple management domains In the multi-gatekeeper DRC environment, the method provided by the present invention is more convenient and practical. The method of the present invention can also be applied to other multi-gateway call modes, such as partial/routing mode, direct/routing, routing/direct mode, and gatekeeper routing.

Claims

Claim

A method for negotiating end-to-end session keys across multiple networks, where the primary and the called endpoints are in different gatekeeper management domains, and the method includes the following steps:

(3) After receiving the location request message, the called gatekeeper determines a method for generating a session key according to whether the calling endpoint and the called gatekeeper support the DH key exchange algorithm and the security policy, and generates a method according to the method. The shared secret is placed in the location confirmation message for communication between the calling endpoint and the called endpoint, and the location confirmation message is sent to the calling gatekeeper for further key agreement;

(4) After receiving the location confirmation message, the calling gatekeeper decrypts the shared secret for the calling endpoint according to the determined method of generating the session key, and then encrypts or forwards or directly forwards the shared secret. Sending an access confirmation message to the calling endpoint, and copying the shared secret for the called endpoint in the location confirmation message;

2. The method of claim 1 wherein:

The methods for generating a session key include:

(b) the session key is generated by the calling gatekeeper and the called gatekeeper using the D-H key exchange algorithm; or

(c) The session key is generated by the calling endpoint and the called gatekeeper using the D-H key exchange algorithm.

3. The method of claim 2, wherein:

The access request message, the location request message, the location confirmation message, and the access acknowledgement message all include a plaintext token, and the caller endpoint, the calling gatekeeper, and the different values of the algorithm object identifier in the plaintext token are used. Whether the called gatekeeper supports the DH key exchange algorithm, or is used to indicate the The text token contains the shared secret and is handed over to the calling endpoint or the called endpoint.

4. The method of claim 3, wherein:

In the step (1), the calling endpoint places its D-H public key in the D-H public key field in the plaintext token, and sets a value indicating that the algorithm object identifier supports the D-H key exchange algorithm. 5. The method of claim 4, wherein:

In the step (2), if the calling endpoint and the called gatekeeper use the DH key exchange algorithm to generate the session key, the plaintext token of the access request message sent by the calling endpoint is copied into the location request message. .

6. The method of claim 5, wherein:

In the step (3), the calling endpoint selects to use the DH key exchange algorithm, and the security policy of the called gatekeeper allows the DH key exchange algorithm to be used, and the DH public key generated by the called gatekeeper and the secondary positioning request Together with the public copper obtained in the message, the DH key exchange algorithm is used to calculate the shared secret and two plaintext tokens respectively used for the calling gatekeeper and the called endpoint, and placed in the location confirmation message.

7. The method of claim 3, wherein:

In the step (3), if the called gatekeeper cannot use the DH key exchange algorithm, the called gatekeeper generates a shared secret with the calling gatekeeper and the called endpoint respectively, and then encrypts the shared secret correspondingly. The encryption parameters are respectively placed in the plaintext tokens of the calling gatekeeper and the called endpoint for the location confirmation message.

8. The method of claim 6 wherein:

In the step (4), the calling gatekeeper checks to receive the location confirmation message. If the calling endpoint and the called gatekeeper use the DH key exchange algorithm to generate the session key, all the plaintext orders in the location confirmation message will be located. The card is copied to the access confirmation message.

9. The method of claim 7 wherein:

In the step (4), after receiving the location confirmation message, the calling gatekeeper decrypts the shared secret from the location confirmation message, and then encrypts the shared secret, and sets the encryption result and the encryption parameter to the access confirmation message. In the plaintext token of the calling endpoint, the location confirmation message is also used for the called party. The plaintext token of the endpoint is copied into the access confirmation message.

10. The method of claim 8 wherein:

In the step (5), the access confirmation message received by the calling endpoint obtains the DH public key of the called party from the plaintext token of the access confirmation message, and uses the DH together with the DH public key saved by the calling endpoint. The key exchange algorithm calculates the shared secret and obtains the session key.

11. The method of claim 9 wherein:

In the step (5), the access confirmation message received by the calling endpoint, according to the encryption parameter of the plaintext token used by the calling endpoint in the access confirmation message, and the sharing between the calling endpoint and the calling gatekeeper The key decrypts the plaintext token in the access confirmation message to obtain a shared secret, thereby obtaining a session key.