CN101207478B - 一种跨域多网守端到端会话密钥协商方法 - Google Patents
一种跨域多网守端到端会话密钥协商方法 Download PDFInfo
- Publication number
- CN101207478B CN101207478B CN2006101678455A CN200610167845A CN101207478B CN 101207478 B CN101207478 B CN 101207478B CN 2006101678455 A CN2006101678455 A CN 2006101678455A CN 200610167845 A CN200610167845 A CN 200610167845A CN 101207478 B CN101207478 B CN 101207478B
- Authority
- CN
- China
- Prior art keywords
- gatekeeper
- called
- hellman
- diffie
- cleartoken
- 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.)
- Expired - Fee Related
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种跨域多网守端到端会话密钥协商方法,该方法通过ARQ/ACF,LRQ/LCF信令执行流程,基于端点与网守是否支持D-H密钥交换算法及安全策略,动态协商出一种端到端通信中最优的密钥协商方法,包括:由被叫网守产生共享秘密,主叫网守及主叫端点根据该共享秘密得到会话密钥;由主叫网守和被叫网守使用D-H密钥交换算法生成会话密钥;由主叫端点与被叫网守使用D-H密钥交换算法生成会话密钥。并据此完成端点之间的共享秘密或会话密钥的生成与交换,克服了目前跨域多网守端到端呼叫模式下,密钥协商方法是基于预先配置而带来的效率不高,互联互通性差的限制。
Description
技术领域
本发明涉及分组网络通信安全领域,尤其涉及一种跨域多网守直接路由呼叫模式下端到端通信会话密钥协商方法。
背景技术
在基于分组网络通信安全领域,密钥是最为重要的,在网络上H.323端点之间通过密钥交换所得到的共享或会话密钥可以对RAS(注册、接入与状态)信令、呼叫信令、H.245控制信令等实施身份证实,信令消息完整性检查以及对媒体数据流进行加/解密等安全措施。
目前,多网守路由模式下共享或会话密钥交换方法,基本采用的是预配置以及电话、E-Mail等带外方法。
直接路由呼叫(以下简称DRC)模式是H.323基于分组的多媒体通信***中呼叫建立的一个重要方法。由于DRC模式下,不能假定二个端点之间的拥有一个预共享秘密或会话密钥(共享秘密与用户标识、口令及随机数等信息一起,通过散列算法可生成会话密钥),因此,以上所使用方法要么难于难布署,要么不安全而无法在实际中应用。
H.235标准定义了一种基于H.323协议集,实现通信安全方法,包括Diffie-Hellman(迪福-海尔曼,简称D-H)公钥密码密钥交换协议,随机数生成共享秘密并由对称密码进行加密保护的密钥生成与交换方法。但并没有提出一种跨域多网守的端到端密钥协商及交换技术,也没有考虑到充分利用端点与网守的处理能力,及具有不同密钥协商能力的终端如何动态协商出一种双方都支持的密码方法。特别是在H.323多网守环境直接路由呼叫模式下,现存终端设备具备多种建立会话密钥方法,而通信的二端点之间又不可能事先能预配置的情况下,给互联互通通信安全带来困难。
发明内容
本发明要解决的技术问题就是提供一种跨域多网守端到端会话密钥协商方法,克服目前跨域多网守端到端呼叫模式下,密钥协商方法是基于预先配置而带来的效率不高,互联互通性差的限制。
为了解决上述技术问题,本发明提供一种跨域多网守端到端会话密钥协商方法,包括如下步骤:
(1)在主叫端点使用直接路由呼叫DRC呼叫被叫端点之前,主叫端点根据自身能力和安全策略,选择是否支持D-H密钥交换算法,并将该信息放入呼叫接入请求ARQ消息中,发送给其所归属的网守,该网守为主叫网守;
(2)主叫网守收到ARQ后,向被叫网守发起定位请求LRQ消息,以查询被叫端点地址;该LRQ消息中,主叫网守根据主叫端点及自身能力及安全策略,选择是否支持D-H密钥交换算法,从而为主叫端点选出一种生成会话密钥的方法;
(3)被叫网守收到LRQ后,根据主叫端点、主叫网守的选择,以及被叫网守是否支持D-H密钥交换算法和安全策略,最终确定生成会话密钥的方法,并将该信息及根据该方法生成的共享秘密放入定位确认LCF消息中,用于主叫端点与被叫端点之间的通信,将LCF发送给主叫网守;
(4)主叫网守收到LCF消息后,根据已确定的生成会话密钥的方法,对用于主叫端点的共享秘密进行解密然后再加密转发或是直接转发该共享秘密,据此生成ACF消息发送给主叫端点;该ACF消息中还复制了LCF中用于被叫端点的共享秘密;
(5)主叫端点收到ACF消息后,根据已确定的密钥方法,提取与被叫端点所共享的秘密,进而得到会话密钥。
进一步地,生成会话密钥的方法包括:
(a)由被叫网守产生共享秘密,主叫网守及主叫端点根据该共享秘密得到会话密钥;
(b)由主叫网守和被叫网守使用D-H密钥交换算法生成会话密钥;
(c)由主叫端点与被叫网守使用D-H密钥交换算法生成会话密钥。
进一步地,所述ARQ、LRQ、LCF、ACF均包含明文标记ClearToken,ClearToken中的tokenOID用于表示主叫端点、主叫网守、被叫网守是否支持D-H密钥交换算法,或者用于表示该ClearToken包含共享秘密,交给主叫端点或被叫端点使用。
进一步地,所述步骤(1)中,若选择由主叫端点与被叫网守使用D-H密钥交换算法生成会话密钥,则将其D-H公钥放在ClearToken中的dhkey域中。
进一步地,所述步骤(2)中,若主叫端点不支持D-H密钥交换算法,而主叫网守支持D-H密钥交换算法,选择由主叫网守和被叫网守使用D-H密钥交换算法生成会话密钥,主叫网守产生D-H公钥,并将该公钥存入LRQ中ClearToken中的dhkey域。
进一步地,所述步骤(2)中,若由主叫端点与被叫网守使用D-H密钥交换算法生成会话密钥,则将主叫端点发送的ARQ的ClearToken复制到LRQ的ClearToken中。
进一步地,所述步骤(3)中,若主叫端点与主叫网守都不支持D-H密钥交换算法,或者被叫网守不支持D-H密钥交换算法或安全策略不允许使用D-H密钥交换算法,则由被叫网守产生共享秘密,将该共享秘密加密后,与加密参数一起放入LCF消息的CTg.h235Key.secureSharedSecret字段中;同时,被叫网守产生共享秘密加密后,与加密参数一起放入LCF消息的另一个用于被叫端点ClearToken中。
进一步地,所述步骤(3)中,若主叫端点不支持D-H密钥交换算法,但主叫网守与被叫网守之间支持D-H密钥交换算法且被叫网守的安全策略允许使用D-H密钥交换算法,则由被叫网守生成D-H公钥,和LRQ内主叫网守的D-H公钥一起,使用D-H密钥交换算法计算出会话的共享秘密,该共享秘密加密后,与加密参数和被叫网守生成D-H公钥一起放入LCF消息的ClearToken中;同时,计算出的共享秘密加密后,与加密参数一起放入LCF消息的另一个用于被叫端点ClearToken中。
进一步地,所述步骤(3)中,主叫端点选择使用D-H密钥交换算法,且被叫网守的安全策略允许使用D-H密钥交换算法,则被叫网守生成的D-H公钥,与从LRQ中获取的公钥一起,使用D-H密钥交换算法计算出共享秘密,该共享秘密加密后,与加密参数和被叫网守生成D-H公钥一起放入LCF消息的ClearToken中;同时,计算出的共享秘密加密后,与加密参数一起放入LCF消息的另一个用于被叫端点ClearToken中。
进一步地,所述步骤(4)中,主叫网守检查收到LCF,若由被叫网守产生共享秘密,则将该LCF中加密的共享秘密解密,再进行加密,并与加密参数一起保存到ACF的ClearToken的CTA.h235Key.secureSharedSecret字段中;同时将用于被叫端点ClearToken复制到ACF中。
进一步地,所述步骤(4)中,主叫网守检查收到LCF,若是由主叫网守和被叫网守使用D-H密钥交换算法生成会话密钥,从LCF的ClearToken中获得被叫网守的D-H公钥,与主叫网守保存的D-H公钥一同使用D-H密钥交换算法计算出共享秘密,该共享秘密加密后,与加密参数一起保存到ACF的ClearToken中;同时将用于被叫端点ClearToken复制到ACF中。
进一步地,所述步骤(4)中,主叫网守检查收到LCF,若是由主叫端点与被叫网守使用D-H密钥交换算法生成会话密钥,则直接将LCF中所有的ClearToken复制到ACF的ClearToken中。
进一步地,所述步骤(5)中,主叫端点检查收到的ACF,若由主叫端点与被叫网守使用D-H密钥交换算法生成会话密钥,则从ACF的ClearToken中获得被叫网守的D-H公钥,与主叫端点保存的D-H公钥一同使用D-H密钥交换算法计算出会话密钥。
进一步地,所述步骤(5)中,主叫端点检查收到的ACF,若被叫网守产生共享秘密,或由主叫网守和被叫网守使用D-H密钥交换算法生成会话密钥,则根据ACF中的ClearToken信息和主叫端点与主叫网守的共享密钥解密得到会话密钥。
通过上述步骤,通信双方(端点)可协商出一个可信的动态会话密钥,利用密码学将其与呼叫认证捆绑在一起,包括呼叫控制信道中会话密钥刷新需求。
本发明的优点有:
1.通过动态适配终端与网守的安全能力,可提高密钥交换的效率,减少延时及网守的处理负荷,同时在实施安全通信过程中,增加了不同安全能力终端互联互通的灵活性。
2.借助于ARQ/ACF,LRQ/LCF信令执行流程,基于端点与网守是否支持公钥密码及对称密码算法,动态协商出一种端到端通信中最优的密钥协商方法,并以此方法完成端点之间的共享秘密或会话密钥的生成与交换,为后续呼叫信令建立起安全关系,防止信令及数据消息被伪造、完整性及可能的机密性丢失。
3.采用的安全技术与现有标准相容,安全体系的布置也比较简单,并且不需要假定任何附加的安全基础设施方法。
随着大规模H.323多媒体通信***的布署与应用,如全球范围的VoIP网或国家范围面向公众的视频会议/可视电话***等,在这种多运营商、跨多个管理域分层多网守DRC环境下,使用本发明提供的方法更为方便实用。
4.本发明方法也可以应用到其它多网守呼叫模式,如部分/路由方式,直接/路由,路由/直接方式及网守路由方式等。
附图说明
图1为多网守直接路由呼叫模式场景;
图2为多网守直接路由呼叫模式下共享秘密协商流程图。
具体实施方式
下面结合附图及具体实施例对本发明进行详细说明。
为说明本发明方法,引用下列符号来表示端点与网守的能力或二者组合,或者用来区分主叫/被叫端点所保存的共享秘密。
符号 | 表示的意义 |
″I0″ | 表明主叫端点不支持D-H,主叫网守或被叫网守不支持D-H密钥交换算法。 |
[0041]
″I1″ | 交给主叫端点的立ClearToken中使用,表明此ClearToken中包含共享秘密。 |
″I2″ | 交给被叫端点的独立ClearToken中使用,表明此ClearToken中包含共享秘密。 |
″I3″ | 表明主叫端点不支持G-H过程,但主叫与被叫网守支持D-H密钥交换算法。 |
″I4″ | 表示主叫端点支持D-H密钥交换算法,被叫网守支持D-H密钥交换算法 |
本发明实施例,采用H.323***跨网守管理范围的直接路由模式,并假定主/被叫端点分别注册在不同的主/被叫网守上,通讯过程是在没有安全性保证的IP网络上进行。使用的场景如图1所示。
图1为多网守直接路由模式下的通信场景图。图中的网守云包括一个或多个网守,端点可以连接到相同或不同的网守。直接路由呼叫模型中,网守不参于H.225.0呼叫控制信令,因此不在H.225.0中执行信令隧道。这样,网守不影响两个支持信令隧道的端点之间的隧道。直接路由呼叫模型中,H.245控制信道只能直接在端点之间连接。基于H.245控制信道,完成实时数据流传输协议(RTP)。
在图1所示的通信过程中,首先,在RAS信道上,端点与网守交换接入消息,然后在呼叫信令信道上交换呼叫信令,然后是H.245控制信道的建立。网守对接入消息的响应决定了是否使用直接路由呼叫模式。虽然端点可以指定优选项,但模式选择不受端点控制。
本发明实施例中,网守对其管理端点的所有RAS消息进行认证与完整性检查,端点对也对网守的RAS消息进行认证与完整性检查,从而使端点和所属网守之间达到相互信任目的,以便能检查出欺诈的实体,并将被欺诈可能性降到最小。中间网云中网守与网守之间也进行相互鉴别,避免网守域间的恶意攻击。在上述条件下,能够保证H.323端点之间RAS信道的安全性,以此为基础可实现呼叫信令的安全性。
本发明实施例中,方法1表示由被叫网守产生共享秘密,进而可以生成会话密钥;方法2表示由主叫网守和被叫网守使用D-H密钥交换算法生成会话密钥;方法3表示由主叫端点与被叫网守使用D-H密钥交换算法生成会话密钥。
下面结合图2动态决策流程图,根据RAS信令与呼叫信令的逻辑顺序来说明本发明三种方法是如何依据安全策略动态协商出来,以共同支持端点之间进行密钥协商。
1.ARQ请求阶段:
主叫端点EpA在使用直接路由呼叫模式呼叫被叫端点EpB之前,EpA向归属GkG发送ARQ消息,消息中中包含一个独立的ClearToken,假设为CTA,其中tokenOID根据是否支持D-H而采用不同的设置,这可由用户根据终端能力与安全策略来设定。如果希望由GK代为生成安全共享秘密,给出一个标识“I0”,其他字段不使用;如果EpA希望采用D-H与被叫网守协商共享秘密,则将其D-H公钥放在的dhkey域中,对tokenOID设定一个相关标识“I4”,其他字段不使用。
2.LRQ请求阶段:
GkG在收到EpA发来的ARQ后,判断出不属于同一管理域,发起LRQ消息向GkH查询EpB的地址。LRQ消息包含一个ClearToken,其内部各子域的设置规则由EpA能力与GkG所采用具体密钥协商规程而定,具体设置如下:
当ARQ中的ClearToken的tokenOID为”I0”时,如果主叫网守不支持D-H密钥交换与协商,这时GkG生成LRQ(图2数字1),包含一个ClearToken,其中tokenOID设置为”I0”,ClearToken的其他字段不使用,这些设置说明要采用方法1进行密钥协商,即需要被叫GK分配共享秘密,假设为Kab。
当ARQ中的ClearToken的tokenOID为”I0”时,GkG生成LRQ,如果主/被叫网守支持D-H密钥交换算法,则包含一个ClearToken,其中tokenOID设置一个标识符,如“I3”,表明期望与被叫GK使用D-H密钥交换算法为二边端点协商出会话的共享秘密。(图2数字4)GkG产生并设置ClearToken中的dhkey作为D-H公钥。
当ARQ中的ClearToken的tokenOID为“I4”,应根据安全策略可以选择使用方法3的过程。GkG生成LRQ(图2数字9),其中包含从ARQ复制过来的ClearToken。
3.LCF确认
GkH收到LRQ后并识别出EpA与EpB支持这种呼叫模式,根据所含ClearToken的tokenOID执行不同密钥协商过程来生成基于呼叫的共享秘密(基于该共享秘密,以后通信时生成会话密钥)Kab与二个独立的ClearToken。一个用于主叫网守Gkg,假定称为CTg;另一个用于被叫端点EpB,假定称为CTb。这个Kab然后通过使用CTg与CTB将分别推送到GkG与EpB。
根据tokenOID的不同值,返回不同方法的LCF具体做法如下:
3.1如果LRQ中的tokenOID为“I0”,表明采用方法1。
LRQ中的“I0”表明主叫端点与其归属网守都不支持D-H密钥交换算法,要求被叫网守为其生成共享秘密。(图2数字2)这种情形下,返回的LCF采用方法1,其具体设置过程如下:
GkH随机产生Kab。为了加密Kab,首先,GkH产生随机的challenge,并用和GkG之间的共享密钥Kgh和challenge以及事先配置的密钥推导算法导出一个密钥,如设为EKgh。然后,GkH用EKgh加密Kab得到一共享秘密,如设定为EKab1,并把EKab1和加密参数(加密算法和加密用初始化向量)一起,设置到CTg.h235Key.secureSharedSecret字段中,具体细节可参考H.235附录I,并设置CTg的tokenOID为“I0”。同时,GkH使用类似的过程产生另一个ClearToken,设置tokenOID为“I2”,称为CTb。最后,GkH生成LCF(图2数字2),其中包含CTg和CTb。
3.2如果LRQ中的tokenOID为“I3”,表明采用方法2或方法1。
LRQ中“I3”表明端点不支持D-H密钥交换算法,但网守之间期待支持D-H密钥交换算法且GkH的安全策略允许使用D-H密钥交换算法(图2数字4)。具体过程如下:
当GkH支持D-H密钥交换算法且安全能力相匹配,则GkH生成自己D-H公钥,并和LRQ内GkG的D-H公钥一起,使用D-H算法计算出会话共享秘密Kab。然后,使用与上面方法1类似过程生成CTb,tokenOID为“I2”。最后,GkH生成LCF(图2数字5),其中包含CTb和一个独立ClearToken(tokenOID为“I3”)CTg,其中有设置好期望的D-H公钥。
如果GkH不支持D-H算法或安全策略不允许使用D-H密钥交换算法,则GkH使用上述方法1过程生成LCF(图2数字7)。
3.3如果LRQ中tokenOID为“I4”,表明采用方法3或方法1。
LRQ中“I4”表示期待GkH支持D-H算法,如果GkH的安全策略允许使用D-H密钥交换算法,则GkH开始与EpA协商会话密钥(图2数字10-11)。具体过程如下:
首先,GkH生成期望的D-H公钥,与从LRQ中获取的公钥一起,使用D-H算法计算出共享秘密Kab。然后,使用与方法1的过程步骤生成CTb,tokenOID可设为“I2”表示。最后,GkH生成LCF,其中包含CTb和一个独立ClearToken(tokenOID可设为”I4”)CTg,其中有设置好期望的D-H公钥。
如果GkH不支持D-H算法或安全策略不允许使用D-H密钥交换算法,GkH可使用方法1过程来生成LCF。
4.ACF确认
GkG收到LCF后,检验消息中的CTg的tokenOID为“I3”(图2数字5)时,采用D-H密钥交换算法计算出Kab,产生CTa,其内tokenOID设为“I1”。具体做法是:从独立ClearToken中获得GkH的D-H公钥,与自己保存的D-H公钥一同使用D-H算法计算出共享秘密Kab;然后使用与下面相同方法生成CTa。最后,GkG生成ACF(图2数字6),其中包含CTa(tokenOID为”I1”)和从LCF复制过来的CTb(tokenOID为”I2”)。
如果CTg的tokenOID为“I0”(可能对应图2数字1,5,9三种情形,被叫不支持D-H所返回的标志)时,首先,GkG可通过CTg中的challenge、IV以及指定的密钥导出算法导出密钥Ekgh,或通过其它安全机制来导出;然后,GkG用EKgh解密EKab1得到Kab;最后产生CTa,其内tokenOID设为“I1”。CTa的生成做法如下:首先,GkG用GkG和EpA之间的共享秘密Kag和challenge以及指定的密钥导出算法导出密钥EKag。然后,GkG用EKag加密Kab得到EKab1,并把EKab1和加密参数(加密算法和加密用到的初始化向量)一起,设置到一个独立的CTA.h235Key.secureSharedSecret字段中。最后,GkG生成ACF(可能对应图2数字3,8,13三种情形之一,主叫或被叫不支持D-H所返回的标志),其中包含CTa和从LCF复制过来的CTb。
如果GkG收到的LCF消息中ClearToken的tokenOID为“I4”,则GkG生成ACF,其中包含从LCF中复制过来的所有ClearToken(对应图2数字10-11种情形)。
5.Setup
EpA收到ACF后,检验消息中独立ClearToken的tokenOID为“I4”,则判定为主叫端点与被叫网守,利用D-H算法计算会话密钥。做法是:
从ClearToken中获得被叫方的D-H公钥,与自己保存的D-H公钥一同使用D-H算法计算出共享秘密Kab,进而可以计算出会话密钥。
其它情况则直接提取CTa,并根据CTa中信息和其与GkG的共享密钥Kag导出密钥EKag,然后使用EKag解密CTa.h235Key.secureSharedSecret.encryptedSessionKey得到共享秘密Kab,进而可以计算出会话密钥。
EpA创建Setup消息,把ACF消息中的CTb复制到Setup消息中,然后利用会话密钥设置H235V3附录D/附录F的鉴权信息。EpA直接向EpB发出呼叫建立请求消息Setup。
6.后面的呼叫信令设置:
EpB收到Setup消息后,提取CTb,并根据CTb中信息和其与GkH的共享密钥Kbh导出密钥EKbh,然后使用EKbh解密CTb.h235Key.secureSharedSecret.encryptedSessionKey得到共享秘密Kab;此时,EpB就可以使用Kab对Setup及后续的呼叫信令消息进行鉴权。
通过以上ARQ,LRQ,LCF,ACF信令流的顺序执行流程中,依据主叫终,主叫网守与被叫网守是否具备D-H能力的8种状态,按照不同安全能力、优先级(方法1最低,方法3最高)及其它安全策略来共同实施在网守与网守或终端与网守之间如何动态协商出双方一致支持的密钥生成与交换方法,即方法1、方法2或方法3。
Claims (14)
1.一种跨域多网守端到端会话密钥协商方法,包括如下步骤:
(1)在主叫端点使用直接路由呼叫DRC呼叫被叫端点之前,主叫端点根据自身能力和安全策略,选择是否支持D-H密钥交换算法,并将该信息放入呼叫接入请求ARQ消息中,发送给其所归属的网守,该网守为主叫网守;
(2)主叫网守收到ARQ后,向被叫网守发起定位请求LRQ消息,以查询被叫端点地址;该LRQ消息中,主叫网守根据主叫端点及自身能力及安全策略,选择是否支持D-H密钥交换算法,从而为主叫端点选出一种生成会话密钥的方法;
(3)被叫网守收到LRQ后,根据主叫端点、主叫网守的选择,以及被叫网守是否支持D-H密钥交换算法和安全策略,最终确定生成会话密钥的方法,并将该信息及根据该方法生成的共享秘密放入定位确认LCF消息中,用于主叫端点与被叫端点之间的通信,将LCF发送给主叫网守;
(4)主叫网守收到LCF消息后,根据已确定的生成会话密钥的方法,对用于主叫端点的共享秘密进行解密然后再加密转发或是直接转发该共享秘密,据此生成ACF消息发送给主叫端点;该ACF消息中还复制了LCF中用于被叫端点的共享秘密;
(5)主叫端点收到ACF消息后,根据已确定的密钥方法,提取与被叫端点所共享的秘密,进而得到会话密钥。
2.根据权利要求1所述的方法,其特征在于:
生成会话密钥的方法包括:
(a)由被叫网守产生共享秘密,主叫网守及主叫端点根据该共享秘密得到会话密钥;
(b)由主叫网守和被叫网守使用D-H密钥交换算法生成会话密钥;
(c)由主叫端点与被叫网守使用D-H密钥交换算法生成会话密钥。
3.根据权利要求2所述的方法,其特征在于:所述ARQ、LRQ、LCF、ACF均包含明文标记ClearToken,ClearToken中的tokenOID用于表示主叫端点、主叫网守、被叫网守是否支持D-H密钥交换算法,或者用于表示该ClearToken包含共享秘密,交给主叫端点或被叫端点使用。
4.根据权利要求3所述的方法,其特征在于:所述步骤(1)中,若选择由主叫端点与被叫网守使用D-H密钥交换算法生成会话密钥,则将其D-H公钥放在ClearToken中的dhkey域中。
5.根据权利要求3所述的方法,其特征在于:所述步骤(2)中,若主叫端点不支持D-H密钥交换算法,而主叫网守支持D-H密钥交换算法,选择由主叫网守和被叫网守使用D-H密钥交换算法生成会话密钥,主叫网守产生D-H公钥,并将该公钥存入LRQ中ClearToken中的dhkey域。
6.根据权利要求4所述的方法,其特征在于:所述步骤(2)中,若由主叫端点与被叫网守使用D-H密钥交换算法生成会话密钥,则将主叫端点发送的ARQ的ClearToken复制到LRQ的ClearToken中。
7.根据权利要求3所述的方法,其特征在于:所述步骤(3)中,若主叫端点与主叫网守都不支持D-H密钥交换算法,或者被叫网守不支持D-H密钥交换算法或安全策略不允许使用D-H密钥交换算法,则由被叫网守产生共享秘密,将该共享秘密加密后,与加密参数一起放入LCF消息的CTg.h235Key.secureSharedSecret字段中;同时,被叫网守产生共享秘密加密后,与加密参数一起放入LCF消息的另一个用于被叫端点ClearToken中。
8.根据权利要求5所述的方法,其特征在于:所述步骤(3)中,若主叫端点不支持D-H密钥交换算法,但主叫网守与被叫网守之间支持D-H密钥交换算法且被叫网守的安全策略允许使用D-H密钥交换算法,则由被叫网守生成D-H公钥,和LRQ内主叫网守的D-H公钥一起,使用D-H密钥交换算法计算出会话的共享秘密,该共享秘密加密后,与加密参数和被叫网守生成D-H公钥一起放入LCF消息的ClearToken中;同时,计算出的共享秘密加密后,与加密参数一起放入LCF消息的另一个用于被叫端点ClearToken中。
9.根据权利要求6所述的方法,其特征在于:所述步骤(3)中,主叫端点选择使用D-H密钥交换算法,且被叫网守的安全策略允许使用D-H密钥交换算法,则被叫网守生成的D-H公钥,与从LRQ中获取的公钥一起,使用D-H密钥交换算法计算出共享秘密,该共享秘密加密后,与加密参数和被叫网守生成D-H公钥一起放入LCF消息的ClearToken中;同时,计算出的共享秘密加密后,与加密参数一起放入LCF消息的另一个用于被叫端点ClearToken中。
10.根据权利要求7所述的方法,其特征在于:所述步骤(4)中,主叫网守检查收到LCF,若由被叫网守产生共享秘密,则将该LCF中加密的共享秘密解密,再进行加密,并与加密参数一起保存到ACF的ClearToken的CTA.h235Key.secureSharedSecret字段中;同时将用于被叫端点ClearToken复制到ACF中。
11.根据权利要求8所述的方法,其特征在于:所述步骤(4)中,主叫网守检查收到LCF,若是由主叫网守和被叫网守使用D-H密钥交换算法生成会话密钥,从LCF的ClearToken中获得被叫网守的D-H公钥,与主叫网守保存的D-H公钥一同使用D-H密钥交换算法计算出共享秘密,该共享秘密加密后,与加密参数一起保存到ACF的ClearToken中;同时将用于被叫端点ClearToken复制到ACF中。
12.根据权利要求9所述的方法,其特征在于:所述步骤(4)中,主叫网守检查收到LCF,若是由主叫端点与被叫网守使用D-H密钥交换算法生成会话密钥,则直接将LCF中所有的ClearToken复制到ACF的ClearToken中。
13.根据权利要求12所述的方法,其特征在于:所述步骤(5)中,主叫端点检查收到的ACF,若由主叫端点与被叫网守使用D-H密钥交换算法生成会话密钥,则从ACF的ClearToken中获得被叫网守的D-H公钥,与主叫端点保存的D-H公钥一同使用D-H密钥交换算法计算出会话密钥。
14.根据权利要求3所述的方法,其特征在于:所述步骤(5)中,主叫端点检查收到的ACF,若被叫网守产生共享秘密,或由主叫网守和被叫网守使用D-H密钥交换算法生成会话密钥,则根据ACF中的ClearToken信息和主叫端点与主叫网守的共享密钥解密得到会话密钥。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2006101678455A CN101207478B (zh) | 2006-12-18 | 2006-12-18 | 一种跨域多网守端到端会话密钥协商方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2006101678455A CN101207478B (zh) | 2006-12-18 | 2006-12-18 | 一种跨域多网守端到端会话密钥协商方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101207478A CN101207478A (zh) | 2008-06-25 |
CN101207478B true CN101207478B (zh) | 2010-07-14 |
Family
ID=39567389
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2006101678455A Expired - Fee Related CN101207478B (zh) | 2006-12-18 | 2006-12-18 | 一种跨域多网守端到端会话密钥协商方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101207478B (zh) |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1691583A (zh) * | 2004-04-26 | 2005-11-02 | 华为技术有限公司 | 基于端点之间的安全通信方法 |
CN1777094A (zh) * | 2004-11-15 | 2006-05-24 | 中兴通讯股份有限公司 | 通用引导体系中密钥重协商的触发方法 |
-
2006
- 2006-12-18 CN CN2006101678455A patent/CN101207478B/zh not_active Expired - Fee Related
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1691583A (zh) * | 2004-04-26 | 2005-11-02 | 华为技术有限公司 | 基于端点之间的安全通信方法 |
CN1777094A (zh) * | 2004-11-15 | 2006-05-24 | 中兴通讯股份有限公司 | 通用引导体系中密钥重协商的触发方法 |
Also Published As
Publication number | Publication date |
---|---|
CN101207478A (zh) | 2008-06-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN100592731C (zh) | 端到端加密数据电信的合法侦听 | |
US8850203B2 (en) | Secure key management in multimedia communication system | |
US8301883B2 (en) | Secure key management in conferencing system | |
US8533462B2 (en) | Verifying cryptographic identity during media session initialization | |
US9167422B2 (en) | Method for ensuring media stream security in IP multimedia sub-system | |
KR101501399B1 (ko) | 종단간 암호화를 갖는 통신 시스템에서의 정책 라우팅 기반 합법적 인터셉션 | |
CN101420413B (zh) | 会话密钥协商方法、认证服务器及网络设备 | |
US20100211779A1 (en) | Identity Based Authenticated Key Agreement Protocol | |
EP2426852B1 (en) | Method and system for implementing secure forking calling session in ip multi-media subsystem | |
Asokan | Anonymity in a mobile computing environment | |
CN103493427A (zh) | 安全关联的发现 | |
CN103534975A (zh) | 根据公开密钥发现用于密钥管理的安全关联 | |
JP2012533218A (ja) | 効率的鍵管理システムおよび方法 | |
CN101232368A (zh) | 一种分配媒体流密钥的方法和多媒体子*** | |
WO2007073659A1 (fr) | Methode d'acces des terminaux a base de protocole h.323 applique a un reseau de paquets | |
CN101207477A (zh) | 一种跨域多网守端到端会话密钥协商方法 | |
CN101273571B (zh) | 跨域多网守分组网络密钥协商安全策略的实现方法 | |
CN101207480A (zh) | 一种跨域多网守端到端会话密钥协商方法 | |
CN100382484C (zh) | 一种直接路由模式下跨关守管理范围的会话密钥分配方法 | |
CN112019553B (zh) | 一种基于ibe/ibbe数据共享方法 | |
CN101207478B (zh) | 一种跨域多网守端到端会话密钥协商方法 | |
CN1323509C (zh) | 一种直接路由模式下跨关守管理范围的会话密钥分配方法 | |
CN110933673B (zh) | 一种ims网络的接入认证方法 | |
CN101174944A (zh) | 一种直接路由模式下跨关守管理范围的会话密钥分配方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20100714 Termination date: 20151218 |
|
EXPY | Termination of patent right or utility model |