CN101207477A - Method for multi-network guard end-to-end conversation cryptographic key negotiation of striding field - Google Patents
Method for multi-network guard end-to-end conversation cryptographic key negotiation of striding field Download PDFInfo
- Publication number
- CN101207477A CN101207477A CNA2006101622799A CN200610162279A CN101207477A CN 101207477 A CN101207477 A CN 101207477A CN A2006101622799 A CNA2006101622799 A CN A2006101622799A CN 200610162279 A CN200610162279 A CN 200610162279A CN 101207477 A CN101207477 A CN 101207477A
- Authority
- CN
- China
- Prior art keywords
- gatekeeper
- called
- hellman
- diffie
- shared secret
- Prior art date
- Legal status (The legal status 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 status listed.)
- Withdrawn
Links
Images
Abstract
The invention discloses a cross-domain multi network keeper end-to-end session key negotiation method, which dynamically negotiates a best key negotiation method in the end-to-end communication through signaling execution flows of ARQ/ACF and LRQ/LCF based on that whether D-H key exchange algorithm and security strategy are supported by the network keepers. The method comprises the following steps: a called network keeper generates a sharing secret, a calling network keeper and a calling endpoint obtain the session key according to the sharing secret, and the calling network keeper and the called network keeper generate the session key by using the D-H key exchange algorithm, thereby the generation and the exchange of the sharing secret or the session key are carried out among each endpoint, thus the limits of low efficiency and bad interconnection and interoperability, which are caused by the fact that the key negotiation method is based on pre-configuration, are overcome under the prior cross-domain multi network keeper end-to-end calling mode.
Description
Technical field
The present invention relates to the packet network communication security fields, relate in particular to end-to-end communication session keys machinery of consultation under the direct routing call pattern of a kind of cross-domain many gatekeepers.
Background technology
Based on the packet network communication security fields, key is of paramount importance, on the network H.323 between the end points by cipher key change resulting share or session key can be to RAS (registration, access and state) signaling, call signaling, H.245 control signaling etc. and implement identity and confirm, signaling message integrity checking and media data flow carried out safety measure such as enciphering/deciphering.
At present, many gatekeepers route pattern is shared down or the session key exchange method, and basic what adopt is pre-configured and out-of-band methods such as phone, E-Mail.
Directly routing call (hereinafter to be referred as DRC) pattern is an important method of call setup in the H.323 packet-based multimedia communications system.Because under the DRC pattern, (shared secret is with information such as user ID, password and random numbers can not to suppose have a pre-shared secret or session key between two end points, can generate session key by hashing algorithm), therefore, above institute's using method or be difficult to difficult arrangement, otherwise dangerous and can't use in practice.
H.235 standard definition a kind of based on protocol suite H.323; realize the communication security method; comprise Diffie-Hellman (Defo-Hellman is called for short D-H) public key cryptography IKE, random number generates shared secret and is carried out the key generation and the switching method of encipherment protection by symmetric cryptography.But a kind of cross-domain many gatekeepers' end-to-end key agreement and switching technology are not proposed, also do not consider the disposal ability that makes full use of end points and gatekeeper, and how dynamic negotiation goes out the cryptographic methods that a kind of both sides support to have the terminal of different key agreement abilities.Particularly under the direct routing call pattern of many gatekeepers environment H.323, existing terminal equipment possesses the multiple session key method of setting up, and under can not situation that in advance can be pre-configured between two end points of communication, brings difficulty for the communication security that interconnects.
Summary of the invention
The technical problem to be solved in the present invention just provides a kind of method for multi-network guard end-to-end conversation cryptographic key negotiation of striding field, do not support in calling endpoint under the situation of D-H Diffie-Hellman, overcome under the present end-to-end call model of cross-domain many gatekeepers, cryptographic key negotiation method is based on pre-configured and efficient that bring is not high, the restriction of interconnecting property difference.
In order to solve the problems of the technologies described above, the invention provides a kind of method for multi-network guard end-to-end conversation cryptographic key negotiation of striding field, comprise the steps:
(1) before calling endpoint is used direct routing call DRC calling called end point, calling endpoint will be called out to insert and be asked ARQ message to send to the gatekeeper that it belongs to, and this gatekeeper is the caller gatekeeper;
(2) after the caller gatekeeper receives ARQ, initiate Location Request LRQ message, with inquiry address, called end point to called gatekeeper; In this LRQ message, the caller gatekeeper selects whether support the D-H Diffie-Hellman, thereby selects a kind of method that generates session key according to self-ability and security strategy;
(3) after called gatekeeper receives LRQ, selection according to the caller gatekeeper, and whether called gatekeeper supports D-H Diffie-Hellman and security strategy, the final method of determining to generate session key, and put into positioning confirmation LCF message with this information and according to the shared secret that this method generates, be used for communicating by letter between calling endpoint and the called end point, LCF is sent to the caller gatekeeper;
(4) after the caller gatekeeper receives LCF message,, the shared secret that is used for calling endpoint is decrypted and then encrypts forwarding, generate ACF message in view of the above and send to calling endpoint according to the method for fixed generation session key; Also duplicated the shared secret that is used for the called end point among the LCF in this ACF message;
(5) after calling endpoint is received ACF message, extract the secret of sharing with the called end point, and then obtain session key.
Further, the method for generation session key comprises:
(a) produce shared secret by called gatekeeper, caller gatekeeper and calling endpoint obtain session key according to this shared secret;
(b) use the D-H Diffie-Hellman to generate session key by caller gatekeeper and called gatekeeper;
Further, described ARQ, LRQ, LCF, ACF all comprise expressly mark ClearToken, tokenOID among the ClearToken is used to represent whether calling endpoint, caller gatekeeper, called gatekeeper support the D-H Diffie-Hellman, be used to perhaps represent that this ClearToken comprises shared secret, give calling endpoint or called end point and use.
Further, in the described step (2), if calling endpoint is not supported the D-H Diffie-Hellman, and the caller gatekeeper supports the D-H Diffie-Hellman, selection uses the D-H Diffie-Hellman to generate session key by caller gatekeeper and called gatekeeper, the caller gatekeeper produces the D-H PKI, and deposits this PKI among the LRQ dhkey territory among the ClearToken.
Further, in the described step (3), if calling endpoint and caller gatekeeper do not support the D-H Diffie-Hellman, perhaps called gatekeeper does not support D-H Diffie-Hellman or security strategy not to allow to use the D-H Diffie-Hellman, then produce shared secret by called gatekeeper, after this shared secret encrypted, put into the CTg.h235Key.secureSharedSecret field of LCF message with encryption parameter; Simultaneously, after called gatekeeper produced shared secret and encrypts, another that put into LCF message with encryption parameter was used for called end point ClearToken.
Further, in the described step (3), if calling endpoint is not supported the D-H Diffie-Hellman, but the security strategy of supporting D-H Diffie-Hellman and GkH between caller gatekeeper and the called gatekeeper allows to use the D-H Diffie-Hellman, then generate the D-H PKI by called gatekeeper, with the D-H PKI of caller gatekeeper in the LRQ together, use the D-H Diffie-Hellman to calculate the shared secret of session, this shared secret generates the ClearToken that the D-H PKI is put into LCF message with encryption parameter and called gatekeeper after encrypting; Simultaneously, after the shared secret that calculates was encrypted, another that put into LCF message with encryption parameter was used for called end point ClearToken.
Further, in the described step (4), the caller gatekeeper checks and receives LCF, if produce shared secret by called gatekeeper, then with the shared secret deciphering of encrypting among this LCF, encrypt again, and be saved in the CTA.h235Key.secureSharedSecret field of ClearToken of ACF with encryption parameter; To be used for called end point ClearToken simultaneously and copy to ACF.
Further, in the described step (4), the caller gatekeeper checks and receives LCF, if use the D-H Diffie-Hellman to generate session key by caller gatekeeper and called gatekeeper, from the ClearToken of LCF, obtain called gatekeeper's D-H PKI, the D-H PKI of preserving with the caller gatekeeper together uses the D-H Diffie-Hellman to calculate shared secret, and this shared secret is saved among the ClearToken of ACF with encryption parameter after encrypting; To be used for called end point ClearToken simultaneously and copy to ACF.
Further, in the described step (5), the ACF that the calling endpoint inspection is received obtains session key according to the ClearToken information among the ACF and calling endpoint and caller gatekeeper's shared secret key decryption.
Advantage of the present invention has:
1. by dynamic adaptation terminal and gatekeeper's security capabilities, can improve the efficient of cipher key change, reduce time-delay and gatekeeper's processing load, in implementing the secure communication process, increase the flexibility that different security capabilities terminals interconnect simultaneously.
2. by means of ARQ/ACF, the LRQ/LCF signaling is carried out flow process, whether support public key cryptography and symmetric cryptographic algorithm based on end points and gatekeeper, dynamic negotiation goes out cryptographic key negotiation method optimum in a kind of end-to-end communication, and finish the shared secret between the end points or the generation and the exchange of session key with the method, set up security relationship for the subsequent voice calls signaling, prevent that signaling and data-message are forged, integrality and possible confidentiality lose.
3. safe practice of Cai Yonging and existing standard are compatible, and the layout of security system is also fairly simple, and do not need to suppose any additional security infrastructure method.
Along with the extensive H.323 arrangement and the application of multimedia communications system, as the VoIP net of global range or range of countries video conference/video-phone system towards the public etc., at this multi-operator, stride under a plurality of many gatekeepers of management domain layering DRC environment, use the more convenient practicality of method provided by the invention.
4. the inventive method also can be applied to other many gatekeepers call model, as part/routing mode, directly/and route, route/direct mode and gatekeeper's routing mode etc.
Description of drawings
Fig. 1 is the direct routing call pattern of a many gatekeepers scene;
Fig. 2 is that shared secret is consulted flow chart under the direct routing call pattern of many gatekeepers.
Embodiment
The present invention is described in detail below in conjunction with drawings and the specific embodiments.
Be explanation the inventive method, quote ability or the two combination that following symbol is represented end points and gatekeeper, perhaps be used for distinguishing the shared secret that preserve caller/called end point.
| Symbol | The meaning of expression |
| " I0 " | Show that calling endpoint do not support D-H, caller gatekeeper or called gatekeeper do not support the D-H Diffie-Hellman. |
| " I1 " | Give among the independent ClearToken of calling endpoint and use, show among this ClearToken to comprise shared secret. |
| " I2 " | Give among the independent ClearToken of called end point and use, show among this ClearToken to comprise shared secret. |
| " I3 " | Show that calling endpoint do not support the D-H process, but the calling and called gatekeeper supports the D-H Diffie-Hellman. |
The embodiment of the invention adopts the H.323 direct route pattern of system's cross-gate keeper range of management, and supposes that calling/called end points is registered in respectively on the different calling/called gatekeepers, and communication process is to carry out on the IP network that does not have fail safe to guarantee.The scene of using as shown in Figure 1.
Fig. 1 is the direct communication scenes figure in routing mode of many gatekeepers.Gatekeeper's cloud among the figure comprises one or more gatekeepers, and end points can be connected to identical or different gatekeeper.Directly in the routed call models, the gatekeeper does not participate in H.225.0 call control signalling, does not therefore carry out the signaling tunnel in H.225.0.Like this, the gatekeeper does not influence two tunnels between the end points of supporting the signaling tunnels.Directly in the routed call models, H.245 control channel can only directly connect between end points.Based on control channel H.245, finish real time data flow host-host protocol (RTP).
In communication process shown in Figure 1, at first, on the RAS channel, end points and gatekeeper exchange access message, exchange call signaling then on call signaling channel, are the H.245 foundation of control channel then.The gatekeeper has determined whether to use direct routing call pattern to the response that inserts message.Though end points can be specified preference, not receiving end point control of model selection.
In the embodiment of the invention, the gatekeeper authenticates and integrity checking all RAS messages of its management end points, end points authenticates and integrity checking the also RAS message to the gatekeeper, thereby make between end points and the affiliated gatekeeper and reach the mutual trust purpose, so that can check out the entity of swindle, and will be dropped to minimum by the swindle possibility.Also differentiate mutually between gatekeeper and the gatekeeper in the mid-level net cloud, avoid the malicious attack between the gatekeeper territory.Under these conditions, the H.323 fail safe of RAS channel between the end points can be guaranteed, the fail safe of call signaling can be realized based on this.
In the embodiment of the invention, method 1 expression produces shared secret by called gatekeeper, and then can generate session key; Method 2 expressions use the D-H Diffie-Hellman to generate session key by caller gatekeeper and called gatekeeper.
Below in conjunction with Fig. 2 dynamic decision flow chart, illustrate according to the logical order of RAS signaling and call signaling three kinds of methods of the present invention are how to come out according to the security strategy dynamic negotiation, to carry out key agreement between the common support end points.
1.ARQ request stage:
Calling endpoint EpA is before using direct routing call call by pattern called end point EpB, EpA sends ARQ message to ownership GkG, comprise an independently ClearToken in the message, be assumed to be CTA, wherein whether tokenOID is according to supporting D-H to adopt different settings, and this can be set according to terminal capability and security strategy by the user.Hope on behalf of generating safe shared secret, then provides a sign " I0 " by GK, and other fields are not used.
2.LRQ request stage:
GkG judges and does not belong to same management domain after receiving the ARQ that EpA sends, and initiates the address of LRQ message to GkH inquiry EpB.LRQ message comprises a ClearToken, and the rule that is provided with of its inner each subdomain is adopted concrete key agreement rules to decide by EpA ability and GkG, specifically is provided with as follows:
If the caller gatekeeper does not support D-H cipher key change and negotiation, at this moment GkG generates LRQ (Fig. 2 numeral 1), comprise a ClearToken, wherein tokenOID is set to " I0 ", other fields of ClearToken are not used, these are provided with explanation and will adopt method 1 to carry out key agreement, promptly need called GK to distribute shared secret, are assumed to be Kab.
If calling/called gatekeeper supports the D-H Diffie-Hellman, GkG generates LRQ, comprises a ClearToken, and wherein tokenOID is provided with an identifier, as " I3 ", show that it is the shared secret that two limit end points negotiate session that expectation is used the D-H Diffie-Hellman with called GK.(Fig. 2 numeral 4) GkG produces and is provided with dhkey among the ClearToken as the D-H PKI.
3.LCF confirm
GkH receives behind the LRQ and identifies EpA and EpB supports this call model, carry out different cipher key agreement process according to the tokenOID of contained ClearToken and generate ClearToken independently based on the shared secret of calling out (, generating session key when communicating by letter later on) Kab and two based on this shared secret.One is used for caller gatekeeper Gkg, supposes to be called CTg; Another is used for called end point EpB, supposes to be called CTb.This Kab is then by using CTg and CTB to be pushed to GkG and EpB respectively.
According to the different value of tokenOID, the LCF specific practice of returning distinct methods is as follows:
3.1 if the tokenOID among the LRQ is " I0 ", show employing method 1.
" I0 " among the LRQ shows that calling endpoint and its ownership gatekeeper do not support the D-H Diffie-Hellman, requires called gatekeeper to generate shared secret for it.Under (Fig. 2 numeral 2) this situation, the LCF employing method of returning 1, its concrete setting up procedure is as follows:
GkH produces Kab at random.In order to encrypt Kab, at first, GkH produces challenge at random, and with and GkG between shared key K gh and key of key derivation algorithm derivation of challenge and configured in advance, as be made as EKgh.Then, GkH encrypts Kab with EKgh and obtains a shared secret, as be set at EKab1, and together EKab1 and encryption parameter (cryptographic algorithm and use initialization vector), be set in the CTg.h235Key.secureSharedSecret field, detail can be with reference to appendix I H.235, and the tokenOID that CTg is set is " I0 ".Simultaneously, GkH uses similar process to produce another ClearToken, tokenOID is set is " I2 ", is called CTb.At last, GkH generates LCF (Fig. 2 numeral 2), wherein comprises CTg and CTb.
3.2 if the tokenOID among the LRQ is " I3 ", show employing method 2 or method 1.
" I3 " shows that end points do not support the D-H Diffie-Hellman among the LRQ, but expectation supports the security strategy of D-H Diffie-Hellman and GkH to allow to use D-H Diffie-Hellman (Fig. 2 numeral 4) between the gatekeeper.Detailed process is as follows:
Be complementary when GkH supports D-H Diffie-Hellman and security capabilities, then GkH generates own D-H PKI, and and LRQ in GkG the D-H PKI together, use the D-H algorithm computation to go out session shared secret Kab.Then, use with top method 1 similar procedure and generate CTb, tokenOID is " I2 ".At last, GkH generates LCF (Fig. 2 numeral 5), wherein comprises CTb and an independent ClearToken (tokenOID is " I3 ") CTg, and the D-H PKI of the expectation of setting is wherein arranged.
If GkH does not support D-H algorithm or security strategy not to allow to use the D-H Diffie-Hellman, then GkH uses said method 1 process to generate LCF (Fig. 2 numeral 7).
4.ACF confirm
After GkG receives LCF, when the tokenOID of the CTg in the check message is " I3 " (Fig. 2 numeral 5), adopt the D-H Diffie-Hellman to calculate Kab, produce CTa, tokenOID is made as " I1 " in it.Specific practice is: obtain the D-H PKI of GkH from independent ClearToken, together use the D-H algorithm computation to go out shared secret Kab with the D-H PKI of oneself preserving; Use then with following same procedure and generate CTa.At last, GkG generates ACF (Fig. 2 numeral 6), the CTb that wherein comprises CTa (tokenOID for " I1 ") and duplicate from LCF (tokenOID for " I2 ").
If the tokenOID of CTg is " I0 " (possible corresponding diagram 2 numerals 1,5,9 three kinds of situations, the called sign of not supporting D-H and being returned) time, at first, GkG can derive algorithm key derivation Ekgh by the key of challenge, IV among the CTg and appointment, or derives by other security mechanism; Then, GkG obtains Kab with EKgh deciphering EKab1; Produce CTa at last, tokenOID is made as " I1 " in it.The generation way of CTa is as follows: at first, GkG derives algorithm key derivation EKag with the key of the shared secret Kag between GkG and the EpA and challenge and appointment.Then, GkG encrypts Kab with EKag and obtains EKab1, and EKab1 and encryption parameter (cryptographic algorithm and the initialization vector of using) together, is set to one independently in the CTA.h235Key.secureSharedSecret field.At last, GkG generates ACF (one of 3,8,13 3 kinds of situations of possible corresponding diagram 2 numerals, caller or the called sign of not supporting D-H and being returned), the CTb that wherein comprises CTa and duplicate from LCF.
5.Setup
After EpA receives ACF, directly extract CTa, and according to the shared key K ag key derivation EKag of information among the CTa and itself and GkG, use EKag deciphering CTa.h23 5Key.secureSharedSecret.encryptedSessionKey to obtain shared secret Kab then, and then can calculate session key.
EpA creates Setup message, and the CTb in the ACF message is copied in the Setup message, utilizes session key that the authentication information of H235V3 appendix D/ appendix F is set then.EpA directly sends call setup request message Setup to EpB.
6. the call signaling setting of back:
After EpB receives Setup message, extract CTb, and, use EKbh to decipher CTb.h235Key.secureSharedSecret.encryptedSessionKey then and obtain shared secret Kab according to information among the CTb and its shared key K bh key derivation EKbh with GkH; At this moment, EpB just can use Kab that Setup and follow-up call-signaling message are carried out authentication.
By above ARQ, LRQ, LCF, the order of ACF signaling flow is carried out in the flow process, according to caller eventually, whether caller gatekeeper and called gatekeeper possess 8 kinds of states of D-H ability, and (method 1 is low according to different security capabilities, priority, method 2 height) and other security strategy come common implementing how dynamic negotiation go out the consistent key of supporting of both sides between gatekeeper and gatekeeper or terminal and gatekeeper to generate and switching method, i.e. method 1 or method 2.
Claims (9)
1. a method for multi-network guard end-to-end conversation cryptographic key negotiation of striding field comprises the steps:
(1) before calling endpoint is used direct routing call DRC calling called end point, calling endpoint will be called out to insert and be asked ARQ message to send to the gatekeeper that it belongs to, and this gatekeeper is the caller gatekeeper;
(2) after the caller gatekeeper receives ARQ, initiate Location Request LRQ message, with inquiry address, called end point to called gatekeeper; In this LRQ message, the caller gatekeeper selects whether support the D-H Diffie-Hellman, thereby selects a kind of method that generates session key according to self-ability and security strategy;
(3) after called gatekeeper receives LRQ, selection according to the caller gatekeeper, and whether called gatekeeper supports D-H Diffie-Hellman and security strategy, the final method of determining to generate session key, and put into positioning confirmation LCF message with this information and according to the shared secret that this method generates, be used for communicating by letter between calling endpoint and the called end point, LCF is sent to the caller gatekeeper;
(4) after the caller gatekeeper receives LCF message,, the shared secret that is used for calling endpoint is decrypted and then encrypts forwarding, generate ACF message in view of the above and send to calling endpoint according to the method for fixed generation session key; Also duplicated the shared secret that is used for the called end point among the LCF in this ACF message;
(5) after calling endpoint is received ACF message, extract the secret of sharing with the called end point, and then obtain session key.
2. method according to claim 1 is characterized in that:
The method that generates session key comprises:
(a) produce shared secret by called gatekeeper, caller gatekeeper and calling endpoint obtain session key according to this shared secret;
(b) use the D-H Diffie-Hellman to generate session key by caller gatekeeper and called gatekeeper.
3. method according to claim 2, it is characterized in that: described ARQ, LRQ, LCF, ACF all comprise expressly mark ClearToken, tokenOID among the ClearToken is used to represent whether calling endpoint, caller gatekeeper, called gatekeeper support the D-H Diffie-Hellman, be used to perhaps represent that this ClearToken comprises shared secret, give calling endpoint or called end point and use.
4. method according to claim 3, it is characterized in that: in the described step (2), if calling endpoint is not supported the D-H Diffie-Hellman, and the caller gatekeeper supports the D-H Diffie-Hellman, selection uses the D-H Diffie-Hellman to generate session key by caller gatekeeper and called gatekeeper, the caller gatekeeper produces the D-H PKI, and deposits this PKI among the LRQ dhkey territory among the ClearToken.
5. method according to claim 3, it is characterized in that: in the described step (3), if calling endpoint and caller gatekeeper do not support the D-H Diffie-Hellman, perhaps called gatekeeper does not support D-H Diffie-Hellman or security strategy not to allow to use the D-H Diffie-Hellman, then produce shared secret by called gatekeeper, after this shared secret encrypted, put into the CTg.h235Key.secureSharedSecret field of LCF message with encryption parameter; Simultaneously, after called gatekeeper produced shared secret and encrypts, another that put into LCF message with encryption parameter was used for called end point ClearToken.
6. method according to claim 4, it is characterized in that: in the described step (3), if calling endpoint is not supported the D-H Diffie-Hellman, but the security strategy of supporting D-H Diffie-Hellman and GkH between caller gatekeeper and the called gatekeeper allows to use the D-H Diffie-Hellman, then generate the D-H PKI by called gatekeeper, with the D-H PKI of caller gatekeeper in the LRQ together, use the D-H Diffie-Hellman to calculate the shared secret of session, this shared secret generates the ClearToken that the D-H PKI is put into LCF message with encryption parameter and called gatekeeper after encrypting; Simultaneously, after the shared secret that calculates was encrypted, another that put into LCF message with encryption parameter was used for called end point ClearToken.
7. method according to claim 5, it is characterized in that: in the described step (4), the caller gatekeeper checks and receives LCF, if produce shared secret by called gatekeeper, then with the shared secret deciphering of encrypting among this LCF, encrypt again, and be saved in the CTA.h235Key.secureSharedSecret field of ClearToken of ACF with encryption parameter; To be used for called end point ClearToken simultaneously and copy to ACF.
8. method according to claim 6, it is characterized in that: in the described step (4), the caller gatekeeper checks and receives LCF, if use the D-H Diffie-Hellman to generate session key by caller gatekeeper and called gatekeeper, from the ClearToken of LCF, obtain called gatekeeper's D-H PKI, the D-H PKI of preserving with the caller gatekeeper together uses the D-H Diffie-Hellman to calculate shared secret, and this shared secret is saved among the ClearToken of ACF with encryption parameter after encrypting; To be used for called end point ClearToken simultaneously and copy to ACF.
9. method according to claim 3 is characterized in that: in the described step (5), the ACF that the calling endpoint inspection is received obtains session key according to the ClearToken information among the ACF and calling endpoint and caller gatekeeper's shared secret key decryption.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNA2006101622799A CN101207477A (en) | 2006-12-19 | 2006-12-19 | Method for multi-network guard end-to-end conversation cryptographic key negotiation of striding field |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNA2006101622799A CN101207477A (en) | 2006-12-19 | 2006-12-19 | Method for multi-network guard end-to-end conversation cryptographic key negotiation of striding field |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN101207477A true CN101207477A (en) | 2008-06-25 |
Family
ID=39567388
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNA2006101622799A Withdrawn CN101207477A (en) | 2006-12-19 | 2006-12-19 | Method for multi-network guard end-to-end conversation cryptographic key negotiation of striding field |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101207477A (en) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101959189A (en) * | 2010-09-21 | 2011-01-26 | 中兴通讯股份有限公司 | Method and system for managing access password and basic key |
| CN103685181A (en) * | 2012-09-13 | 2014-03-26 | 北京大唐高鸿软件技术有限公司 | Key negotiation method based on SRTP |
| CN105848140A (en) * | 2016-03-17 | 2016-08-10 | 西安电子科技大学 | Safe end-to-end establishment method capable of achieving communication supervision in 5G network |
| CN107872462A (en) * | 2017-11-22 | 2018-04-03 | 苏州科达科技股份有限公司 | Conference call method and device |
| CN108541367A (en) * | 2015-06-09 | 2018-09-14 | 英特尔公司 | For using the service of congregation and multiple key-distribution servers to carry out the systems, devices and methods of secure network bridge joint |
| CN111630882A (en) * | 2018-01-19 | 2020-09-04 | 奥兰治 | Method for determining a key for protecting a communication between a user equipment and an application server |
-
2006
- 2006-12-19 CN CNA2006101622799A patent/CN101207477A/en not_active Withdrawn
Cited By (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101959189A (en) * | 2010-09-21 | 2011-01-26 | 中兴通讯股份有限公司 | Method and system for managing access password and basic key |
| CN103685181A (en) * | 2012-09-13 | 2014-03-26 | 北京大唐高鸿软件技术有限公司 | Key negotiation method based on SRTP |
| CN108541367A (en) * | 2015-06-09 | 2018-09-14 | 英特尔公司 | For using the service of congregation and multiple key-distribution servers to carry out the systems, devices and methods of secure network bridge joint |
| CN108541367B (en) * | 2015-06-09 | 2021-09-14 | 英特尔公司 | System, apparatus and method for secure network bridging using a rendezvous service and multiple key distribution servers |
| CN105848140A (en) * | 2016-03-17 | 2016-08-10 | 西安电子科技大学 | Safe end-to-end establishment method capable of achieving communication supervision in 5G network |
| CN105848140B (en) * | 2016-03-17 | 2019-03-15 | 西安电子科技大学 | It can be realized the End-to-End Security method for building up of communication supervision in a kind of 5G network |
| CN107872462A (en) * | 2017-11-22 | 2018-04-03 | 苏州科达科技股份有限公司 | Conference call method and device |
| CN107872462B (en) * | 2017-11-22 | 2021-02-26 | 苏州科达科技股份有限公司 | Video conference calling method and device |
| CN111630882A (en) * | 2018-01-19 | 2020-09-04 | 奥兰治 | Method for determining a key for protecting a communication between a user equipment and an application server |
| CN111630882B (en) * | 2018-01-19 | 2024-01-23 | 奥兰治 | User equipment, authentication server, medium, and method and system for determining key |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN100592731C (en) | Lawful interception of end-to-end encrypted data traffic | |
| US8533462B2 (en) | Verifying cryptographic identity during media session initialization | |
| US8850203B2 (en) | Secure key management in multimedia communication system | |
| US9049024B2 (en) | Secure key management in conferencing system | |
| US9106410B2 (en) | Identity based authenticated key agreement protocol | |
| KR101501399B1 (en) | Policy routing-based lawful interception in communication system with end-to-end encryption | |
| CN101232368B (en) | Method for distributing media stream cryptographic key and multimedia subsystem | |
| US20140169563A1 (en) | Method for ensuring media stream security in ip multimedia sub-system | |
| EP2426852B1 (en) | Method and system for implementing secure forking calling session in ip multi-media subsystem | |
| Asokan | Anonymity in a mobile computing environment | |
| CN103493427A (en) | Discovery of security associations | |
| CN101420413A (en) | Session cipher negotiating method, network system, authentication server and network appliance | |
| CN101207477A (en) | Method for multi-network guard end-to-end conversation cryptographic key negotiation of striding field | |
| CN101273571B (en) | Implementing method for field-crossing multi-network packet network cryptographic key negotiation safety strategy | |
| CN101207480A (en) | Method for multi-network guard end-to-end conversation cryptographic key negotiation of striding field | |
| CN100382484C (en) | Conversation key distribution method of crossing gate-guard management range under divect route mode | |
| CN112019553B (en) | Data sharing method based on IBE/IBBE | |
| CN101207478B (en) | Method for key agreement of guard end-to-end conversation in cross-domain multi-network | |
| CN100583733C (en) | Method for realizing safety of media flow and communication system | |
| CN1323509C (en) | Conversation key distribution method of crossing gate-guard management range under direct route mode | |
| CN101174944A (en) | Conversation key distribution method across-gatekeeper control limit under direct routing mode | |
| Saninas et al. | PRIVATE AND ANONYMOUS AUTHENTICATION IN MOBILE NETWORKS |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C04 | Withdrawal of patent application after publication (patent law 2001) | ||
| WW01 | Invention patent application withdrawn after publication |