WO2007093079A1

WO2007093079A1 - Implementation method of crossdomain multi-gatekeeper packet network key negotiation security policy

Info

Publication number: WO2007093079A1
Application number: PCT/CN2006/000225
Authority: WO
Inventors: Chen Lu; Liang Zhang; Guangfeng Li; Yan Li; Changyin Sun; Weigang Liu
Original assignee: Zte Corporation
Priority date: 2006-02-16
Filing date: 2006-02-16
Publication date: 2007-08-23
Also published as: CN101273571B; CN101273571A

Abstract

A kind of implementation method of crossdomain multi-gatekeeper packet network key negotiation security policy, includes following steps: each terminal respectively determines its local security policy via signaling exchange with the gatekeeper it belongs to; according to the security policy of calling terminal and the key support ability of itself, calling gatekeeper determines the key negotiation protocol, and sends out key a negotiation request; called gatekeeper judges that whether it can execute the key negotiation request of the forwarded calling terminal according to the super priority protocol; the calling terminal determines whether continue to carrying out next signaling exchange according to the negotiatory security policy. The security policy implementation method of present invention can negotiate dynamically creditable session key, bind with the call authentication by use of cryptology, and realize the security policy of packet network. The security technology is compatible with exist standards. The dispose of security system is simple, and has no need of assuming of any additional security infrastructure method.

Description

Implementation method of cross-domain multi-gatekeeper packet network key agreement security policy

Technical field

The present invention relates to the technical field of security policy implementation based on packet network communication, and particularly relates to a different processing capability and security policy in a cross-domain multi-gatekeeper packet network environment.

A method for implementing a session key negotiation security policy in a secure communication process between ITU-T H.323 multimedia endpoints (representing terminals or gateways). Background technique

In a cross-domain multi-gatekeeper packet network environment, secure communication between ITU-T H.323 multimedia endpoints (EndPoints) cannot assume that there is a Share Secret Key between the two endpoints, because in this case It is unrealistic to require a pre-shared key (Share Secret Key) between all endpoints before communication.

Related security issues in the Direct Router Call (DRC) mode, such as the negotiation, generation, and release of encrypted session keys, are described in detail in ITU-T Rec. H.235, Appendix I. How to implement secure communication, especially session key negotiation, is still a problem to be solved in a multi-gateway environment in different management domains.

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 a multi-gateway environment, it is increasingly important to provide an effective and enforceable intelligent security policy to dynamically implement session key negotiation in order to meet various security requirements of users.

Keys are extremely important for implementing secure communication between ITU-T H.323 multimedia endpoints based on the H.235 standard. The shared key obtained by key exchange between H.323 endpoints on the packet network can perform identity verification, signaling message integrity check and media on RAS signaling, call signaling, H.245 control signaling, etc. Security measures such as encryption/decryption of data streams. Currently, there are multiple methods for key exchange for numerous security policies. One method uses an email, phone, or other non-H.323 protocol to transmit a session key. This type of key exchange method is more efficient and straightforward, but when using unencrypted communication methods to pass keys, it may lead to key leakage, and in a large-scale deployment environment, this method is due to the large number of endpoints. Feasible and unrealistic.

The commonly used method is to use symmetric key cryptography and public key cryptography, such as Diffie-Hellman or similar key negotiation method, for the generation and sharing of keys by two hosts.

H.225.0 is one of the core protocols of the H.323 system. It consists of three parts: call control, RAS and how to encapsulate audio and video signals with RTP. The call control signaling of H.225.0 is derived from Q.931. The function is to establish a call connection between the EP (EndPoint endpoint, including the terminal and the gateway) of H.323, including the process of call setup and teardown; RAS is the agreement between the endpoint and the gatekeeper, mainly completing registration, positioning, call admission, etc. Management function. It mainly contains the following protocol process:

Gatekeeper search: Used by endpoints to automatically search for their home gatekeeper. The message used is GRQ

(Gatekeeper Request Gatekeeper Discovery Request), GRJ (Gatekeeper Reject Gatekeeper Rejection), GCF (Gatekeeper Confirm Gatekeeper Confirmation). The endpoint uses the multicast address to send GRQ to find its own home gatekeeper, and the available home gatekeeper responds with GCF. After receiving the confirmation, the endpoint selects its own gatekeeper to obtain and record the gatekeeper's RAS address for subsequent RAS messages.

Endpoint registration: Information used by the endpoint to register/deregister itself with the home gatekeeper, including the alias address (E.164 address or H.323 identity) and the call signaling transport layer address. The endpoint must be registered to initiate and accept calls, and registration indicates that the endpoint has joined a management zone. The messages used for registration are R Q (egistration Request registration request), RCF (Registration Confirm registration confirmation), and RRJ (Registration Reject registration rejection). The endpoint uses the RRQ to register with the searched home gatekeeper. If the registration is successful, the gatekeeper responds with the RCF.

Call admission: Call access for the gatekeeper control endpoint, including user access authentication and address resolution. The messages used are ARQ (Admission Request Access Request), ACF (Admission). Confirm access confirmation), ARJ (Admission Reject access rejection). When the endpoint initiates a call, it first sends an ARQ message to the home gatekeeper, including the authentication information, the destination address, and the required bandwidth. The gatekeeper authenticates the user and parses the destination address. If the gatekeeper agrees to initiate the call, it sends back the ACF to the endpoint, including the allowed bandwidth and the translated call signaling transport layer address or the gatekeeper's call signaling transport layer address (depending on whether direct routing is used or not) Gatekeeper routing method). The H.225.0 Call Control Protocol uses this call signaling transport layer address to initiate a call. When the endpoint receives an incoming call request, it also sends an ARQ message to its gatekeeper for authentication. If the gatekeeper agrees that the endpoint receives the call, it will return the ACF to the endpoint to continue processing the incoming call procedure.

Positioning function: Refers to requesting the gatekeeper to provide address translation. The message used is LRQ

(Location Request address resolution request), LCF (Location Confirm address resolution confirmation), LRJ (Location Reject address resolution rejection). When an endpoint or gatekeeper knows the alias address of an endpoint and needs to know its call signaling transport layer address, it can send an LRQ message to the corresponding gatekeeper. The LRQ message can be sent in unicast or multicast mode. When the gatekeeper of the target endpoint receives the LRQ message, it returns the call signaling transport layer address of the endpoint or the call signaling transport layer address of the gatekeeper to the requester through the LCF. Which address is sent back depends on whether the call signalling is directly routed or gatekeeper.

In fact, H.235 does not propose a key exchange technique that defines only one H.323-based protocol set for key exchange. It allows developers to choose a key exchange method in the product, but there is no security policy that explains how different security policies are negotiated.

For small-scale systems, various signaling security protocols can be protected by pre-configuring security policies and methods. However, for larger H.323 systems, users need to communicate with different users. Pre-configured policies are unrealistic. .

In large-scale systems, different operators and different manufacturers' H.323 endpoint products use different key exchange methods due to different capabilities, especially in different routing call modes of H.323 multi-gatekeeper environment. The session key method, it is also impossible to pre-configure between the two endpoints of the communication, which brings difficulties to the specific implementation. Summary of the invention

The technical problem to be solved by the present invention is to propose a method for implementing a key agreement negotiation security policy for a cross-domain multi-gatekeeper packet network. The method of the invention extends the single-gatekeeper direct routing restriction in Appendix I of the H.235 protocol, and proposes a key agreement scheme in which the endpoints are placed in different management domains, different gatekeeper environments, and different routing modes, providing call establishment and The subsequent signaling messages are secure, including authentication, integrity checking, and the confidentiality of possible media streaming protocols.

To solve the above technical problem, the present invention provides a cross-domain multi-gatekeeper packet network key negotiation security policy implementation method, which includes the following steps:

(1) Each endpoint performs security policy negotiation through signaling interaction with its home gatekeeper, and determines the local security policy of each endpoint according to the key support capabilities of each endpoint and its home gatekeeper;

(2) The calling endpoint sends a key negotiation request to the calling gatekeeper according to the determined local security policy, and the calling gatekeeper determines the highest and lowest priority keys according to the security policy of the calling endpoint and its own key support capability. Negotiating procedures, and forwarding the key agreement request of the calling endpoint to the called gatekeeper according to the highest priority procedure;

(3) The called gatekeeper determines, according to its own key support capability, whether the key negotiation request of the forwarded calling endpoint can be performed according to the highest priority procedure, and if so, according to the highest priority procedure Key negotiation is performed. If not, key negotiation is performed according to the determined lowest priority procedure, and the negotiation result is forwarded to the calling endpoint by the calling gatekeeper.

The method of the invention may further comprise the steps of:

(4) After receiving the negotiation result, the calling endpoint determines whether to continue to use the negotiation result for subsequent signaling interaction based on the local security policy.

The signaling interaction process in the step (1) may be a gatekeeper discovery process or/and a registration process. The key support capability may be whether to support public key key negotiation.

The step (1) may include - (1-1) By the gatekeeper discovery request or/and the registration request message, the endpoint reports to its home gatekeeper whether it supports public key key negotiation;

(1 -2) The gatekeeper returns a determined endpoint local security policy to the endpoint based on whether the endpoint supports the public key key negotiation, through the gatekeeper discovery acknowledgement and/or the registration acknowledgement message, where: the endpoint and the gatekeeper either When public key key negotiation is not supported, determine the local security policy of the endpoint as: It is hoped that the gatekeeper will generate the shared key on its behalf;

When both the endpoint and the gatekeeper support public key key negotiation, the endpoint local security policy is determined as: the shared key is generated by signaling negotiation with the called gatekeeper.

The key negotiation request sent by the calling endpoint to the calling gatekeeper in step (2) may be an access request message, where the message includes local security policy information of the calling endpoint.

When the calling endpoint local security policy is configured to generate a sharing key by signaling negotiation with the called gatekeeper, the access request message may further include public key information.

Step (2) The step of determining the priority of the key agreement procedure by the calling gatekeeper according to the security policy of the calling endpoint and the key support capability of the calling endpoint, which may include:

When the calling endpoint local security policy is to generate a shared key by the gatekeeper, and the calling gatekeeper does not support public key key negotiation, the highest and lowest priority procedures for determining the key agreement procedure are: The gatekeeper generates a session key;

When the calling endpoint local security policy is to generate a shared key by the gatekeeper, and the calling gatekeeper supports the public key key negotiation, the highest priority procedure for determining the key agreement procedure is: the calling gatekeeper and the The gatekeeper uses the public key key negotiation process to generate a session key; the lowest priority procedure is: generating a session key by the called gatekeeper;

When the calling endpoint local security policy generates a shared key by signaling negotiation with the called gatekeeper, the final priority procedure for determining the key agreement procedure is: the calling endpoint and the called gatekeeper use the public key. The key negotiation process generates a session key; the lowest priority procedure is: The session key is generated by the called gatekeeper.

The access request message may further include called endpoint information, and the calling gatekeeper determines, according to the called endpoint information, whether the called endpoint belongs to a different administrative domain than the calling endpoint. In the step (2), the step that the calling gatekeeper can forward the key negotiation request of the calling endpoint to the called gatekeeper according to the highest priority procedure is sent by using an address resolution request, and the address resolution request includes The determined highest priority procedure information.

In the step (3), the step of the called gatekeeper determining whether the key negotiation request of the forwarded calling endpoint is performed according to the highest priority procedure may include:

When the highest priority procedure is to generate a session key by the called gatekeeper, it is determined that key negotiation can be performed according to the highest priority procedure;

When the highest priority procedure generates a session key for the calling gatekeeper and the called gatekeeper using the public key key negotiation process, if the called gatekeeper supports the public key key negotiation, it is determined that the highest priority can be performed. Procedure to perform key agreement; if the called gatekeeper does not support public key key negotiation, it is determined that key negotiation cannot be performed according to the highest priority procedure;

When the highest priority procedure generates a session key for the calling party and the called gatekeeper using the public key key negotiation process, if the called gatekeeper supports the public key key negotiation, it is determined that the highest priority can be followed. Procedure to perform key agreement; if the called gatekeeper does not support public key key negotiation, it is determined that key negotiation cannot be performed according to the highest priority procedure.

By using the security policy implementation method of the present invention, a trusted session key can be dynamically negotiated, and cryptography is used to bundle it with call authentication to implement a security policy of the packet network. The security technology adopted by the method of the present invention is compatible with existing standards. The layout of the security system is also relatively simple and does not require any additional security infrastructure methods to be assumed. BRIEF abstract

1 is a scenario diagram of a multi-gateway routing mode for implementing a key agreement security policy for a cross-domain multi-gatekeeper packet network according to an embodiment of the present invention;

FIG. 2 is a schematic diagram of a security policy implementation process in a multi-gateway routing call mode according to an implementation method of a cross-domain multi-gatekeeper packet network key agreement security policy according to an embodiment of the present invention. BEST MODE FOR CARRYING OUT THE INVENTION The core idea of the present invention is that a gatekeeper (GK, GateKeeper) in different management domains flexibly configures a corresponding security policy management policy to dynamically select a key distribution mode according to the endpoint capability of the jurisdiction, thereby completing the endpoint between different domains. Key management tasks. In principle, since the H.323 packet network in the multi-administration domain multi-gateway environment is more open than the closed H.323 environment, the key management needs to ensure a certain security.

The present invention mainly describes the GK between different domains in different routing modes of endpoints placed in different gatekeeper environments in different management domains, and performs signaling processes such as GRQ/RQ, ARQ/ACF/ARJ, LRQ/LCF/LRJ, etc. Secure key agreement between endpoints in two different gatekeeper environments to establish a secure channel for subsequent call signaling to prevent forgery, loss of integrity, and possible loss of confidentiality. In particular, if the endpoint supports key exchange based on a public key, such as Diffie-Hellman or (similar to the Diffie-Hellman elliptic curve method), the target domain GK will authenticate the source endpoint and use the security policy pair source or source that is shared or negotiated with the source GK. GK is certified. After the authentication is passed, the target GK will return the Diffie-Hellman public key with the authentication value and the source gatekeeper identifier G ID.

The present invention assumes that GK is a security module that implements key storage, cryptographic algorithms and mechanisms for negotiation, security management and maintenance access, and reliability. These security policies can be implemented in software, in hardware, or both. In this secure mode, GK acts as a trusted intermediate entity, terminating the security association between hops. During the key negotiation process, the GK will generate or forward a shared key containing an endpoint-end based on the security policy, and at the same time complete the relevant authentication and integrity check, which can be performed by using the CryptoToken included in each signaling. The security-related data structure recalculates the authentication code implementation. The shared key here is a security key and is part of the cryptographic algorithm security parameters. It can be exported by password, or configured to be assigned or other methods.

As shown in FIG. 1 , a scenario diagram of a multi-gateway routing mode for implementing a cross-domain multi-gatekeeper packet network key agreement security policy according to an embodiment of the present invention includes: a calling endpoint 101 (EpA), a calling network守 102 (GkG), intermediate gatekeeper 103, called gatekeeper 104 (GkH), called endpoint 105 (EpB). Supporting key agreement methods for the calling endpoint 101, the calling gatekeeper 102, and the called gatekeeper 104, such as transmitting a session key based on symmetric cryptographic encryption, Diffie-Hellman (referred to as DH) public key cryptography, implementing session key negotiation, etc. The embodiment of the invention describes a flexible selection of a session key distribution mode based on a priority security policy. The specific security policy is as follows:

The calling endpoint 101 can support the symmetric negotiation of the symmetric password according to the security strength requirement and the registered gatekeeper, and can also support the public key cryptography to implement the key negotiation method.

The calling gatekeeper 102 uses the public key crypto method of the calling endpoint 101 as a high priority policy according to the local security policy for the security request of the calling endpoint 101, and satisfies the security request of the calling endpoint 101 as much as possible. If not, re-negotiate the new symmetric cryptographic method with the calling endpoint 101.

The called gatekeeper 104 satisfies the security request based on the public key cryptography method of the calling endpoint 101 or the calling gatekeeper 102 according to the endpoint security request forwarded by the calling gatekeeper 102. If not, the calling gatekeeper 102 A new symmetric cryptographic method is negotiated and forwarded to the calling endpoint 101 by the calling gatekeeper 102.

The calling endpoint 101 determines, according to the received security policy negotiation result, whether to continue the subsequent signaling interaction with the newly negotiated security policy based on the local security policy.

The embodiment of the present invention proposes a shared key negotiation between two endpoints by means of their respective gatekeepers, and provides security for call signaling and subsequent H.245 control signaling.

As shown in FIG. 2, a security policy implementation process diagram of a multi-gateway routing call mode according to the method for implementing a cross-domain multi-gatekeeper packet network key agreement security policy according to an embodiment of the present invention is as follows:

(Step 201) The calling endpoint and the called endpoint that are in different domain gatekeeper management send GRQ/RRQ (gatekeeper discovery and gatekeeper registration request) signaling to their respective gatekeepers.

(Step 202) The calling party and the called gatekeeper send GCF/RCF (gatekeeper discovery request response and gatekeeper registration request response) or GRJ/RRJ (gatekeeper response rejection/registration response rejection) to the calling and called endpoints. Signaling, complete the call mode supported by the gatekeeper and whether the endpoint has the public key crypto method to implement the key negotiation capability. (Step 203) Before calling the called endpoint, the calling endpoint sends an ARQ message to its home gatekeeper GkG, which may include an independent ClearToken, where the tokenOID field is set to support the key negotiation capability object identifier (in Text is given numerically), other fields are not used.

(Step 204) After receiving the ARQ, the gatekeeper GkG of the calling endpoint determines whether the called endpoint (represented by destinationInfo or destCallSignalAddress in the ARQ message) is its own management domain, and if it does not belong to the endpoint of its own jurisdiction, then to the called endpoint The gatekeeper initiates an LRQ message to query the called endpoint address. The calling gatekeeper GkG security policy rule is that if the calling endpoint supports a public key method such as Diffie-Hellman key agreement, the LRQ message actually forwards the key agreement request of the calling endpoint. This can be done by including a ClearToken in the generated LRQ message, where tokenOID is set to indicate the required key negotiation capability object identifier to the called gatekeeper, while other fields are not used. If the calling and called endpoints are at the same gatekeeper, the key negotiation method is the same as given in H.235 Appendix I. The security policy here is based on the GRQ/RRQ, GCF/RCF (or GRJ/RRJ) signaling interaction, and the gatekeeper imposes restrictions on whether or not to support the endpoint's public key method for key negotiation. If the endpoint is allowed to support the public key method, the endpoint can perform key negotiation by the public key method in the subsequent signaling. Otherwise, the session key negotiation can only be performed by the symmetric cipher method.

(Step 205) Two different policy rules are adopted depending on whether the called gatekeeper GkH supports the public key method for the calling endpoint.

(Step 206) The GkH generation shares the semi-public key with the EpA, and together with the semi-public key generated by the EpA, generates a session key (or shared key) shared by the calling and called endpoints.

(Step 207) The shared key is respectively placed in two separate ClearTokens in the LCF message returned to the calling gatekeeper GkG, respectively for the communication security behind the calling and called endpoints. The shared keys in the two ClearTokens are protected by a security encryption mechanism between the gatekeeper-gatekeeper and the gatekeeper-end, respectively, to prevent leakage of the delivery process.

(Step 208) The calling gatekeeper GkG forwards the secure session key negotiated by the GkH and the calling endpoint through the public key method, and returns to the calling endpoint EpA through the ACF message. Thereby completing the basis The endpoint public key method implements the process of session key negotiation.

(Step 209) When GkH does not support the public key method of the endpoint to generate the shared session key of the calling and called endpoints, a session key is separately generated by GkH, and the session key may be generated by using a random number generation method.

(Step 210) Since the called gatekeeper GkH does not satisfy the key agreement request method forwarded by the calling gatekeeper, in order to complete the key negotiation as much as possible, the GkH and the calling gatekeeper protect the master and the called party by using a symmetric password. The shared key generated by the endpoint. It is returned to the calling gateway GkG as an LRJ message. After receiving the LRJ message, the calling endpoint gatekeeper checks the tokenOID flag of the ClearToken in the message, and the GkG between the two gatekeepers decrypts the shared key used in the calling endpoint ClearToken according to the previously negotiated security policy, and then uses and The security policy pre-configured by the calling endpoint regenerates a token for the calling user with the encrypted shared key, and copies the ClearToken for the called endpoint in the LRJ message, and puts it into the ARJ returned to the calling endpoint. Send in the message.

(Step 211) The calling gatekeeper recovers the shared key according to the LRJ message, and encrypts the shared key or session key in the ARJ message through a security policy shared with the calling endpoint EpA. After receiving the ACF (or ARJ) message, the calling endpoint extracts the secret shared with the called endpoint for subsequent call signaling security protection, such as the authentication of ITU-T H.235V3 Appendix D.

(Step 212) The calling endpoint EpA is based on the symmetric cipher method. In the ARQ message, the gatekeeper is requested to share the key with the called endpoint EpB.

(Step 213) GkG negotiates with the called gatekeeper GkH based on whether the public key method itself supports, and negotiates the session key for the called terminal.

(Step 214) GkG sends a symmetric key method to GkH to generate a session key (shared key) shared between the calling and called endpoints by using the LRQ message.

(Step 215) Generate a GkG-GkH session key semi-public key.

(Step 216) The GkG issues a public key method to the GkH in the LRQ message to generate a session key (shared key) shared between the calling and called endpoints. (Step 217) GkH decides which key to generate based on whether or not it supports the public key method. (Step 218) The public key method is used between the called gatekeeper support and the calling gatekeeper to generate a GkH-GkG session key semi-public key.

(Step 219) GkH sends the GkH-GkG session key semi-public key generated by the public key method to GkG in the LCF message.

(Step 220) GkG will negotiate the session key with the called gatekeeper by public key method, send the session key to EpA with ACF message, and adopt the letter in GRQ/GCF/GRJ (or RRQ/RCF/RRJ). The security policy negotiated during the interaction phase is enforced.

(Step 221) The called gatekeeper does not support the public key method with the calling gatekeeper, and GkH generates the session key.

(Step 222) GkH sends a session key generated by the symmetric cryptographic method to GkG in the LRJ message.

(Step 223) GkG sends the session key generated by the symmetric cryptographic method to EpA in the ACF message.

(Step 224) When GkH does not support sharing the session key with the endpoint's public key method to generate the primary and called endpoints, a session key is generated separately by GkH.

(Step 225), the GkH and the calling gatekeeper protect the shared key generated by the master and the called endpoint in a symmetric cipher manner. It is returned to the calling gatekeeper GkG as an LRJ message.

(Step 226) The calling gatekeeper recovers the shared key according to the LRJ message, and encrypts the shared key or session key in the ACF/ARJ message through a security policy shared with the calling endpoint EpA.

(Step 227) After receiving the ACF/ARJ message, the calling endpoint extracts the secret shared with the called endpoint and sends a call setup request message Setup to the EpB.

(Step 228) The EpB sends a Call Proceeding message to the EpA, and performs a step 229 in response to the call setup request message.

(Step 229) EpB sends an ARQ message to GkH.

(Step 230) GkH responds to the ACF message to EpB. (Step 231) EpB sends an Alerting message to EpA.

(Step 232) EpB sends a connect message to EpA to establish a call connection.

Steps 203 to 211 illustrate a security policy for the calling party and the called party to complete the session key negotiation for the calling party and the called party when the calling party supports the public key method.

In step 206 to step 208, the public key method is used between the called gatekeeper GkH and the calling endpoint EpA for session key negotiation.

Step 209 to step 211, indicating that the called gatekeeper GkH does not support the security policy and steps taken to dynamically complete the key negotiation when using the public key method for session key negotiation with the calling endpoint EpA.

In step 212 to step 226, it is explained that when the master, the gatekeeper supports or does not support the public key method, how to perform the session key negotiation based on the symmetric cryptographic method and the called endpoint.

In steps 215-217, GkG and GkH negotiate the session key in a public key method.

Steps 218-220 illustrate the signaling flow when the called gatekeeper supports the public key method between the calling gatekeeper and the calling gatekeeper.

Step 221-223 illustrates the signaling flow that the called gatekeeper does not support the use of the symmetric cryptographic method to generate and transmit the session key when the calling gatekeeper adopts the public key method.

In steps 224-226, the process of generating a session key by GkH is illustrated.

The embodiments of the present invention are applicable to direct routing and optional routing modes of the H.323 system across the network management scope. Assume that the master/called endpoints are registered on different master/called gatekeepers, and the communication process is performed on an IP network without security guarantee.

The premise of implementing the embodiment of the present invention is: the gatekeeper performs authentication and integrity check on all RAS messages of the management endpoint, and the endpoint pair also performs authentication and integrity check on the RAS message of the gatekeeper, so that the endpoint and the associated gatekeeper To achieve mutual trust, so that fraudulent entities can be identified and the likelihood of fraud is minimized.

The intermediate entity gatekeeper and the gatekeeper 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 embodiment of the present invention uses the following symbols to indicate the capability of the endpoint and the gatekeeper or a combination of the two, and distinguishes the shared key held by the calling/called endpoint, and the meaning of the symbol representation:

"10" indicates that the calling endpoint does not support D-H, and the calling gatekeeper or called gatekeeper does not support the D-H key negotiation process.

'Ί Used in a separate ClearToken returning to the calling endpoint, indicating that this ClearToken contains a session key.

"12" is used in the called Clear Gate to the called endpoint independent ClearToken, indicating that this ClearToken contains the session key.

"13" indicates that the calling endpoint does not support the G-H process, but the calling and called gatekeepers support the D-H process.

"14" indicates that the calling endpoint supports the D-H process, and the called gatekeeper supports the D-H process.

Embodiments of the present invention support and not support Diffie-Hdlman in endpoints and gatekeepers respectively.

In the case of the D-H) public key method, it is explained how the present invention flexibly selects the session key allocation mode in the direct routing mode.

Although the present invention uses the direct routing mode of the H.323 system across the network management scope as an embodiment, the method of the present invention is applicable to various routing methods.

Assume that the master/called endpoints are registered on different master/called gatekeepers respectively, and the communication process is performed on an IP network without security guarantee. This embodiment gives a description of the session key generation process in the direct routed call mode (DRC) with several practical scenarios based on the security policy described above.

DRC I: The calling endpoint and the calling party GK do not support the D-H process, only the called GK is required to generate the session key.

DRC II: The calling endpoint does not support the D-H process, and the master/called GK uses the D-H process to negotiate the session key.

DRC III: The calling endpoint supports the D-H process, where the calling endpoint and the called GK negotiate the session key using the D-H procedure.

The following three processes are described based on the logical sequence of RAS signaling and call signaling. The implementation of the body protocol.

1. GRQ/GCF or RRQ/RCF signaling phase: In the GK discovery process (GRQ/GCF) or / and registration process (RRQ/RCF), the endpoint indicates to the home GK whether it supports the public key (D-H) process. The method is to include a separate ClearToken in GRQ (or RRQ), where tokenOID is set to "10", indicating that the DH process is not supported, and setting to "14" indicates support. After receiving the GRQ (or RRQ), the GK recognizes the tokenOID in the ClearToken, determines whether to support the endpoint according to the management policy, and replies to the corresponding GCF (or RCF). In the included ClearToken, the tokenOID is set as follows: If the GK is not Support the endpoint DH key negotiation process, set to "10" regardless of how the endpoint is set, which indicates that the security policy is generated by the gatekeeper to generate the shared key; if the GK supports the DH process of the endpoint, and the gatekeeper The management policy also supports this endpoint, which is set to "14". When the master/called GK assigns a session key to the endpoints of the two sides in the future, it is determined by the signaling between the gatekeepers to select which key negotiation process: DRC I, DRC II or DRCIII process.

2. ARQ request phase:

Before the calling EpA calls the called EpB in the direct routing mode, the calling endpoint EpA sends an ARQ to the home GkG, which includes an independent ClearToken, which is assumed to be a CTA, wherein the tokenOID is set as follows: If it is desired to generate a secure share by GK The key is "10", other fields are not used; if EpA wants to use DH to negotiate the shared key with the called gatekeeper, put its DH public key in the dhkey domain, tokenOID is "14", other fields Do not use.

3. LRQ request phase:

After receiving the ARQ sent by EpA, GkG determines that the called EpB belongs to the same administrative domain (destinationInfo or destCallSignalAddress in the message indicates EpB), and the shared key negotiation process is the same as Appendix I/H.235; The domain then initiates an LRQ message to query GkH for the address of EpB. The LRQ message contains a ClearToken. The setting rules of each internal sub-domain are determined by the EpA capability and the specific key negotiation procedure adopted by GkG. The specific settings are as follows: DRC I: When the tokenOID of the ClearToken in the ARQ is ', 10', GkG generates LRQ, which contains a ClearToken, where the tokenOID is set to "10", and other fields of the ClearToken are not used, indicating that the called GK needs to be assigned the session key Kab.

DRC II: When the tokenOID of the ClearToken in ARQ is ,, 10", GkG generates LRQ, which contains a ClearToken, where tokenOID is set to "13", indicating that it is expected to negotiate with the called GK to use the DH process to negotiate a shared session secret for the two endpoints. GkG generates and sets the dhkey in the ClearToken as the DH public key.

DRC III: When the tokenOID of the ClearToken in the ARQ is "14", the DRC III process should be selected according to the security policy. GkG generates LRQ, which contains the ClearToken copied from ARQ.

LCF confirmation

After receiving the LRQ, GkH recognizes that EpA and EpB support this call mode, and performs different key negotiation processes according to the tokenOID of the ClearToken to generate a call-based shared key Kab and two independent ClearTokens. One is used for the calling gatekeeper GkG, called CTg; the other is used for the called endpoint EpB, called CTb. This Kab is then pushed to GkG and EpB by using CTg and CTb, respectively. The specific practices are as follows:

DRC I: If the tokenOID is 'Ί0', it indicates that neither the calling endpoint nor the gatekeeper supports the DH process, and the called gatekeeper is required to generate a shared key for it. In this case, GkH randomly generates Kab. In order to encrypt Kab, first GkH generates a random challenge and derives the key EK _g h using the shared key Kgh and challenge between GkG and the pre-configured key derivation algorithm. Then, GkH encrypts Kab with EKgh to get EKabl, and EKabl and encryption parameters (Encryption algorithm and encryption initialization vector) together, set to CTg.h235Key. secureSharedSecret field, please refer to H.235 Appendix I for details, and set CTg's tokenOID to "10" to indicate that the called GK does not support DH key negotiation. At the same time, GkH uses a similar process to generate another ClearToken, setting the tokenOID to "12", called CTb. Finally, GkH generates LCF, which contains CTg and CTb.

DRC II: The tokenOID at this time is "13", indicating that the DH algorithm is supported between the gatekeepers. Security policies allow the use of DH processes. If GkH also supports the DH process and the security capabilities match, GkH generates its own DH public key and, together with the DH public key of GkG in LRQ, uses the DH algorithm to calculate the session shared key Kab. Then, CTb is generated using a procedure similar to DRC I above, with tokenOID "12". Finally, GkH generates an LCF containing CTb and a separate ClearToken (tokenOID is "13") CTg, which has the desired DH public key set.

If GkH does not support the DH algorithm or the security policy does not allow the use of DH procedures, then GkH should use the DRC I procedure to generate the LRJ.

DRCIII: When tokenOID is "14", if GkH supports DH algorithm and the security policy allows DH process, GkH starts negotiating session key with EpA. First, GkH generates the desired DH public key, and together with the public key obtained from the LRQ, uses the DH algorithm to calculate the session key Kab. Then, a CTb is generated using a method similar to the DRC I procedure, with a tokenOID of "12". Finally, GkH generates LCF, which contains CTb and a separate ClearToken (tokenOID is "15") CTg, which has the desired DH public key set.

5. ACF/ARJ confirmation

After GkG receives the LCF/LRJ and checks that the tokenOID of the CTg in the message is "13", the Kab is calculated by the D-H key negotiation algorithm, and CTa is generated, and the tokenOID is set to "II". The specific method is as follows: Get the DH common key of GkH from the independent ClearToken, and use the DH algorithm to calculate the session key Kab together with the DH shared key saved by itself; then use the same method as below to generate CTa. Finally, GkG generates ACF or ARJ, which contains CTa (tokenOID is Ί) and CTb (tokenOID is "12") copied from LCF/LRJ.

If the tokenOID of the CTg is "10", first, GkG derives the key EKgh through the challenge, IV in the CTg and the specified key derivation algorithm; then, GkG decrypts EKabl with EKgh to obtain the Kab; finally, CTa is generated, and the tokenOID is set therein. For "II". CTa is generated as follows: First, GkG uses the shared key Kag and challenge between GkG and EpA. And the specified key export algorithm derives the key EKag. Then, GkG encrypts Kab with EKag to get EKabl, and sets EKAM and encryption parameters (encryption algorithm and initialization vector IV used for encryption) to a separate CTa.h235Key.secureSliaredSecret field. Finally, GkG generates ACF/ARJ, which contains CTa and CTb copied from LCF/LRJ.

If the tokenOID of the ClearToken in the LCF message received by GkG is "14", then

GkG generates ACF, which contains all ClearTokens copied from the LCF.

6. Setup

After EpA receives the ACF, it checks the tokenOid of the independent ClearToken in the message as "14" and calculates the session key. The method is to obtain the DH common key of the called party from the ClearToken, and use the DH algorithm to calculate the session key Kab together with the DH shared key saved by itself. In other cases, the CTa is directly extracted, and the key EKag is derived based on the information in CTa and its shared key Kag with GkG, and then the key Kab is obtained by decrypting CTa.h235Key.secureSharedSecret. encryptedSessionKey using EKag. EpA creates a Setup message, copies the CTb in the ACF message into the Setup message, and then sets the H235V3 appendix D authentication information using the shared key Kab. EpA sends a call setup request message Setup directly to EpB.

7. The following call signaling settings:

After receiving the Setup message, EpB extracts the CTb, and derives the key EKbh according to the information in CTb and its shared key Kbh with GkH, and then uses EKbh to decrypt CTb.h235Key.secureSharedSecret.encr ptedSessionKey to obtain the key Kab; at this time, EpB Kab can be used to authenticate Setup and subsequent call signaling messages. Industrial applicability

Through the foregoing method of the embodiment of the present invention, based on the security policy of the present invention, a trusted session key can be dynamically negotiated, and cryptographically bundled with call authentication, including session key refresh requirement. In the implementation of the present invention, the adopted security technology is compatible with existing standards, and the security system is also relatively simple in arrangement and does not assume any additional security infrastructure methods, such as smart cards and complex management protocols.

Claims

Power brake request

A method for implementing a key agreement security policy for a cross-domain multi-gatekeeper packet network, characterized in that the method comprises the following steps:

(2) The calling endpoint sends a key negotiation request to the calling gatekeeper according to the determined local security policy, and the calling gatekeeper determines the highest and lowest priority keys according to the security policy of the calling endpoint and its own key support capability. Negotiating the procedure and forwarding the key agreement request of the calling endpoint to the called gatekeeper according to the highest priority procedure;

2. The method of claim 1 further comprising the step of -

3. The method according to claim 1, wherein the signaling interaction process in the step (1) is a gatekeeper discovery process or/and a registration process.

4. The method according to claim 1, wherein the key support capability is to support public key key negotiation.

5. The method according to claim 1, wherein the step (1) comprises: (1 - 1) by the gatekeeper discovery request or/and the registration request message, the endpoint reports to the home gatekeeper whether it supports Public key key negotiation;

(1 - 2) The gatekeeper returns a determined endpoint local security policy to the endpoint based on whether the endpoint supports the public key key negotiation, or through the gatekeeper discovery confirmation or/and the registration confirmation message, where - When the endpoint and the gatekeeper do not support the public key key negotiation, the endpoint local security policy is determined as: It is desirable that the gatekeeper generate the shared key on its behalf;

When both the endpoint and the gatekeeper support public key key negotiation, the endpoint local security policy is determined as: It is desirable to generate a shared key through signaling negotiation with the called gatekeeper.

The method according to claim 1, wherein the key negotiation request sent by the calling endpoint to the calling gatekeeper is an access request message, where the message includes the calling party. Local security policy information for the endpoint.

The method according to claim 6, wherein when the calling endpoint local security policy is configured to generate a shared key by signaling negotiation with the called gatekeeper, the access request message further includes Public key information.

The method according to claim 6, wherein in step (2), the calling gatekeeper determines the priority of the key agreement procedure according to the security policy of the calling endpoint and the key support capability of the calling endpoint. , including:

When the calling endpoint local security policy is to generate a shared key by signaling negotiation with the called gatekeeper, the highest priority procedure for determining the key agreement procedure is: the calling endpoint and the called gatekeeper use the public key The key negotiation process generates a session key; the lowest priority procedure is: The session key is generated by the called gatekeeper.

The method of claim 6, wherein the access request message further includes called endpoint information, and the calling gatekeeper determines whether the called endpoint and the calling party are based on the called endpoint information. Endpoints belong to different administrative domains.

10. The method according to claim 1, wherein in the step (2), the step of the calling gatekeeper forwarding the key agreement request of the calling endpoint to the called gatekeeper according to the highest priority procedure is The address resolution request is sent by the address resolution request, and the determined highest priority procedure information is included in the address resolution request.

The method according to claim 8, wherein in the step (3), the called gatekeeper determines whether the key negotiation request of the forwarded calling endpoint can be performed according to the highest priority procedure. The step of including, when the highest priority procedure is to generate a session key by the called gatekeeper, determining that the key negotiation can be performed according to the highest priority procedure;

When the highest priority procedure generates a session key for the calling gatekeeper and the called gatekeeper using the public key key negotiation process, if the called gatekeeper supports the public key key negotiation, it is determined that the highest priority can be followed. Procedure to perform key agreement; if the called gatekeeper does not support public key key negotiation, it is determined that key negotiation cannot be performed according to the highest priority procedure;