CN1815950A - 一种直接路由模式下跨关守管理范围的会话密钥分配方法 - Google Patents
一种直接路由模式下跨关守管理范围的会话密钥分配方法 Download PDFInfo
- Publication number
- CN1815950A CN1815950A CNA2005100053974A CN200510005397A CN1815950A CN 1815950 A CN1815950 A CN 1815950A CN A2005100053974 A CNA2005100053974 A CN A2005100053974A CN 200510005397 A CN200510005397 A CN 200510005397A CN 1815950 A CN1815950 A CN 1815950A
- Authority
- CN
- China
- Prior art keywords
- session key
- node
- ownership
- message
- calling
- 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.)
- Granted
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/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
- H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
-
- 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
- H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
-
- 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/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
- H04L65/1106—Call signalling protocols; H.323 and related
-
- 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
-
- 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
- H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Security & Cryptography (AREA)
- Signal Processing (AREA)
- General Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- Multimedia (AREA)
- General Business, Economics & Management (AREA)
- Business, Economics & Management (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
- Telephonic Communication Services (AREA)
Abstract
本发明提供一种直接路由模式下跨关守管理范围的会话密钥分配方法,其核心为:主/被叫节点的归属关守根据接收的消息中承载的信息、预先设置的选择会话密钥分配方式的预定规则确定主/被叫方会话密钥分配方式,并为主、被叫节点分配会话密钥。本发明的主被叫节点的归属关守能够根据网络的具体情况灵活选择主被叫节点间的会话密钥分配方法;从而实现了提高归属关守分配会话密钥的灵活性、使消息传输的安全等级与消息传输时延取得平衡的目的。
Description
技术领域
本发明涉及网络通讯技术领域,具体涉及一种直接路由模式下跨关守管理范围的会话密钥分配方法。
背景技术
H323***是基于无QOS(服务质量)保证的PBN(分组网络)实现的。由于PBN本身的技术原因,使PBN不能够提供QOS,也不能提供安全的服务。在H323***中,如何提供适时安全的服务是非常重要。
H235协议V3版以前的版本描述了一些用于H323***的鉴别和保密技术,但都是假定在GK(关守)路由模式情况下的技术方案。H235协议V3版的附录I提出了一种直接路由的安全方案,这种方案主要利用H235V3附录D和附录F的基本特性,提供H323***通信的安全服务,但是限制在一个GK管理范围内。
在实际的网络环境中,H323***通常会包括两个或多个GK,H323***包括两个GK的组网逻辑框图如附图1所示。
图1中,虚线表示H225协议中的RAS消息传输,实线表示H225协议中Q931消息传输。EPa和EPb表示两个不同的H323节点,GKg和GKh表示两个不同的GK。GKg是EPa的归属GK,GKh是EPb的归属GK。
当H323***包括两个或多个GK时,通常会通过呼叫前的预约机制,使主叫节点EPa和GKg之间有共享密钥Kag,被叫节点EPb和GKh之间有共享密钥Kbh,GKg和GKh之间有共享密钥Kgh,以确保RAS消息的可靠传输。
当EPa和Epb之间采用直接路由模式进行呼叫时,为保证Q931消息的可靠传输,双方需要通过RAS消息的可靠传输来获取EPa和Epb之间直接传输Q931消息的会话密钥。
目前,主被叫节点会话密钥的分配方法主要有两种:
方法一、基于被叫节点的归属关守产生会话密钥的密钥分配方式。
具体实现过程为:图1中,主叫节点EPa向GKg发送ARQ(呼叫接入请求)消息,ARQ消息中携带了一个ClearToken(明文标记),这个ClearToken中的tokenOID设置为″I0″表明EPa支持H235V3附录I。
GKg在接收到EPa发来的ARQ消息后,根据ARQ消息承载的destinationInfo或者destCallSignalAddress字段确定被叫节点为Epb,由于Epb不属于其管辖,所以,GKg发起LRQ(定位请求)消息向GKh查询EPb的地址。LRQ消息中的endpointIdentifier为主叫节点EPa的节点ID(标识符)。
GKg在转化ARQ消息时,如果发现消息中ClearToken的tokenOID为″I0″,则确定EPa支持H235V3附录I功能,于是在LRQ消息中也生成一个ClearToken,其中的tokenOID也为″I0″。如果GKg不支持附录I,就不需要在LRQ消息中创建tokenOID为″I0″的ClearToken,且消息的后续处理按照不支持附录I的普通方式进行消息交互。
GKh在接收到LRQ消息后,检查消息的ClearToken中的tokenOID是否为″I0″,如果tokenOID为″I0″,表明对端支持附录I。如果GKh自己也支持附录I,就根据LRQ提供的被叫节点信息,查询被叫节点EPb是否支持附录I。
GKh生成EPa和EPb之间的共享密钥Kab,且产生随机的challenge,并用GKh和GKg之间的共享密钥Kgh和challenge以及指定密钥导出算法导出密钥EKgh,然后用EKgh加密Kab得到EKab1,并将EKab1和加密参数配置到一个独立的ClearToken.h235Key.secureSharedSecret字段的对应子字段中。
如果LRQ消息中设置了endpointIdentifier,GKh需要把这个字段也设置到ClearToken.h235Key.secureSharedSecret.generalID字段中,并将导出密钥时用到的算法配置到ClearToken.h235Key.secureSharedSecret.keyDerivationOID字段,将导出密钥时用到的challenge设置到ClearToken.challenge字段,同时将ClearToken.generalID设置为GKg的节点ID,ClearToken.senderID设置为GKh的节点ID,最后把ClearToken的tokenOID设置为″I3″,在后文中把这个ClearToken记为CTg。
GKh用GKh和EPb之间的共享密钥Kbh和另外的challenge一起导出密钥EKbh,并用EKbh加密Kab得到EKab2,并把加密结果EKab2和加密参数如加密算法和加密时用到的初始化向量等一起设置到另外一个ClearToken的h235Key.secureSharedSecret字段中。
如果LRQ消息中设置了endpointIdentifier,GKh还需要把这个字段也设置到ClearToken.h235Key.secureSharedSecret.generalID字段中,将导出密钥时用到的challenge设置到ClearToken.challenge字段,ClearToken.generalID设置为EPb的节点ID,ClearToken.senderID设置为GKh的节点ID,最后把这个ClearToken的tokenOID设置为″I2″,在后文中,把这个ClearToken记为CTb。
在进行了上述设置后,GKh把LCF消息发给GKg。
GKg接收到GKh发来的LCF消息后,取出独立的ClearToken信息,如果LCF消息中有两个以上的ClearToken,且其中一个ClearToken的tokenOID为″I3″,即CTg,另外一个ClearToken的tokenOID为″I2″,即CTb,则表明GKh、EPb同意使用附录I的安全方案。
GKg构造ACF(呼叫接入确认)消息,创建一个ClearToken,其中的tokenOID设置为″I1″,选取一个随机的challenge设置到CTa.challenge中,利用CTg提供的参数如challenge、密钥导出算法、加密算法、加密用到的初始化向量等和利用challenge和Kgh导出的密钥Ekgh,解密
CT3.h235Key.secureSharedSecret.encryptedSessionKey得到密钥Kab,GKg根据Kag和CTa.challenge导出密钥EKag,用EKag加密Kab并把加密结果和加密参数设置到CTa.h235Key.secureSharedSecret中的对应子字段中,把CTb.generalID复制到CTa.h235Key.secureSharedSecret.generalID,把CTb复制到ACF消息中,最后,将ACF消息发给节点EPa。
Epa接收到ACF消息后,提取CTa和CTb,并根据CTa中的信息和利用EPa与GKg的共享密钥Kag导出的密钥EKag解密CTa.h235Key.secureSharedSecret.encryptedSessionKey得到密钥Kab。
Epa在获得会话密钥Kab后,即可以利用该密钥创建Setup消息,将ACF消息中的CTb复制到Setup消息中,然后利用共享密钥Kab设置H235V3附录D方案的鉴权信息,EPa直接向Epb发送Setup消息。
Epb接收到Setup消息后,提取CTb,根据CTb.genralID和CTb.sendersID以及CTb.challenge信息利用Kbh导出密钥EKbh,并解密CTb.h235Key.secureSharedSecret.encryptedSessionKey得到密钥Kab。
EPb根据Kab对Setup消息进行鉴权,并进行后续的Q931消息传输。
在该方法中,主叫节点、被叫节点之间的会话密钥Kab在GK的每一跳都要进行加密、解密过程,当GK级数较多时,会增加消息传输时延,而且会话密钥只由被叫节点的归属关守产生,不能提供端到端的安全服务。
方法二、基于主叫节点与被叫节点的归属关守之间进行DH协商的会话密钥分配方式。
具体实现过程为:图1中,主叫节点Epa向GKg发送ARQ消息时,在ARQ消息中设置独立的ClearToken,其中的tokenOID为″I0″,EPa产生用于DH协商的公开密钥,并设置在ClearToken.dhkey中,EPa将ARQ消息传输至其所归属的GKg。
支持附录I的GKg接收到ARQ消息后,查询被叫节点Epb,由于EPb不在其管理范围内,于是GKg发起LRQ消息到GKh,LRQ消息中携带独立的ClearToken,其中tokenOID字段为″I0″,且dhkey字段的内容与ARQ消息的dhkey字段中的内容一样。
GKg接收到LRQ消息后,根据LRQ中的ClearToken.tokenOID和被叫的Pb确定主、被叫节点都支持附录I时,GKh创建一个ClearToken,设置tokenOID为″I2″,在后文中,将这个ClearToken记为CTb。
GKh产生DH协商的公钥,并与收到的LRQ消息中的DH公钥一起使用DH算法计算出节点间直接传输Q931消息的会话密钥Kab。
GKh产生一个随机的challenge,设置到CTb.challenge中,然后根据这个challenge和Kbh导出密钥EKbh和KSbh。GKh产生一个随机的初始化向量IV,分别设置到CTb.h235Key.securitySharedSecret.paramS.IV中。GKh把ENCEKbh, KSbh,IV(Kab)设置到CTb.h235Key.securitySharedSecret.encryptedSessionKey中。
GKh在LCF中包含GKh产生的DH公钥和CTb,向GKg发送LCF消息。
GKg接收到GKh发来的LCF消息后,获取CTb和dhkey信息,并将其复制到ACF消息中,将ACF消息发给节点EPa。
Epa接收到ACF消息后,根据消息中的dhkey获取DH公钥,并与自己的DH公钥一起通过DH算法计算出会话密钥Kab。
Epa在获得会话密钥Kab后,即可以利用该密钥创建Setup消息,将ACF消息中的CTb复制到Setup消息中,然后利用共享密钥Kab设置H235V3附录D方案的鉴权信息,Epa将Setup消息传输至Epb。
Epb接收到Setup消息后,提取CTb,并根据CTb.genralID和CTb.sendersID以及CTb.challenge信息利用Kbh导出密钥EKbh,解密CTb.h235Key.secureSharedSecret.encryptedSessionKey得到密钥Kab,EPb根据Kab对Setup消息进行鉴权。
该方法需要终端与GK都支持DH协商过程,其适用范围受到限制。
综上所述,现有的为主被叫节点分配会话密钥的方法不能够由关守选择,存在消息传输时延大、不能够提供端到端的安全服务、适用范围不广泛、会话密钥分配方法灵活性差等缺点。
发明内容
本发明的目的在于,提供一种直接路由模式下跨关守管理范围的会话密钥分配方法,使节点的归属关守能够选择会话密钥的分配方式,以实现提高关守分配会话密钥的灵活性、使消息传输的安全等级与消息传输时延取得平衡的目的。
为达到上述目的,本发明提供的一种直接路由模式下跨关守管理范围的会话密钥分配方法,包括:
主/被叫节点的归属关守根据接收的消息中承载的信息、预先设置的选择会话密钥分配方式的预定规则确定主/被叫方会话密钥分配方式,并为主、被叫节点分配会话密钥。
所述预定规则包括:主叫方预定规则、被叫方预定规则;
所述主叫方预定规则包括:关守的可用计算资源和/或主叫节点支持的会话密钥分配方式和/或主叫节点的安全级别;
所述被叫方预定规则包括:关守的可用计算资源和/或主叫方会话密钥分配方式和/或被叫节点的安全级别。
所述方法具体包括:
a、主叫节点将其支持的会话密钥分配方式承载于呼叫接入请求消息中传输至其归属的关守;
b、所述主叫节点的归属关守根据呼叫接入请求消息中承载的主叫节点支持的会话密钥分配方式信息、所述预定规则确定主叫方会话密钥分配方式,并将其承载于定位请求消息中传输至被叫节点的归属关守;
c、所述被叫节点的归属关守根据定位请求消息中承载的信息、所述预定规则确定被叫方会话密钥分配方式,并计算所述主被叫节点间的会话密钥,将被叫方会话密钥分配方式、所述会话密钥通过定位确认消息传输至主叫节点的归属关守;
d、所述主叫节点的归属关守根据定位确认消息中承载的信息、主叫节点支持的会话密钥分配方式确定会话密钥,并将所述会话密钥通过呼叫接入确认消息传输至所述主被叫节点。
所述步骤a进一步包括:
主叫节点在不支持DH协商时,将“I0”承载于呼叫接入请求消息的明文标记的tokenOID中,传输至其归属的关守;
主叫节点在支持DH协商时,将“I4”承载于呼叫接入请求消息的明文标记的tokenOID中,将主叫节点的DH公钥承载于所述明文标记的dhkey中,传输至其归属的关守。
所述步骤b中的主叫方会话密钥分配方式包括:被叫节点的归属关守产生会话密钥和/或主被叫节点的归属关守之间进行DH协商和/或主叫节点与被叫节点的归属关守之间进行DH协商。
所述步骤b进一步包括:
当所述主叫节点的归属关守确定主叫方会话密钥分配方式为被叫节点的归属关守产生会话密钥时,将“I0”承载于定位请求消息中的明文标记的tokenOID中,传输至被叫节点的归属关守;
当所述主叫节点的归属关守确定主叫方会话密钥分配方式为主被叫节点的归属关守之间进行DH协商时,所述主叫节点的归属关守产生其DH公钥,并承载于定位请求消息中的明文标记的dhkey中,将“I4”承载于所述明文标记的tokenOID中,传输至被叫节点的归属关守;
当所述主叫节点的归属关守确定主叫方会话密钥分配方式为主叫节点与被叫节点的归属关守之间进行DH协商时,将所述呼叫接入请求消息中的明文标记承载于定位请求消息中,传输至被叫节点的归属关守。
所述步骤c中被叫方会话密钥分配方式包括:被叫节点的归属关守产生会话密钥和/或DH协商。
所述步骤c进一步包括:
当所述被叫节点的归属关守确定被叫方会话密钥分配方式为被叫节点的归属关守产生会话密钥时,生成主被叫节点间的会话密钥,并生成tokenOID为“I2”的CTb、tokenOID为“I3”的CTg,通过定位确认消息传输至主叫节点的归属关守;
当所述被叫节点的归属关守确定被叫方会话密钥分配方式为DH协商时,产生DH公钥,并将所述DH公钥和从定位请求消息中获取的DH公钥一起通过DH算法计算出会话密钥,生成tokenOID为“I2”的CTb及tokenOID为“I5”且dhkey为所述被叫节点的归属关守产生的DH公钥的明文标记,将所述CTb及所述明文标记通过定位确认消息传输至主叫节点的归属关守。
所述步骤d具体包括:
所述主叫节点的归属关守获取定位确认消息中承载的被叫方会话密钥分配方式信息,并判断;
如果该信息为被叫节点的归属关守产生会话密钥,根据定位确认消息中承载的CTg生成CTa,将所述CTa、定位确认消息中的CTb通过呼叫接入确认消息传输至主叫节点;
如果该信息为DH协商且确定主叫节点不支持DH协商,根据其DH公钥、定位确认消息中的被叫节点的归属关守的DH公钥通过DH算法计算会话密钥,并产生CTa,将所述CTa、定位确认消息中的CTb通过呼叫接入确认消息传输至主叫节点;
如果该信息为DH协商且确定主叫节点支持DH协商,获取所述定位确认消息中的明文标记,并将其承载于呼叫接入确认消息中传输至主叫节点;
所述主叫节点判断呼叫接入确认消息中是否包含tokenOID为“I5”的明文标记;
如果不包含tokenOID为“I5”的明文标记,根据其与归属关守之间的共享密钥、呼叫接入确认消息中的CTa计算出会话密钥;
如果包含tokenOID为“I5”的明文标记,根据其DH公钥、所述呼叫接入确认消息中承载的被叫节点的归属关守的DH公钥计算会话密钥;
所述主叫节点根据所述会话密钥设置呼叫建立消息的鉴权信息,同时,将所述CTb承载于呼叫建立消息中传输至被叫节点;
所述被叫节点根据所述呼叫建立消息中的CTb获取所述会话密钥,并根据所述会话密钥对呼叫建立消息进行鉴权,确定主叫节点;
所述被叫节点将所述会话密钥确定为所述主叫节点与其进行直接路由模式的消息传输的会话密钥。
所述方法在步骤a之前还包括:
节点将其支持DH协商的信息承载于网守发现请求/注册请求消息的明文标记中传输至其归属的关守。
通过上述技术方案的描述可知,本发明通过在主被叫关守设置其选取会话密钥的分配方式,使主被叫节点的归属关守能够根据网络的具体情况灵活选择主被叫节点间的会话密钥;本发明中的关守能够在主被叫节点均不支持DH协商过程时,通过主被叫节点的归属关守之间进行DH协商来分配主被叫节点间的会话密钥,为主被叫节点提供了一种新的端到端的安全服务,提高了会话密钥的安全性;从而通过本发明提供的技术方案实现了提高归属关守分配会话密钥的灵活性、使消息传输的安全等级与消息传输时延取得平衡的目的。
附图说明
图1是包括两个GK的H323***的组网逻辑框图。
具体实施方式
本发明的核心是:主/被叫节点的归属关守根据接收的消息中承载的信息、预先设置的选择会话密钥分配方式的预定规则确定主/被叫方会话密钥分配方式,并为主、被叫节点分配会话密钥。
下面基于本发明的核心思想对本发明提供的技术方案做进一步的描述。
本发明适用于H323***跨GK管理范围的直接路由模式,即主/被叫节点分别注册在不同的主/被叫GK上,且通讯过程在没有安全性保证的IP网络上进行。
实施本发明技术方案的前提是:GK对其管理节点的所有RAS消息进行鉴权,节点也对其归属的GK的RAS消息进行鉴权,使节点和其归属的GK之间达到相互信任的目的。相互连接的GK之间也进行相互鉴权,避免GK域间的恶意攻击,使相互连接的GK之间达到相互信任的目的。通过上述鉴权过程保证了H.323实体之间RAS信道的安全性。
本发明首先需要设置关守选择会话密钥分配方式的预定规则,该预定规则可通过静态配置、动态配置等方式设置在关守。
预定规则可根据关守所处的主被叫方分为:主叫方预定规则和被叫方预定规则。主/被叫方预定规则包含的内容可根据实际网络中的实际需要来设定,如主叫方预定规则可包括下述的一项或多项:关守可用的计算资源、主叫节点支持的会话密钥分配方式、主叫节点的安全级别等,被叫方预定规则可包括下述的一项或多项:关守可以的计算资源、主叫方会话密钥分配方式、被叫节点的安全级别等。
在进行上述设置后,主被叫关守均可根据其繁忙程度等因素灵活选取会话密钥的分配方式。
下面通过下述三种过程对本发明的主、被叫节点的归属关守同时行使会话密钥分配选择权实现会话密钥分配过程进行详细描述。
三种会话密钥的分配过程分别为:
DRCI:主、被叫方会话密钥分配方式均为被叫节点的归属GK产生会话密钥。
DRCII:主叫方会话密钥分配方式为主被叫节点的归属关守之间进行DH协商、且被叫方会话密钥分配方式为DH协商。
DRCIII:主叫方会话密钥分配方式为主叫节点与被叫节点的归属关守之间进行DH协商、且被叫方会话密钥分配方式为DH协商。
本发明中的节点可以在GK发现过程中或节点注册过程中向其归属的GK表明其是否支持DH协商,如节点在GRQ/RRQ(网守发现请求/注册请求)消息中携带独立ClearToken,当节点将该ClearToken中的tokenOID设置为“I0”,表明其不支持DH协商,当节点将该ClearToken中的tokenOID设置为“I4”时,表明其支持DH协商。节点归属的GK接收GRQ/RRQ消息,并根据消息中独立携带的ClearToken的tokenOID承载的信息,即可确定该节点是否支持DH协商过程,节点的归属GK根据管理策略决定是否接受此节点,并回复GCF/RCF(网守发现确认/注册确认)消息,GCF/RCF消息中携带与GRQ/RRQ消息中相同的ClearToken。
当主叫节点不支持DH协商过程时,主叫节点的归属GK可以根据主叫方预定规则分别选择DRCI、DRCII过程来分配主被叫节点间的会话密钥,被叫节点的归属GK同样可以选择DRCI、DRCII过程来分配主被叫节点间的会话密钥。
当主叫节点支持DH协商过程时,主叫节点的归属GK可以分别选择DRCI、DRCIII过程来分配主被叫节点间的会话密钥,被叫节点的归属GK同样可以选择DRCI、DRCIII过程来分配主被节点间的会话密钥。
下面结合附图1对主、被叫节点的归属GK通过DRCI、DRCII、DRCIII过程实现主被叫节点间的会话密钥分配过程进行详细描述:
DRCI过程的步骤1、主叫节点EPa使用直接路由模式呼叫被叫节点EPb前,主叫节点EPa向其归属的GKg发送ARQ消息,该消息中应包含一个独立的ClearToken,该ClearToken的tokenOID应设置为“I0”,表明主叫节点不支持DH协商,该ClearToken的其他字段不使用。
DRCI过程的步骤2、GKg在接收到EPa发送来的ARQ消息后,根据ARQ消息中的destinationInfo或者destCallSignalAddress确定被叫节点为Epb,由于EPb不属于自己管辖范围内的节点,所以,GKg需要发起LRQ消息向GKh查询EPb的地址信息。
GKg生成LRQ消息,GKg根据ARQ消息的ClearToken的tokenOID为“I0”和主叫方预定规则在确定主叫方会话密钥分配方式为被叫节点的归属关守产生会话密钥时,使LRQ消息中包含一个ClearToken,该ClearToken的tokenOID应设置为“I0”,表明主叫方会话密钥分配方式为被叫节点的归属关守产生会话密钥,该ClearToken中的其他字段不使用,在进行上述设置后,GKg向GKh发送LRQ消息。
DRCI过程的步骤3、GKh接收LRQ消息,在检验该消息中的ClearToken的tokenOID为“I0”、且根据被叫方预定规则确定使用被叫节点的归属GK产生会话密钥时,使用随机数产生会话密钥Kab。GKh为了加密Kab,首先,产生随机challenge,并使用GKh和GKg之间的共享密钥Kgh和challenge以及指定的密钥导出算法导出密钥EKgh。然后,GKh用EKgh加密Kab得到EKab1,并把EKab1和加密参数如加密算法和加密用到的初始化向量等一起,设置到一个独立的ClearToken.h235Key.secureSharedSecret字段中。这个ClearToken的tokenOID为“I3”,称为CTg。同时,GKh使用类似的过程产生另一个ClearToken,该ClearToken的tokenOID为“I2”,即CTb。最后,GKh生成LCF消息,该LCF消息中包含CTg和CTb。GKh将LCF消息直接发送至GKg,或向GKh的上一级GK发送LCF消息,直至传输至GKg。
DRCI过程的步骤4、GKh接收LCF消息,在检验该消息中ClearToken的tokenOID为“I3”时,解密CTg,并产生CTa。具体过程如下:首先,GKg通过CTg中的challenge、IV以及指定的密钥导出算法导出密钥EKgh。然后,GKg用EKgh解密EKab1得到Kab。为了产生CTa,首先,GKg用GKg和EPa之间的共享密钥Kag和challenge以及指定的密钥导出算法导出密钥EKag。然后,GKg用EKag加密Kab得到EKab1,并把EKab1和加密参数如加密算法和加密用到的初始化向量等一起设置到一个独立的ClearToken.h235Key.secureSharedSecret字段中。这个ClearToken的tokenOID为”I1”,称为CTa。最后,GKg生成ACF,其中包含CTa和其接收的LCF消息中复制过来的CTb。
若GKg管理范围内存在下一级GK,则ACF中应包含CTa和CTg,下一级GK使用其与GKg的导出密钥加密Kab生成。
在进行上述设置后,GKg向EPa发送ACF消息。
DRCI过程的步骤5、Epa接收ACF消息,从该消息中提取CTa,并根据CTa中的信息和其与GKg的共享密钥Kag导出密钥EKag,然后,使用EKag解密CTa.h235Key.secureSharedSecret.encryptedSessionKey得到会话密钥Kab。
EPa创建Setup消息,把ACF消息中的CTb复制到Setup消息中,然后利用会话密钥Kab设置H235V3附录D/附录F的鉴权信息。EPa直接向EPb发出呼叫建立请求消息Setup。
Epb接收Setup消息,从该消息中提取CTb,并根据CTb中信息和其与GKh的共享密钥Kbh导出密钥EKbh,然后使用EKbh解密CTb.h235Key.secureSharedSecret.encryptedSessionKey得到会话密钥Kab;此时,EPb就可以使用Kab对Setup消息进行鉴权,根据鉴权结果确定发送Setup消息的主叫节点,将会话密钥Kab确定为Epb与Epa之间进行Q931消息传输的会话密钥。
后续的呼叫过程利用H235附录D/附录F进行鉴别。
DRCII过程的步骤1、主叫节点EPa使用直接路由模式呼叫被叫节点EPb前,主叫节点EPa向其归属的GKg发送ARQ消息,该消息中应包含一个独立的ClearToken,该ClearToken的tokenOID应设置为“I0”,表明主叫节点不支持DH协商,该ClearToken的其他字段不使用。
DRCII过程的步骤2、GKg接收EPa发送来的ARQ消息,根据ARQ消息中的destinationInfo或者destCallSignalAddress确定被叫节点为Epb,由于EPb不属于自己管辖的节点,所以GKg发起LRQ消息向GKh查询EPb的地址。
GKg生成LRQ消息,GKg根据ARQ消息的ClearToken的tokenOID为“I0”和主叫方预定规则在确定主叫方会话密钥分配方式为主被叫节点的归属GK进行DH协商时产生会话密钥时,在该消息中包含一个ClearToken,ClearToken中的tokenOID为“I4”,表明主叫方会话密钥分配方式为主被叫节点的归属GK进行DH协商,GKg产生GKg的DH公钥,并设置在该ClearToken的dhkey中。
在进行上述设置后,GKg向GKh发送LRQ消息。
DRCII过程的步骤3、GKh接收LRQ消息,在检验到该消息中ClearToken的tokenOID为“I4”、且根据被叫方预定规则确定被叫方会话密钥分配方式为DH协商时,GKh开始与GKg使用DH协商过程确定主被叫节点间的会话密钥。具体过程为:首先,GKh生成期望GKh的DH公钥,与从LRQ消息中获取的GKg的公钥一起,使用DH算法计算出会话密钥Kab。然后,使用DRC I过程的步骤3的方法生成tokenOID为“I2”的CTb。最后,GKh生成LCF消息,其中包含CTb和一个独立的ClearToken,该ClearToken的tokenOID为“I5”,并包含GKh的DH公钥。ClearToken的tokenOID为“I5”即表明该ClearToken中包含有被叫节点的归属关守的DH公钥。
如果GKh由于不支持DH算法或安全策略不允许等因素根据被叫方预定规则确定被叫方会话密钥分配方式为被叫节点的归属GK产生会话密钥时,则GKh应该使用DRC I过程的步骤3生成LCF消息。
在进行上述设置后,GKh向GKg发送LCF消息。
DRCII过程的步骤4、GKg接收LCF消息,在检验出消息中包含tokenOID为“I5”的ClearToken、且主叫节点不支持DH协商时,计算会话密钥并产生CTa。具体过程为:从LCF消息独立的ClearToken中获得Gkh的DH共钥,与自己保存的GKg的DH公钥一起使用DH算法计算出会话密钥Kab。然后,使用与DRC I过程中步骤4基本相同的过程生成CTa。最后,GKg生成ACF消息,其中包含CTa和从LCF消息中复制过来的CTb。
如果GKg在检验出LCF消息中包含tokenOID为“I5”的ClearToken、且主叫节点支持DH协商时,则GKg应该使用DRCIII过程的步骤4生成ACF消息。
如果GKg在检验出LCF消息中包含有tokenOID为“I3”的ClearToken时,GKg应使用DRC I过程的步骤4生成ACF消息。
在进行上述设置后GKg向EPa发送ACF消息。
DRCII过程的步骤5、Epa接收ACF消息,如果Epa在检验出ACF消息中不包含tokenOID为“I5”的ClearToken时,从ACF消息中提取CTa,并根据CTa中的信息和其与GKg的共享密钥Kag导出密钥EKag,然后使用EKag解密CTa.h235Key.secureSharedSecret.encryptedSessionKey得到会话密钥Kab。
如果Epa在检验出ACF消息中包含tokenOID为“I5”的ClearToken时,根据DRCIII过程的步骤5计算出会话密钥Kab。
EPa创建Setup消息,把ACF消息中的CTb复制到Setup消息中,然后,利用主被叫节点间的会话密钥Kab设置H235V3附录D/附录F的鉴权信息。EPa直接向EPb发送呼叫建立请求消息Setup。
Epb接收Setup消息,并从该消息中提取CTb,并根据CTb中信息和其与GKh的共享密钥Kbh导出密钥EKbh,然后使用EKbh解密CTb.h235Key.secureSharedSecret.encryptedSessionKey得到会话密钥Kab。此时,EPb就可以使用会话密钥Kab对Setup消息进行鉴权,根据鉴权结果确定发送Setup消息的主叫节点,将会话密钥Kab确定为Epb与Epa之间进行Q931消息传输的会话密钥。
后续的呼叫过程利用H235附录D/附录F进行鉴别。
DRCIII过程的步骤1、主叫节点支持DH协商过程,主叫节点EPa使用直接路由模式呼叫被叫节点EPb前,EPa生成其期望的DH公钥,并设置在ARQ消息的独立的ClearToken的dhkey中,该ClearToken的tokenOID设置为“I4”,其他字段不使用。
DRCIII过程的步骤2、GKg接收ARQ消息,根据ARQ消息中的destinationInfo或者destCallSignalAddress确定被叫节点为Epb,由于EPb不属于自己管辖的节点,所以,GKg发起LRQ消息向GKh查询EPb的地址。
GKg生成LRQ消息,GKg根据ARQ消息的ClearToken的tokenOID为“I4”和主叫方预定规则在确定主叫方会话密钥分配方式为主叫节点与被叫节点的归属关守进行DH协商时,将ARQ消息中的ClearToken复制到LRQ消息中,GKg向GKh发送LRQ消息。
DRCIII过程的步骤3、GKh接收LRQ消息,在检验出LRQ消息中包含有tokenOID为“I4”的独立ClearToken、且根据被叫方预定规则确定被叫方会话密钥分配方式为DH协商时,根据使用DH协商过程开始与EPa协商会话密钥。具体过程为:首先,GKh生成期望的DH公钥,与从LRQ中获取的GKg的DH公钥一起,使用DH算法计算出会话密钥Kab。然后,使用与DRCI过程中的步骤3的方法生成CTb,该CTb的tokenOID为“I2”。最后,GKh生成LCF消息,其中包含CTb和一个独立的ClearToken,该ClearToken中的tokenOID为“I5”,并包含GKh的DH公钥。ClearToken的tokenOID为“I5”即表明该ClearToken中包含有被叫节点的归属关守的DH公钥
如果GKh由于不支持DH算法或安全策略不允许等因素根据被叫方的预定规则确定被叫方会话密钥分配方式为被叫节点的归属GK产生会话密钥时,则GKh应该使用DRCI过程的步骤3生成LCF消息。
在进行上述设置后,GKh向GKg发送LCF消息。
DRCIII过程的步骤4、GKg接收LCF消息,在检验出LCF消息中包含有tokenOID为“I5”的ClearToken、且主叫节点支持DH协商时,GKg生成ACF消息,该消息中包含从LCF消息中复制过来的所有ClearToken。GKg向EPa发送ACF消息。
如果GKg在检验出LCF消息中包含有tokenOID为“I3”的ClearToken、且确定主叫节点不支持DH协商时,GKg应使用DRCI过程中的步骤4生成ACF消息。
DRCIII过程的步骤5、Epa接收ACF消息,在检验出该消息中包含有tokenOID为“I5”的独立ClearToken时,计算会话密钥。具体过程为:Epa从ClearToken中获得被叫节点的归属关守的DH共钥,与自己保存的DH共钥一同使用DH算法计算出会话密钥Kab。
Epa在检验出该消息中包含有tokenOID为“I3”的独立ClearToken时,应使用DRCI过程的步骤5的计算会话密钥的方法来计算会话密钥。
EPa创建Setup消息,把ACF消息中的CTb复制到Setup消息中,然后利用共享密钥Kab设置H235V3附录D/附录F的鉴权信息。EPa直接向EPb发出呼叫建立请求消息Setup。
Epb接收Setup消息,从该消息中提取CTb,并根据CTb中的信息和其与GKh的共享密钥Kbh导出密钥EKbh,然后使用EKbh解密CTb.h235Key.secureSharedSecret.encryptedSessionKey得到会话密钥Kab,此时,EPb就可以使用Kab对Setup消息进行鉴权,根据鉴权结果确定发送Setup消息的主叫节点,将会话密钥Kab确定为Epb与Epa之间进行Q931消息传输的会话密钥。
后续的呼叫过程利用H235附录D/附录F进行鉴别。
本发明中tokenOID标识符的意义如表1所示:
表1
ObjectIdentifierReference | Object Identifier Value | Description |
″I0″ | {itu-t(0)recommendation(0)h(8)235version(0)348} | 1.在GRQ/RRQ、GCF/RCF、ARQ的独立Clear Token中使用,表明节点Ep不支持DH过程。2.在LRQ的独立ClearToken中使用,表明此ClearToken包含主叫方的DH公钥。 |
″I1″ | {itu-t(0)recommendation(0)h(8)235version(0)349} | 在交给主叫节点的独立ClearToken中使用,表明此ClearToken中包含会话密钥。 |
″I2″ | {itu-t(0)recommendation(0)h(8)235version(0)350} | 在交给被叫节点的独立ClearToken中使用,表明此ClearToken中包含会话密钥。 |
″I3″ | {itu-t(0)recommendation(0)h(8)235version(0)351} | 在LCF的独立ClearToken中使用,表明此ClearToken包含会话密钥。 |
″I4″ | {itu-t(0)recommendation(0)h(8)235version(0)352} | 1.在GRQ/RRQ、GCF/RCF、ARQ的独立ClearToken中使用,表明EP支持DH过程。2.在LRQ的独立ClearToken中使用,表明此ClearToken包含主叫方的DH公钥。 |
″I5″ | {itu-t(0)recommendation(0)h(8)235version(0)353} | 在交给主叫节点的独立ClearToken中使用,表明此ClearToken中包含被叫方的DH公钥。 |
虽然通过实施例描绘了本发明,本领域普通技术人员知道,本发明有许多变形和变化而不脱离本发明的精神,本发明的申请文件的权利要求包括这些变形和变化。
Claims (10)
1、一种直接路由模式下跨关守管理范围的会话密钥分配方法,其特征在于,包括:
主/被叫节点的归属关守根据接收的消息中承载的信息、预先设置的选择会话密钥分配方式的预定规则确定主/被叫方会话密钥分配方式,并为主、被叫节点分配会话密钥。
2、如权利要求1所述的一种直接路由模式下跨关守管理范围的会话密钥分配方法,其特征在于,所述预定规则包括:主叫方预定规则、被叫方预定规则;
所述主叫方预定规则包括:关守的可用计算资源和/或主叫节点支持的会话密钥分配方式和/或主叫节点的安全级别;
所述被叫方预定规则包括:关守的可用计算资源和/或主叫方会话密钥分配方式和/或被叫节点的安全级别。
3、如权利要求1所述的一种直接路由模式下跨关守管理范围的会话密钥分配方法,其特征在于,所述方法具体包括:
a、主叫节点将其支持的会话密钥分配方式承载于呼叫接入请求消息中传输至其归属的关守;
b、所述主叫节点的归属关守根据呼叫接入请求消息中承载的主叫节点支持的会话密钥分配方式信息、所述预定规则确定主叫方会话密钥分配方式,并将其承载于定位请求消息中传输至被叫节点的归属关守;
c、所述被叫节点的归属关守根据定位请求消息中承载的信息、所述预定规则确定被叫方会话密钥分配方式,并计算所述主被叫节点间的会话密钥,将被叫方会话密钥分配方式、所述会话密钥通过定位确认消息传输至主叫节点的归属关守;
d、所述主叫节点的归属关守根据定位确认消息中承载的信息、主叫节点支持的会话密钥分配方式确定会话密钥,并将所述会话密钥通过呼叫接入确认消息传输至所述主被叫节点。
4、如权利要求3所述的一种直接路由模式下跨关守管理范围的会话密钥分配方法,其特征在于,所述步骤a进一步包括:
主叫节点在不支持DH协商时,将“I0”承载于呼叫接入请求消息的明文标记的tokenOID中,传输至其归属的关守;
主叫节点在支持DH协商时,将“I4”承载于呼叫接入请求消息的明文标记的tokenOID中,将主叫节点的DH公钥承载于所述明文标记的dhkey中,传输至其归属的关守。
5、如权利要求3或4所述的一种直接路由模式下跨关守管理范围的会话密钥分配方法,其特征在于,所述步骤b中的主叫方会话密钥分配方式包括:被叫节点的归属关守产生会话密钥和/或主被叫节点的归属关守之间进行DH协商和/或主叫节点与被叫节点的归属关守之间进行DH协商。
6、如权利要求5所述的一种直接路由模式下跨关守管理范围的会话密钥分配方法,其特征在于,所述步骤b进一步包括:
当所述主叫节点的归属关守确定主叫方会话密钥分配方式为被叫节点的归属关守产生会话密钥时,将“I0”承载于定位请求消息中的明文标记的tokenOID中,传输至被叫节点的归属关守;
当所述主叫节点的归属关守确定主叫方会话密钥分配方式为主被叫节点的归属关守之间进行DH协商时,所述主叫节点的归属关守产生其DH公钥,并承载于定位请求消息中的明文标记的dhkey中,将“I4”承载于所述明文标记的tokenOID中,传输至被叫节点的归属关守;
当所述主叫节点的归属关守确定主叫方会话密钥分配方式为主叫节点与被叫节点的归属关守之间进行DH协商时,将所述呼叫接入请求消息中的明文标记承载于定位请求消息中,传输至被叫节点的归属关守。
7、如权利要求3或4所述的一种直接路由模式下跨关守管理范围的会话密钥分配方法,其特征在于,所述步骤c中被叫方会话密钥分配方式包括:被叫节点的归属关守产生会话密钥和/或DH协商。
8、如权利要求7所述的一种直接路由模式下跨关守管理范围的会话密钥分配方法,其特征在于,所述步骤c进一步包括:
当所述被叫节点的归属关守确定被叫方会话密钥分配方式为被叫节点的归属关守产生会话密钥时,生成主被叫节点间的会话密钥,并生成tokenOID为“I2”的CTb、tokenOID为“I3”的CTg,通过定位确认消息传输至主叫节点的归属关守;
当所述被叫节点的归属关守确定被叫方会话密钥分配方式为DH协商时,产生DH公钥,并将所述DH公钥和从定位请求消息中获取的DH公钥一起通过DH算法计算出会话密钥,生成tokenOID为“I2”的CTb及tokenOID为“I5”且dhkey为所述被叫节点的归属关守产生的DH公钥的明文标记,将所述CTb及所述明文标记通过定位确认消息传输至主叫节点的归属关守。
9、如权利要求8所述的一种直接路由模式下跨关守管理范围的会话密钥分配方法,其特征在于,所述步骤d具体包括:
所述主叫节点的归属关守获取定位确认消息中承载的被叫方会话密钥分配方式信息,并判断;
如果该信息为被叫节点的归属关守产生会话密钥,根据定位确认消息中承载的CTg生成CTa,将所述CTa、定位确认消息中的CTb通过呼叫接入确认消息传输至主叫节点;
如果该信息为DH协商且确定主叫节点不支持DH协商,根据其DH公钥、定位确认消息中的被叫节点的归属关守的DH公钥通过DH算法计算会话密钥,并产生CTa,将所述CTa、定位确认消息中的CTb通过呼叫接入确认消息传输至主叫节点;
如果该信息为DH协商且确定主叫节点支持DH协商,获取所述定位确认消息中的明文标记,并将其承载于呼叫接入确认消息中传输至主叫节点;
所述主叫节点判断呼叫接入确认消息中是否包含tokenOID为“I5”的明文标记;
如果不包含tokenOID为“I5”的明文标记,根据其与归属关守之间的共享密钥、呼叫接入确认消息中的CTa计算出会话密钥;
如果包含tokenOID为“I5”的明文标记,根据其DH公钥、所述呼叫接入确认消息中承载的被叫节点的归属关守的DH公钥计算会话密钥;
所述主叫节点根据所述会话密钥设置呼叫建立消息的鉴权信息,同时,将所述CTb承载于呼叫建立消息中传输至被叫节点;
所述被叫节点根据所述呼叫建立消息中的CTb获取所述会话密钥,并根据所述会话密钥对呼叫建立消息进行鉴权,确定主叫节点;
所述被叫节点将所述会话密钥确定为所述主叫节点与其进行直接路由模式的消息传输的会话密钥。
10、如权利要求3所述的一种直接路由模式下跨关守管理范围的会话密钥分配方法,其特征在于,所述方法在步骤a之前还包括:
节点将其支持DH协商的信息承载于网守发现请求/注册请求消息的明文标记中传输至其归属的关守。
Priority Applications (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2005100053974A CN100382484C (zh) | 2005-02-04 | 2005-02-04 | 一种直接路由模式下跨关守管理范围的会话密钥分配方法 |
EP06705589.7A EP1808978B2 (en) | 2005-02-04 | 2006-01-26 | A method and system for distributing the session key across Gatekeeper zones in the direct routing mode |
PCT/CN2006/000168 WO2006081765A1 (fr) | 2005-02-04 | 2006-01-26 | Procede de distribution de la cle de session dans la gamme de gestion du portier transversal selon le mode du trajet le plus direct |
ES06705589.7T ES2402862T5 (es) | 2005-02-04 | 2006-01-26 | Un método y sistema para distribuir la clave de sesión a través de las zonas con múltiples controladores de acceso, Gatekeeper, según el modo de encaminamiento directo |
US11/648,924 US7983280B2 (en) | 2005-02-04 | 2007-01-03 | Method and system for distributing session key across gatekeeper zones in a direct-routing mode |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2005100053974A CN100382484C (zh) | 2005-02-04 | 2005-02-04 | 一种直接路由模式下跨关守管理范围的会话密钥分配方法 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNA2007101814702A Division CN101174944A (zh) | 2005-02-04 | 2005-02-04 | 一种直接路由模式下跨关守管理范围的会话密钥分配方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN1815950A true CN1815950A (zh) | 2006-08-09 |
CN100382484C CN100382484C (zh) | 2008-04-16 |
Family
ID=36776968
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNB2005100053974A Active CN100382484C (zh) | 2005-02-04 | 2005-02-04 | 一种直接路由模式下跨关守管理范围的会话密钥分配方法 |
Country Status (5)
Country | Link |
---|---|
US (1) | US7983280B2 (zh) |
EP (1) | EP1808978B2 (zh) |
CN (1) | CN100382484C (zh) |
ES (1) | ES2402862T5 (zh) |
WO (1) | WO2006081765A1 (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2015027410A1 (zh) * | 2013-08-28 | 2015-03-05 | 华为技术有限公司 | 分发密钥的方法、m2m平台及m2m终端 |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050238174A1 (en) * | 2004-04-22 | 2005-10-27 | Motorola, Inc. | Method and system for secure communications over a public network |
EP3439345A1 (en) * | 2013-03-05 | 2019-02-06 | Huawei Technologies Co., Ltd. | Key exchange method and apparatus |
US9276910B2 (en) * | 2013-11-19 | 2016-03-01 | Wayne Fueling Systems Llc | Systems and methods for convenient and secure mobile transactions |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
AU6758898A (en) * | 1997-03-12 | 1998-09-29 | Visa International | Secure electronic commerce employing integrated circuit cards |
US6681017B1 (en) * | 1997-09-03 | 2004-01-20 | Lucent Technologies Inc. | Simplified secure shared key establishment and data delivery protocols for electronic commerce |
US6775253B1 (en) * | 1999-02-25 | 2004-08-10 | Telcordia Technologies, Inc. | Adaptive signaling for wireless packet telephony |
US6996716B1 (en) * | 1999-04-15 | 2006-02-07 | Avaya Technology Corp. | Dual-tier security architecture for inter-domain environments |
US6658567B1 (en) * | 1999-06-25 | 2003-12-02 | Geomechanics International, Inc. | Method and logic for locking geological data and an analyzer program that analyzes the geological data |
US6775255B1 (en) * | 1999-09-16 | 2004-08-10 | At&T Corp. | H.323 mobility architecture for terminal, user and service mobility |
CN1180573C (zh) * | 2001-08-29 | 2004-12-15 | 华为技术有限公司 | Ip网络***中的节点跨区域呼叫方法 |
JP3746713B2 (ja) * | 2001-12-28 | 2006-02-15 | 株式会社日立製作所 | インターネット電話システムおよび情報処理装置 |
US20040243815A1 (en) | 2003-05-28 | 2004-12-02 | Yoshihiro Tsukamura | System and method of distributing and controlling rights of digital content |
-
2005
- 2005-02-04 CN CNB2005100053974A patent/CN100382484C/zh active Active
-
2006
- 2006-01-26 EP EP06705589.7A patent/EP1808978B2/en active Active
- 2006-01-26 WO PCT/CN2006/000168 patent/WO2006081765A1/zh active Application Filing
- 2006-01-26 ES ES06705589.7T patent/ES2402862T5/es active Active
-
2007
- 2007-01-03 US US11/648,924 patent/US7983280B2/en active Active
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2015027410A1 (zh) * | 2013-08-28 | 2015-03-05 | 华为技术有限公司 | 分发密钥的方法、m2m平台及m2m终端 |
CN104756440A (zh) * | 2013-08-28 | 2015-07-01 | 华为技术有限公司 | 分发密钥的方法、m2m平台及m2m终端 |
Also Published As
Publication number | Publication date |
---|---|
ES2402862T5 (es) | 2018-03-08 |
US20070168527A1 (en) | 2007-07-19 |
US7983280B2 (en) | 2011-07-19 |
EP1808978B1 (en) | 2013-03-13 |
EP1808978A4 (en) | 2008-02-20 |
WO2006081765A1 (fr) | 2006-08-10 |
EP1808978A1 (en) | 2007-07-18 |
CN100382484C (zh) | 2008-04-16 |
EP1808978B2 (en) | 2017-11-15 |
ES2402862T3 (es) | 2013-05-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN1268088C (zh) | 基于pki的vpn密钥交换的实现方法 | |
US7813509B2 (en) | Key distribution method | |
CN1298194C (zh) | 基于漫游密钥交换认证协议的无线局域网安全接入方法 | |
CN1859093A (zh) | 在ip多媒体子***中认证用户终端的方法 | |
CN101052033A (zh) | 基于ttp的认证与密钥协商方法及其装置 | |
CN1870812A (zh) | Ip多媒体子***接入域安全机制的选择方法 | |
CN1602611A (zh) | 端到端加密数据电信的合法侦听 | |
CN1816213A (zh) | 一种端到端加密语音通信的方法 | |
CN1859091A (zh) | 一种基于cpk的可信连接安全认证***和方法 | |
CN1879382A (zh) | 在设备间建立加密通信通道的方法、设备和程序 | |
CN1659922A (zh) | 用于询问-应答用户鉴权的方法和*** | |
CN1574738A (zh) | 在移动特设网络中分配加密密钥的方法及其网络设备 | |
CN1929371A (zh) | 用户和***设备协商共享密钥的方法 | |
CN101061665A (zh) | 利用用户绑定在家用网络中传送内容的方法 | |
CN1186579A (zh) | 计算机支持的在两个计算机之间的密码交换方法 | |
CN1992593A (zh) | 应用于分组网络的基于h.323协议的终端接入方法 | |
CN101047505A (zh) | 一种网络应用push业务中建立安全连接的方法及*** | |
CN1874224A (zh) | 基于会话初始化协议的安全组播方法 | |
CN1815950A (zh) | 一种直接路由模式下跨关守管理范围的会话密钥分配方法 | |
CN1841998A (zh) | 一种终端用户安全接入软交换网络的方法 | |
CN1681239A (zh) | 在无线局域网***中支持多种安全机制的方法 | |
CN1889767A (zh) | 实现媒体流安全的方法及通信*** | |
CN1658551A (zh) | 安全能力协商方法 | |
CN1697424A (zh) | 一种基于十进制通信号码进行私有安全数据通信的方法 | |
CN1571409A (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 |