WO2007093079A1 - Procédé de mise en oeuvre d'une politique de sécurité en matière de négociation-clé dans un réseau interdomaine de commutation de paquets à plusieurs garde-portes - Google Patents

Procédé de mise en oeuvre d'une politique de sécurité en matière de négociation-clé dans un réseau interdomaine de commutation de paquets à plusieurs garde-portes Download PDF

Info

Publication number
WO2007093079A1
WO2007093079A1 PCT/CN2006/000225 CN2006000225W WO2007093079A1 WO 2007093079 A1 WO2007093079 A1 WO 2007093079A1 CN 2006000225 W CN2006000225 W CN 2006000225W WO 2007093079 A1 WO2007093079 A1 WO 2007093079A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
gatekeeper
endpoint
calling
negotiation
Prior art date
Application number
PCT/CN2006/000225
Other languages
English (en)
Chinese (zh)
Inventor
Chen Lu
Liang Zhang
Guangfeng Li
Yan Li
Changyin Sun
Weigang Liu
Original Assignee
Zte Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Zte Corporation filed Critical Zte Corporation
Priority to CN200680035570.8A priority Critical patent/CN101273571B/zh
Priority to PCT/CN2006/000225 priority patent/WO2007093079A1/fr
Publication of WO2007093079A1 publication Critical patent/WO2007093079A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H04L9/0844—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols with user authentication or key authentication, e.g. ElGamal, MTI, MQV-Menezes-Qu-Vanstone protocol or Diffie-Hellman protocols using implicitly-certified keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102—Entity profiles

Definitions

  • 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.
  • DRC Direct Router Call
  • 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.
  • 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).
  • ARQ Admission Request Access Request
  • ACF Admission
  • Confirm access confirmation Admission Reject access rejection
  • ARJ Admission Reject access rejection
  • 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.
  • 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
  • LCF Location Confirm address resolution confirmation
  • LRJ Location Reject address resolution rejection
  • 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.
  • 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.
  • 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.
  • 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.
  • the present invention provides a cross-domain multi-gatekeeper packet network key negotiation security policy implementation method, which includes the following steps:
  • 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;
  • 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.
  • 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:
  • the calling endpoint 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;
  • 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;
  • 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.
  • 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:
  • the highest and lowest priority procedures for determining the key agreement procedure are: The gatekeeper generates a session key;
  • 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;
  • 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.
  • 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.
  • 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:
  • 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;
  • 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;
  • 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.
  • 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.
  • FIG. 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.
  • GK GateKeeper
  • 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.
  • 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.
  • 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.
  • GK acts as a trusted intermediate entity, terminating the security association between hops.
  • 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.
  • a scenario diagram of a multi-gateway routing mode for implementing a cross-domain multi-gatekeeper packet network key agreement security policy includes: a calling endpoint 101 (EpA), a calling network ⁇ 102 (GkG), intermediate gatekeeper 103, called gatekeeper 104 (GkH), called endpoint 105 (EpB).
  • EpA calling endpoint 101
  • GkG calling network ⁇ 102
  • GkH intermediate gatekeeper 103
  • GkH gatekeeper 104
  • EpB endpoint 105
  • 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.
  • DH Diffie-Hellman
  • 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.
  • 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 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.
  • GRQ/RRQ gatekeeper discovery and gatekeeper registration request
  • 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.
  • GCF/RCF gatekeeper discovery request response and gatekeeper registration request response
  • GRJ/RRJ gatekeeper response rejection/registration response rejection
  • 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.
  • tokenOID is set to indicate the required key negotiation capability object identifier to the called gatekeeper, while other fields are not used.
  • 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 calling endpoint gatekeeper 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.
  • 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.
  • GkH sends the GkH-GkG session key semi-public key generated by the public key method to GkG in the LCF message.
  • 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 2228 The EpB sends a Call Proceeding message to the EpA, and performs a step 229 in response to the call setup request message.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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:
  • Embodiments of the present invention support and not support Diffie-Hdlman in endpoints and gatekeepers respectively.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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".
  • 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.
  • 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.
  • GkG 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.
  • 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.
  • GkH 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.
  • 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.
  • GkH uses a similar process to generate another ClearToken, setting the tokenOID to "12", called CTb.
  • 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.
  • 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.
  • GkH should use the DRC I procedure to generate the LRJ.
  • GkG 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.
  • CTa is generated, and the tokenOID is set therein.
  • 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.
  • 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.
  • GkG generates ACF, which contains all ClearTokens copied from the LCF.
  • EpA 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.
  • EpB 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.
  • a trusted session key can be dynamically negotiated, and cryptographically bundled with call authentication, including session key refresh requirement.
  • 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.

Abstract

Selon l'invention, un type de procédé de mise en œuvre d'une politique de sécurité en matière de négociation-clé dans un réseau interdomaine de commutation de paquets à plusieurs garde-portes comprend les étapes suivantes: chaque terminal détermine respectivement sa politique de sécurité locale par échange de signalisation avec le garde-porte auquel il appartient; conformément à la politique de sécurité du terminal appelant et sa propre capacité de soutien clé, le garde-porte appelant détermine le protocole de négociation-clé et envoie une demande de négociation-clé; le garde-porte appelé détermine s'il peut exécuter la demande de négociation-clé transmise par le terminal appelant conformément au protocole de priorité absolue; le terminal appelant détermine s'il y a lieu de continuer à mener l'échange de signalisation suivant conformément à la politique de sécurité de négociation. Le procédé de mise en œuvre de la politique de sécurité de l'invention permet de négocier de manière dynamique une clé de session admissible, d'établir un lien avec l'authentification des appels par cryptologie, et d'exécuter la politique de sécurité du réseau de commutation de paquets. Cette technologie de sécurité est compatible avec les normes existantes. L'utilisation du système de sécurité est simple, sans nécessité de recourir à un quelconque procédé faisant intervenir une infrastructure de sécurité additionnelle.
PCT/CN2006/000225 2006-02-16 2006-02-16 Procédé de mise en oeuvre d'une politique de sécurité en matière de négociation-clé dans un réseau interdomaine de commutation de paquets à plusieurs garde-portes WO2007093079A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN200680035570.8A CN101273571B (zh) 2006-02-16 2006-02-16 跨域多网守分组网络密钥协商安全策略的实现方法
PCT/CN2006/000225 WO2007093079A1 (fr) 2006-02-16 2006-02-16 Procédé de mise en oeuvre d'une politique de sécurité en matière de négociation-clé dans un réseau interdomaine de commutation de paquets à plusieurs garde-portes

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2006/000225 WO2007093079A1 (fr) 2006-02-16 2006-02-16 Procédé de mise en oeuvre d'une politique de sécurité en matière de négociation-clé dans un réseau interdomaine de commutation de paquets à plusieurs garde-portes

Publications (1)

Publication Number Publication Date
WO2007093079A1 true WO2007093079A1 (fr) 2007-08-23

Family

ID=38371164

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2006/000225 WO2007093079A1 (fr) 2006-02-16 2006-02-16 Procédé de mise en oeuvre d'une politique de sécurité en matière de négociation-clé dans un réseau interdomaine de commutation de paquets à plusieurs garde-portes

Country Status (2)

Country Link
CN (1) CN101273571B (fr)
WO (1) WO2007093079A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101729531A (zh) * 2009-03-16 2010-06-09 中兴通讯股份有限公司 网络安全策略分发方法、装置及系统
CN105302564A (zh) * 2015-11-09 2016-02-03 中国人民解放军91655部队 网络办公软件服务控件及实现方法

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102223355B (zh) * 2010-04-19 2015-09-16 中兴通讯股份有限公司 一种安全通信协商方法和装置
CN104363208B (zh) * 2014-10-29 2018-08-07 中国建设银行股份有限公司 一种计算机集群间密钥管理方法及系统
CN109560929B (zh) * 2016-07-01 2020-06-16 华为技术有限公司 密钥配置及安全策略确定方法、装置
EP3756326B1 (fr) * 2018-02-19 2021-08-04 Telefonaktiebolaget Lm Ericsson (Publ) Négociation de sécurité dans des architectures fondées sur un service (sba)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1202060A (zh) * 1997-05-21 1998-12-16 阿尔卡塔尔-阿尔斯托姆通用电气公司 移动无线网络终端间进行直接加密通信的方法及相应设施
WO2005034472A1 (fr) * 2003-09-30 2005-04-14 Nokia Corporation Procede et systeme assurant une communication securisee entre des reseaux de communication
CN1652499A (zh) * 2004-02-07 2005-08-10 华为技术有限公司 一种消息传输的实现方法
CN1705261A (zh) * 2004-05-28 2005-12-07 华为技术有限公司 一种端对端加密通讯系统及方法

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1529531A (zh) * 2003-10-17 2004-09-15 ����ͨѶ�ɷ����޹�˾ 一种移动用户接入安全网关的方法
CN100373843C (zh) * 2004-03-23 2008-03-05 中兴通讯股份有限公司 一种无线局域网中密钥协商方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1202060A (zh) * 1997-05-21 1998-12-16 阿尔卡塔尔-阿尔斯托姆通用电气公司 移动无线网络终端间进行直接加密通信的方法及相应设施
WO2005034472A1 (fr) * 2003-09-30 2005-04-14 Nokia Corporation Procede et systeme assurant une communication securisee entre des reseaux de communication
CN1652499A (zh) * 2004-02-07 2005-08-10 华为技术有限公司 一种消息传输的实现方法
CN1705261A (zh) * 2004-05-28 2005-12-07 华为技术有限公司 一种端对端加密通讯系统及方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101729531A (zh) * 2009-03-16 2010-06-09 中兴通讯股份有限公司 网络安全策略分发方法、装置及系统
CN105302564A (zh) * 2015-11-09 2016-02-03 中国人民解放军91655部队 网络办公软件服务控件及实现方法

Also Published As

Publication number Publication date
CN101273571B (zh) 2010-05-19
CN101273571A (zh) 2008-09-24

Similar Documents

Publication Publication Date Title
US9537837B2 (en) Method for ensuring media stream security in IP multimedia sub-system
JP5106682B2 (ja) マシン・ツー・マシン通信のための方法及び装置
WO2005112338A1 (fr) Procede de distribution de cles
JP2014519256A (ja) エンドツーエンド暗号化を用いる通信システムにおけるポリシールーティングに基づく合法的傍受
WO2010124482A1 (fr) Procédé et système servant à mettre en place une session d'appel de ramification sécurisée dans un sous-système multimédia ip
WO2007073659A1 (fr) Methode d'acces des terminaux a base de protocole h.323 applique a un reseau de paquets
WO2008040213A1 (fr) Procédé, système et dispositif de chiffrement et de signature de messages dans un système de communication
WO2007093079A1 (fr) Procédé de mise en oeuvre d'une politique de sécurité en matière de négociation-clé dans un réseau interdomaine de commutation de paquets à plusieurs garde-portes
WO2005104423A1 (fr) Procede de communication secrete entre deux points limites
CN100571133C (zh) 媒体流安全传输的实现方法
WO2005079013A1 (fr) Procede de transmission de messages dans le systeme h323
CN100544247C (zh) 安全能力协商方法
CN101207477A (zh) 一种跨域多网守端到端会话密钥协商方法
WO2009132551A1 (fr) Procédé d’obtention de clé de flux multimédia, équipement de session et entité à fonction de gestion de clé
WO2008074226A1 (fr) Procédé pour négocier la clé secrète de session entre les points d'extrémité à travers des zones à multiples contrôleurs d'accès
US7983280B2 (en) Method and system for distributing session key across gatekeeper zones in a direct-routing mode
WO2009094813A1 (fr) Procédé et appareil de négociation de paramètres de sécurité pour sécuriser le flux multimédia
CN113114644B (zh) 一种基于sip架构的多级跨域对称密钥管理系统
CN1323509C (zh) 一种直接路由模式下跨关守管理范围的会话密钥分配方法
Floroiu et al. A comparative analysis of the security aspects of the multimedia key exchange protocols
CN117155717B (zh) 基于标识密码的认证方法、跨网跨域数据交换方法及系统
CN101207478B (zh) 一种跨域多网守端到端会话密钥协商方法
Meddahi et al. Enabling secure third party control on wireless home networks
Medvinsky Scalable architecture for VoIP privacy
Verma et al. A Network Based Authentication Scheme for VoIP

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 200680035570.8

Country of ref document: CN

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06705646

Country of ref document: EP

Kind code of ref document: A1