CN101273571B - 跨域多网守分组网络密钥协商安全策略的实现方法 - Google Patents

跨域多网守分组网络密钥协商安全策略的实现方法 Download PDF

Info

Publication number
CN101273571B
CN101273571B CN200680035570.8A CN200680035570A CN101273571B CN 101273571 B CN101273571 B CN 101273571B CN 200680035570 A CN200680035570 A CN 200680035570A CN 101273571 B CN101273571 B CN 101273571B
Authority
CN
China
Prior art keywords
key
gatekeeper
called
public
end points
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.)
Active
Application number
CN200680035570.8A
Other languages
English (en)
Other versions
CN101273571A (zh
Inventor
卢忱
张亮
李广峰
李岩
孙长印
刘卫刚
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ZTE Corp
Original Assignee
ZTE Corp
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 Corp filed Critical ZTE Corp
Publication of CN101273571A publication Critical patent/CN101273571A/zh
Application granted granted Critical
Publication of CN101273571B publication Critical patent/CN101273571B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明提供了一种跨域多网守分组网络密钥协商安全策略实现方法，包括以下步骤：各端点分别与其归属的网守之间通过信令交互确定各端点的本地安全策略；主叫网守根据主叫端点的安全策略与自身的密钥支持能力，确定密钥协商规程，发出密钥协商请求；被叫网守判断是否能够按照最高优先级规程来执行所述被转发的主叫端点的密钥协商请求；主叫端点决定是否继续以协商的安全策略，进行后续信令交互。使用本发明安全策略实现方法，可以动态协商可信会话密钥，利用密码学将其与呼叫认证捆绑在一起，实现分组网络的安全策略，本发明方法采用的安全技术与现有标准相容，安全体系的布置也比较简单，并且不需要假定任何附加的安全基础设施方法。

Description

跨域多网守分组网络密钥协商安全策略的实现方法
技术领域
本发明涉及基于分组网络通信的安全策略实现方法技术领域，特别涉及一种在跨域多网守分组网络环境下具有不同处理能力与安全策略的ITU-T H.323多媒体端点(代表终端或网关)之间安全通信过程中会话密钥协商安全策略的实现方法。
背景技术
跨域多网守分组网络环境下，ITU-T H.323多媒体端点(EndPoint)之间安全通信不能假定二个端点之间的拥有一个预共享密钥(ShareSecret Key)，因为这种情形下，通信之前要求所有端点之间事先预共享密钥(Share Secret Key)是不现实的。
在单网守直接路由呼叫(DRC，Direct Router Call)模式下的相关安全问题，如加密会话密钥的协商、生成与发布，在ITU-T H.235附录I中作了详细描述，但在不同管理域中的多网守环境下，具有不同安全策略能力的多媒体端点(EndPoint)如何实现安全通信特别是会话密钥的协商仍然是一个待解决问题。
随着大规模H.323多媒体通信系统的布署与应用，如全球范围的VoIP网或国家范围面向公众的视频会议/可视电话系统等，在这种多运营商、跨多个管理域分层多网守环境下，为满足用户各种安全需求，提供一种有效及可实施的智能化的安全策略动态实现会话密钥协商的安全方案变得日益重要。
对于基于H.235标准实现ITU-T H.323多媒体端点之间安全通信而言，密钥是极为重要的。在分组网络上H.323端点之间通过密钥交换所得到的共享密钥可以对RAS信令、呼叫信令、H.245控制信令等实施身份证实，信令消息完整性检查以及对媒体数据流进行加/解密等安全措施。
目前，针对众多的安全策略，有多种方法用于密钥交换。一种方法采用电子邮件、电话或者其它非H.323协议形传送会话密钥。这类密钥交换方法比较有效、直接，但是当使用不加密通信方式来传递密钥时，有可能会导致密钥泄漏，以及在大规模布署环境下，这种方法因端点数众多即是可行也不现实。
现在常用的方法是采用对称密码(symmetric key cryptography)与公钥密码方法(Public Key cryptography)，如Diffie-Hellman或类似密钥协商方法，用于两台主机进行密钥的生成和共享。
H.225.0是H.323系统的核心协议之一，它由三部分组成：呼叫控制、RAS和如何用RTP对音视频信号进行封装；H.225.0的呼叫控制信令源自Q.931，其功能是在H.323的EP(EndPoint端点，包括终端和网关)之间建立呼叫联系，包括呼叫建立和拆除等流程；RAS是端点和网守之间的协议，主要完成登记、定位、呼叫接纳等管理功能。它主要包含以下协议过程：
网守搜索：用于端点自动搜索其归属网守。使用的消息有GRQ(Gatekeeper Request网守发现请求)、GRJ(Gatekeeper Reject网守拒绝)、GCF(Gatekeeper Confirm网守确认)。端点采用多播地址发送GRQ寻找自己的归属网守，可用的归属网守以GCF回应。端点收到确认后，选择自己的网守，获得并记录网守的RAS地址供后续RAS消息使用。
端点注册：用于端点向归属网守注册/去注册其自身的信息，包括别名地址(E.164地址或H.323标识)和呼叫信令传输层地址。端点必须在注册后才能发起和接受呼叫，注册表明端点加入了某管理区。用于注册的消息有RRQ(Registration Request注册请求)、RCF(Registration Confirm注册确认)、RRJ(Registration Reject注册拒绝)。端点使用RRQ向搜索到的归属网守登记，登记成功则网守以RCF回应。
呼叫接纳：用于网守控制端点的呼叫接入，包括用户接入认证、地址解析。使用的消息有ARQ(Admission Request接入请求)、ACF(AdmissionConfirm接入确认)、ARJ(Admission Reject接入拒绝)。当端点发起呼叫时，它首先向归属网守发送ARQ消息，包含认证信息、目的地地址和所要求的带宽等。网守对用户进行认证，对目的地址进行解析。如果网守同意发起此呼叫，就向端点回送ACF，包含允许分配的带宽和翻译后所得的被叫呼叫信令传输层地址或网守的呼叫信令传输层地址(取决于采用直选路由方式还是网守选路方式)。H.225.0呼叫控制协议就使用此呼叫信令传输层地址来发起呼叫。当端点收到入呼请求时，也要向其网守发送ARQ消息进行认证。如果网守同意端点接收该呼叫，就回送ACF，端点才可继续处理入呼流程。
定位功能：指请求网守提供地址翻译功能。使用的消息有LRQ(Location Request地址解析请求)、LCF(Location Confirm地址解析确认)、LRJ(Location Reject地址解析拒绝)。当端点或网守知道某一端点的别名地址，需要知道其呼叫信令传输层地址时，可向相应的网守发送LRQ消息。LRQ消息可以以单播或多播方式发送。当目标端点的网守收到LRQ消息后，通过LCF将该端点的呼叫信令运输层地址或该网守的呼叫信令传输层地址回送给请求者。回送哪个地址取决于呼叫信令是采用直接选路方式还是网守选路方式。
事实上，H.235并没有提出一种密钥交换技术，它只定义了一种基于H.323的协议集，以用于密钥交换。它允许开发者在产品中选择一种密钥交换方法，但是没有说明不同安全策略如何协商的安全策略。
对于小规模系统，可以通过预先配置安全策略与方法来保护各种信令安全协议，但对于规模较大的H.323系统，用户需要和不同的用户进行通信，预先配置的策略是不现实的。
大规模系统中，由于不同运营商、不同厂家H.323端点产品因能力不同采用不同密钥交换方法，特别是在H.323多网守环境不同路由呼叫模式下，现存端点设备的多种建立会话密钥方法，通信的二端点之间也不可能事先能预配置，这给具体实施带来困难。
发明内容
本发明所要解决的技术问题在于，提出了一种跨域多网守分组网络密钥协商安全策略实现方法。本发明方法扩展了H.235协议附录I中单网守直接路由限制，提出一种端点放在不同管理域、不同网守环境下、不同路由模式下的密钥协商方案，提供呼叫建立以及其以后信令消息安全，包括认证、完整性检查及可能的媒体流协议的机密性。
为解决上述技术问题，本发明提出了一种跨域多网守分组网络密钥协商安全策略实现方法，包括以下步骤：
(1)各端点分别与其归属的网守之间通过信令交互执行安全策略协商，根据各端点及其归属网守的密钥支持能力确定各端点的本地安全策略；
(2)主叫端点根据确定的本地安全策略向主叫网守发送密钥协商请求，主叫网守根据主叫端点的安全策略与自身的密钥支持能力，确定最高与最低优先级密钥协商规程，并按照最高优先级规程向被叫网守转发主叫端点的密钥协商请求；
(3)被叫网守根据自身的密钥支持能力，判断是否能够按照最高优先级规程来执行所述被转发的主叫端点的密钥协商请求，如果可以，则按照所述最高优先级规程执行密钥协商，如果不能，则按照所述确定的最低优先级规程执行密钥协商，并将协商结果通过主叫网守转发给主叫端点。
本发明方法可以进一步包括步骤：
(4)主叫端点接收到所述协商结果后，基于本地安全策略，决定是否继续利用协商结果进行后续的信令交互。
所述步骤(1)中的信令交互过程可以为网守发现过程或/和注册过程。
所述密钥支持能力可以为是否支持公钥密钥协商。
所述步骤(1)可以包括：
(1-1)通过网守发现请求或/和注册请求消息，端点向其归属网守报告其是否支持公钥密钥协商；
(1-2)网守根据端点与自身是否支持公钥密钥协商，通过网守发现确认或/和注册确认消息，向端点返回确定的端点本地安全策略，其中：
当端点与网守任何一方不支持公钥密钥协商时，确定端点本地安全策略为：希望由网守代为生成共享密钥；
当端点与网守都支持公钥密钥协商时，确定端点本地安全策略为：希望与被叫网守通过信令协商来生成共享密钥。
步骤(2)所述主叫端点向主叫网守发送的密钥协商请求可以为接入请求消息，该消息中包含有所述主叫端点的本地安全策略信息。
当主叫端点本地安全策略为希望与被叫网守通过信令协商来生成共享密钥时，所述接入请求消息中可以进一步包含有公钥信息。
步骤(2)所述主叫网守根据主叫端点的安全策略与自身的密钥支持能力，确定密钥协商规程的优先级的步骤，可以包括：
当该主叫端点本地安全策略为希望由网守代为生成共享密钥，且主叫网守不支持公钥密钥协商时，确定密钥协商规程的最高与最低优先级规程为：由被叫网守产生会话密钥；
当该主叫端点本地安全策略为希望由网守代为生成共享密钥，且主叫网守支持公钥密钥协商时，确定密钥协商规程的最高优先级规程为：主叫网守与被叫网守使用公钥密钥协商过程产生会话密钥；最低优先级规程为：由被叫网守产生会话密钥；
当该主叫端点本地安全策略为希望与被叫网守通过信令协商来生成共享密钥时，确定密钥协商规程的最高优先级规程为：主叫端点与被叫网守使用公钥密钥协商过程产生会话密钥；最低优先级规程为：由被叫网守产生会话密钥。
所述接入请求消息中，可以进一步包括有被叫端点信息，主叫网守根据该被叫端点信息，确定被叫端点是否与主叫端点分属不同的管理域。
所述步骤(2)中，主叫网守可以按照最高优先级规程向被叫网守转发主叫端点的密钥协商请求的步骤，是通过地址解析请求发送的，该地址解析请求中包含有所述确定的最高优先级规程信息。
所述步骤(3)中，被叫网守判断是否能够按照最高优先级规程来执行所述被转发的主叫端点的密钥协商请求的步骤，可以包括：
当所述最高优先级规程为由被叫网守产生会话密钥时，则判断为可以按照最高优先级规程来执行密钥协商；
当所述最高优先级规程为主叫网守与被叫网守使用公钥密钥协商过程产生会话密钥时，如果被叫网守支持公钥密钥协商，则判断为可以按照最高优先级规程来执行密钥协商；如果被叫网守不支持公钥密钥协商，判断为不能按照最高优先级规程来执行密钥协商；
当所述最高优先级规程为主叫端点与被叫网守使用公钥密钥协商过程产生会话密钥时，如果被叫网守支持公钥密钥协商时，则判断为可以按照最高优先级规程来执行密钥协商；如果被叫网守不支持公钥密钥协商，则判断为不能按照最高优先级规程来执行密钥协商。
使用本发明安全策略实现方法，可以动态协商可信会话密钥，利用密码学将其与呼叫认证捆绑在一起，实现分组网络的安全策略，本发明方法采用的安全技术与现有标准相容，安全体系的布置也比较简单，并且不需要假定任何附加的安全基础设施方法。
附图概述
图1为根据本发明实施例所述的跨域多网守分组网络密钥协商安全策略实现方法的多网守路由模式场景图；
图2为根据本发明实施例所述的跨域多网守分组网络密钥协商安全策略实现方法的多网守路由呼叫模式下安全策略实施过程图。
本发明的最佳实施方式
本发明的核心思想是不同管理域中的网守(GK，GateKeeper)根据所管辖的端点能力，灵活配制相应的安全策略管理策略来动态选择密钥分配方式，进而为不同域之间的端点完成密钥管理任务。在原理上，由于多管理域多网守环境下的H.323分组网络比封闭的H.323环境更加开放，密钥的管理需要保证一定的安全性。
本发明主要描述了端点放在不同管理域不同网守环境下的不同路由模式下不同域之间的GK，通过对GRQ/RRQ，ARQ/ACF/ARJ，LRQ/LCF/LRJ等信令执行过程，在二个不同的网守域环境下完成端点之间的安全密钥协商，为后续的呼叫信令建立起安全通道，以防止被伪造、完整性丢失及可能的机密性丢失。特别是如果端点支持基于公钥，如Diffie-Hellman或(类似于Diffie-Hellman椭圆曲线方法)等密钥交换时，目标域GK将认证源端点及使用与源GK共享或协商的安全策略对源GK进行认证。认证通过后，目标GK将返回含有认证值的Diffie-Hellman公钥与源网守标识符GKID。
本发明假定GK是一个安全模块，可实现密钥存贮，密码算法与机制协商，安全管理与维护接入，可靠性等。这些安全策略可以软件实现，也可硬件实现，或二者兼而有之。GK在这种安全模式下，可作为一个可信的中间实体，终止逐跳之间的安全关联。在密钥协商过程中，GK基于安全策略将生成或转发含有端点-端点之间的共享密钥，同时可以完成相关的认证与完整性检查，这可以通过对各信令内所包含的CryptoToken安全相关数据结构重新计算认证码实现。这里的共享密钥是安全密钥，是密码学算法安全参数的一部分。它可以通过口令导出，或者通过配置来分配或其它方法。
如图1所示，为根据本发明实施例所述跨域多网守分组网络密钥协商安全策略实现方法的多网守路由模式场景图，包括：主叫端点101(EpA)、主叫网守102(GkG)、中间网守103、被叫网守104(GkH)、被叫端点105(EpB)。
针对主叫端点101与主叫网守102、被叫网守104对密钥协商方法支持，如基于对称密码加密传输会话密钥，Diffie-Hellman(简称D-H)公钥密码实现会话密钥协商等，本发明实施例描述一种基于优先级安全策略，来灵活选择会话密钥分配方式。具体安全策略如下：
主叫端点101根据安全强度要求及所注册网守的情况，可以支持对称密码实现密钥协商，也可以支持公钥密码实现密钥协商方法。
主叫网守102根据本地安全策略，针对主叫端点101的安全请求，以主叫端点101的公钥密码方法为高优先级策略，尽量满足主叫端点101的安全请求。如果不满足，则重新与主叫端点101协商新的对称密码方法。
被叫网守104根据主叫网守102转发的端点安全请求，尽量满足主叫端点101或主叫网守102的基于公钥密码方法的安全请求，如果不满足，则与主叫网守102协商新的对称密码方法，并通过主叫网守102转发给主叫端点101。
主叫端点101针对所接收的安全策略协商结果，基于本地安全策略，决定是否继续以新协商的安全策略，进行后续信令交互。
本发明实施例提出了一种二端点间借助于各自所属网守来实现共享密钥协商，为呼叫信令及以后的H.245控制信令提供安全保障。
如图2所示，为根据本发明实施例所述跨域多网守分组网络密钥协商安全策略实现方法的多网守路由呼叫模式下安全策略实施过程图，其具体步骤为：
(步骤201)处于不同域网守管理的主叫端点与被叫端点向各自所属网守发送GRQ/RRQ(网守发现与网守注册请求)信令。
(步骤202)主叫、被叫所属网守向主叫、被叫端点发送GCF/RCF(网守发现请求响应与网守注册请求响应)或GRJ/RRJ(网守响应拒绝/注册响应拒绝)信令，完成网守所支持的呼叫模式与端点是否具备公钥密码方法实现密钥协商能力。
(步骤203)在呼叫被叫端点之前，主叫端点向其归属网守GkG发送ARQ消息，其中可以包含一个独立的ClearToken，其内tokenOID字段设置为支持所具有的密钥协商能力对象标识(以文本数字方式给出)，其他字段不使用。
(步骤204)主叫端点的网守GkG收到ARQ后，判断被叫端点(ARQ消息中的destinationInfo或者destCallSignalAddress表示)是否是自己管理域，如果不属于自己管辖的端点，则向被叫端点的网守发起LRQ消息，以查询被叫端点地址。主叫网守GkG安全策略规则是，如果主叫端点支持如Diffie-Hellman密钥协商等公钥方法，则在LRQ消息中，真接转发主叫端点的密钥协商请求。这可通过在生成的LRQ消息中，包含一个ClearToken来完成，其中的tokenOID设置为向被叫网守指示所需要的密钥协商能力对象标识符，而其他字段不使用。如果主被叫端点处于同一网守，则密钥协商方式同H.235附录I中所给出的。这里所基于的安全策略是，在GRQ/RRQ，GCF/RCF(或GRJ/RRJ)的信令交互中，网守对是否支持端点的公钥方法进行密钥协商进行了限制规定。如果允许端点支持公钥方法，则可以在后续的信令中，端点按公钥方法进行密钥协商，否则只能以对称密码方法进行会话密钥协商。
(步骤205)依据被叫网守GkH是否支持对主叫端点的公钥方法，而采取二种不同的策略规则。
(步骤206)GkH生成与EpA之间共享半公钥，并与EpA所生成的半公钥一起生成一个主、被叫端点所共享的会话密钥(或共享密钥)。
(步骤207)共享密钥分别被放入到返回给主叫网守GkG的LCF消息中的二个单独ClearToken中，分别用于主叫与被叫端点后面的通信安全所用。在这二个ClearToken中的共享密钥，分别通过网守-网守、网守-端点之间已有的安全加密机制进行保护，以防止传递过程的泄露。
(步骤208)主叫网守GkG转发GkH与主叫端点通过公钥方法协商的安全会话密钥，通过ACF消息返回给主叫端点EpA。从而完成了基于端点公钥方法实现会话密钥协商的过程。
(步骤209)当GkH不支持与端点的公钥方法生成主、被叫端点共享会话密钥时，则由GkH单独生成一个会话密钥，可以采用随机数产生的方式生成该会话密钥。
(步骤210)由于被叫网守GkH没有满足主叫网守转发的密钥协商请求方法，为了尽可能地完成密钥协商，GkH与主叫网守以对称密码方式保护其为主、被叫端点生成的共享密钥。并以LRJ消息返回给主叫网守GkG。主叫端点网守收到LRJ消息后，检验该消息中ClearToken的tokenOID标志，二个网守之间GkG根据前面所协商的安全策略解密出用于主叫端点ClearToken中的共享密钥，然后利用与主叫端点所预配置的安全策略重新产生一个含有加密共享密钥的用于主叫用户的令牌，同时复制LRJ消息中用于被叫端点的ClearToken，放入到返回给主叫端点的ARJ消息中并发送。
(步骤211)主叫网守根据LRJ消息，恢复出共享密钥，并在ARJ消息中，通过与主叫端点EpA所共享的安全策略加密保护该共享密钥或会话密钥。主叫端点收到ACF(或ARJ)消息后，提取与被叫端点所共享的秘密，用于后面的呼叫信令安全保护，如ITU-T H.235V3附录D的鉴权。
(步骤212)主叫端点EpA基于对称密码方法，在ARQ消息中，请求网守为其分配与被叫端点EpB共享密钥。
(步骤213)GkG基于本身是否支持公钥方法与被叫网守GkH共同协商，为主被叫端点协商出会话密钥。
(步骤214)GkG以LRQ消息，向GkH发出对称密码方法生成主、被叫端点之间共享的会话密钥(共享密钥)。
(步骤215)生成GkG-GkH会话密钥半公钥。
(步骤216)GkG以LRQ消息，向GkH发出公钥方法生成主、被叫端点之间共享的会话密钥(共享密钥)。
(步骤217)GkH基于本身是否支持公钥方法决定生成何种密钥。
(步骤218)被叫网守支持与主叫网守之间采用公钥方法，生成GkH-GkG会话密钥半公钥。
(步骤219)GkH以LCF消息，向GkG发出公钥方法生成的GkH-GkG会话密钥半公钥。
(步骤220)GkG将与被叫网守之间以公钥方法协商出会话密钥，以ACF消息，向EpA发出会话密钥，并采用在GRQ/GCF/GRJ(或RRQ/RCF/RRJ)信令交互阶段所协商的安全策略实施保护。
(步骤221)被叫网守不支持与主叫网守采用公钥方法，GkH生成会话密钥。
(步骤222)GkH以LRJ消息，向GkG发出对称密码方法生成的会话密钥。
(步骤223)GkG以ACF消息，向EpA发出对称密码方法方法生成的会话密钥。
(步骤224)当GkH不支持与端点的公钥方法生成主、被叫端点共享会话密钥时，则由GkH单独生成一个会话密钥。
(步骤225)，GkH与主叫网守以对称密码方式保护其为主、被叫端点生成的共享密钥。并以LRJ消息返回给主叫网守GkG。
(步骤226)主叫网守根据LRJ消息，恢复出共享密钥，并在ACF/ARJ消息中，通过与主叫端点EpA所共享的安全策略加密保护该共享密钥或会话密钥。
(步骤227)主叫端点收到ACF/ARJ消息后，提取与被叫端点所共享的秘密，向EpB发出呼叫建立请求消息Setup。
(步骤228)EpB向EpA发送Call Proceeding消息，响应呼叫建立请求消息同时执行步骤229。
(步骤229)EpB向GkH发送ARQ消息。
(步骤230)GkH向EpB响应ACF消息。
(步骤231)EpB向EpA发送Alerting消息。
(步骤232)EpB向EpA发送connect消息，建立呼叫连接。
步骤203至步骤211说明了主被叫网守对于主叫端点支持公钥方法时，如何为主、被叫端点完成会话密钥协商的安全策略。
步骤206到步骤208，说明被叫网守GkH支持与主叫端点EpA之间采用公钥方法进行会话密钥协商。
步骤209到步骤211，说明被叫网守GkH不支持与主叫端点EpA之间采用公钥方法进行会话密钥协商时，为动态完成密钥协商所采取的安全策略与步骤。
步骤212到步骤226中，说明了主、被网守支持或不支持公钥方法时，如何基于对称密码方法为主、被叫端点完成会话密钥协商。
步骤215-217中，GkG与GkH以公钥方法协商会话密钥。
步骤218-220说明了被叫网守支持与主叫网守之间采用公钥方法时的信令流程。
步骤221-223说明了被叫网守不支持与主叫网守采用公钥方法时采用对称密码方法生成并传输会话密钥的信令流程。
步骤224-226中，说明了GkH生成会话密钥的过程。
本发明实施例适用于H.323系统跨网守管理范围的直接路由及可选路由模式。假设主/被叫端点分别注册在不同的主/被叫网守上，通讯过程是在没有安全性保证的IP网络上进行。
实施本发明实施例的前提是：网守对其管理端点的所有RAS消息进行认证与完整性检查，端点对也对网守的RAS消息进行认证与完整性检查，从而使端点和所属网守之间达到相互信任目的，以便能检查出欺诈的实体，并将被欺诈可能性降到最小。
中间实体网守与网守之间也进行相互鉴别，避免网守域间的恶意攻击。在上述条件下，能够保证H.323端点之间RAS信道的安全性，以此为基础可实现呼叫信令的安全性。
本发明实施例用下列符号表示端点与网守的能力或二者组合，以及区分主叫/被叫端点所保存的共享密钥，符号表示的意义：
″I0″表示主叫端点不支持D-H，主叫网守或被叫网守不支持D-H密钥协商过程。
″I1″在返回主叫端点的独立ClearToken中使用，表示此ClearToken中包含会话密钥。
″I2″在被叫网守交给被叫端点独立ClearToken中使用，表示此ClearToken中包含会话密钥。
″I3″表示主叫端点不支持G-H过程，但主叫与被叫网守支持D-H过程。
″I4″表示主叫端点支持D-H过程，被叫网守支持D-H过程。
本发明实施例分别在端点与网守支持与不支持Diffie-Hellman(简称D-H)公钥方法的情况下，说明本发明在直接路由模式下，如何灵活选择会话密钥分配方式。
本发明虽然以H.323系统跨网守管理范围的直接路由模式为实施例，但是对于各种路由方式，本发明方法都是适用的。
假设主/被叫端点分别注册在不同的主/被叫网守上，通讯过程是在没有安全性保证的IP网络上进行。本实施例基于前面描述的安全策略给出直接路由呼叫模式下(DRC)几种有实用价值场景的会话密钥生成过程描述。
DRC I：主叫端点与主叫GK不支持D-H过程，只要求被叫GK产生会话密钥情况。
DRC II：主叫端点不支持D-H过程，主/被叫GK使用D-H过程协商会话密钥的情况。
DRC III：主叫端点支持D-H过程，主叫端点与被叫GK使用D-H过程协商会话密钥的情况。
下面根据RAS信令与呼叫信令的逻辑顺序来说明以上三种过程中具体协议实现过程。
1.GRQ/GCF或RRQ/RCF信令阶段：GK发现过程(GRQ/GCF)或/和注册过程(RRQ/RCF)中，端点向归属GK表明其是否支持公钥(D-H)过程。方法是在GRQ(或RQ)中包含一个独立ClearToken，其中tokenOID设置为“I0”，表明不支持DH过程，设置为“I4”，则表明支持。GK在收到GRQ(或RRQ)后识别出ClearToken中的tokenOID，根据管理策略决定是否支持此端点，回复相应GCF(或RCF)，在所包含的ClearToken中，对tokenOID设置判断如下：如果GK不支持端点D-H密钥协商过程，则设置为“I0”而不管该端点是如何设置的，这表明安全策略是由网守代为生成共享密钥；如果GK支持该端点的D-H过程，且网守的管理策略也支持该端点，则设置为“I4”。而主/被叫GK在以后为二边的端点分配会话密钥时，是由网守之间通过信令的协商，来选择具体哪一种密钥协商过程：DRC I、DRC II或DRCIII过程。
2.ARQ请求阶段：
在主叫EpA在使用直接路由模式呼叫被叫EpB之前，主叫端点EpA向归属GkG发送ARQ，其中包含一个独立的ClearToken，假设为CTA，其中的tokenOID设置如下：如果希望由GK代为生成安全共享密钥，则为“I0”，其他字段不使用；如果EpA希望采用D-H与被叫网守协商共享密钥，则将其D-H公钥放在的dhkey域中，tokenOID为“I4”，其他字段不使用。
3.LRQ请求阶段：
GkG在收到EpA发来的ARQ后，如果判断被叫EpB属于同一管理域(消息中的destinationInfo或destCallSignalAddress表示EpB)，共享密钥协商过程同附录I/H.235；如果判断不属于同一管理域，则发起LRQ消息向GkH查询EpB的地址。LRQ消息包含一个ClearToken，其内部各子域的设置规则由EpA能力与GkG所采用具体密钥协商规程而定，具体设置如下：
DRC I：当ARQ中的ClearToken的tokenOID为”I0”，GkG生成LRQ，包含一个ClearToken，其中tokenOID设置为”I0”，ClearToken的其他字段不使用，表明需要被叫GK分配会话密钥Kab。
DRC II：当ARQ中的ClearToken的tokenOID为”I0”，GkG生成LRQ，包含一个ClearToken，其中tokenOID设置为“I3”，表明期望与被叫GK使用D-H过程为二边端点协商出共享会话秘密。GkG产生并设置ClearToken中的dhkey作为DH公钥。
DRC III：当ARQ中的ClearToken的tokenOID为“I4”，应根据安全策略选择使用DRC III过程。GkG生成LRQ，其中包含从ARQ复制过来的ClearToken。
LCF确认
GkH收到LRQ后并识别出EpA与EpB支持这种呼叫模式，根据所含ClearToken的tokenOID执行不同密钥协商过程来生成基于呼叫的共享密钥Kab与二个独立的ClearToken。一个用于主叫网守GkG，称为CTg；另一个用于被叫端点EpB，称为CTb。这个Kab然后通过使用CTg与CTb将分别推送到GkG与EpB。具体做法如下：
DRC I：如果tokenOID为″I0″，表明主叫端点与网守都不支持D-H过程，要求被叫网守为其生成共享密钥。这种情形下，GkH随机产生Kab。为了加密Kab，首先，GkH产生随机的challenge，并用和GkG之间的共享密钥Kgh和challenge以及事先配置的密钥推导算法导出密钥EKgh。然后，GkH用EKgh加密Kab得到EKab1，并把EKab1和加密参数(加密算法和加密用初始化向量)一起，设置到CTg.h235Key.secureSharedSecret字段中，具体细节可参考H.235附录I，并设置CTg的tokenOID为“I0”表明被叫GK不支持D-H密钥协商。同时，GkH使用类似的过程产生另一个ClearToken，设置tokenOID为“I2”，称为CTb。最后，GkH生成LCF，其中包含CTg和CTb。
DRC II：这时的tokenOID为“I3”，表明网守之间支持D-H算法且安全策略允许使用D-H过程。如果GkH也支持D-H过程且安全能力相匹配，则GkH生成自己D-H公钥，并和LRQ内GkG的D-H公钥一起，使用D-H算法计算出会话共享密钥Kab。然后，使用与上面DRC I类似过程生成CTb，tokenOID为“I2”。最后，GkH生成LCF，其中包含CTb和一个独立ClearToken(tokenOID为“I3”)CTg，其中有设置好期望的DH公钥。
如果GkH不支持DH算法或安全策略不允许使用DH过程，则GkH应该使用DRC I过程生成LRJ。
DRCIII：当tokenOID为“I4”，若GkH支持DH算法且安全策略允许使用DH过程，则GkH开始与EpA协商会话密钥。首先，GkH生成期望的DH公钥，与从LRQ中获取的公钥一起，使用DH算法计算出会话密钥Kab。然后，使用与DRC I过程类似方法生成CTb，tokenOID为“I2”。最后，GkH生成LCF，其中包含CTb和一个独立ClearToken(tokenOID为”I5”)CTg，其中有设置好期望的DH公钥。
如果GkH不支持DH算法或安全策略不允许使用DH过程，则GkH应该使用DRC I过程生成LRJ。
5.ACF/ARJ确认
GkG收到LCF/LRJ后，检验消息中的CTg的tokenOID为“I3”时，采用D-H密钥协商算法计算出Kab，产生CTa，其内tokenOID设为“I1”。具体做法是：从独立ClearToken中获得GkH的DH共钥，与自己保存的DH共钥一同使用DH算法计算出会话密钥Kab；然后使用与下面相同方法生成CTa。最后，GkG生成ACF或ARJ，其中包含CTa(tokenOID为”I1”)和从LCF/LRJ复制过来的CTb(tokenOID为”I2”)。
如果CTg的tokenOID为“I0”时，首先，GkG通过CTg中的challenge、IV以及指定的密钥导出算法导出密钥EKgh；然后，GkG用EKgh解密EKab1得到Kab；最后产生CTa，其内tokenOID设为“I1”。CTa的生成做法如下：首先，GkG用GkG和EpA之间的共享密钥Kag和challenge以及指定的密钥导出算法导出密钥EKag。然后，GkG用EKag加密Kab得到EKab1，并把EKab1和加密参数(加密算法和加密用到的初始化向量IV)一起，设置到一个独立的CTa.h235Key.secureSharedSecret字段中。最后，GkG生成ACF/ARJ，其中包含CTa和从LCF/LRJ复制过来的CTb。
如果GkG收到的LCF消息中ClearToken的tokenOID为“I4”，则GkG生成ACF，其中包含从LCF中复制过来的所有ClearToken。
6.Setup
EpA收到ACF后，检验消息中独立ClearToken的tokenOID为“I4”，计算会话密钥。做法是，从ClearToken中获得被叫方的DH共钥，与自己保存的DH共钥一同使用DH算法计算出会话密钥Kab。其它情况则直接提取CTa，并根据CTa中信息和其与GkG的共享密钥Kag导出密钥EKag，然后使用EKag解密CTa.h235Key.secureSharedSecret.encryptedSessionKey得到密钥Kab。EpA创建Setup消息，把ACF消息中的CTb复制到Setup消息中，然后利用共享密钥Kab设置H235V3附录D鉴权信息。EpA直接向EpB发出呼叫建立请求消息Setup。
7.后面的呼叫信令设置：
EpB收到Setup消息后，提取CTb，并根据CTb中信息和其与GkH的共享密钥Kbh导出密钥EKbh，然后使用EKbh解密CTb.h235Key.secureSharedSecret.encryptedSessionKey得到密钥Kab；此时，EpB就可以使用Kab对Setup及后续的呼叫信令消息进行鉴权。
工业实用性
通过上述本发明实施例方法，基于本发明的安全策略，可动态协商出一个可信会话密钥，利用密码学将其与呼叫认证捆绑在一起，包括会话密钥刷新需求。本发明在实施过程中，采用的安全技术与现有标准相容，安全体系的布置也比较简单并且不假定任何附加的安全基础设施方法，诸如智能卡及复杂的管理协议。

Claims (11)

1.一种跨域多网守分组网络密钥协商安全策略实现方法，其特征在于，包括以下步骤：
(1)各端点分别与其归属的网守之间通过信令交互执行安全策略协商，根据各端点及其归属网守的密钥支持能力确定各端点的本地安全策略；
(2)主叫端点根据确定的本地安全策略向主叫网守发送密钥协商请求，主叫网守根据主叫端点的安全策略与自身的密钥支持能力，确定最高与最低优先级密钥协商规程，并按照最高优先级规程向被叫网守转发主叫端点的密钥协商请求；
(3)被叫网守根据自身的密钥支持能力，判断是否能够按照最高优先级规程来执行所述被转发的主叫端点的密钥协商请求，如果可以，则按照所述最高优先级规程执行密钥协商，如果不能，则按照所述确定的最低优先级规程执行密钥协商，并将协商结果通过主叫网守转发给主叫端点。
2.如权利要求1所述的方法，其特征在于，进一步包括步骤：
(4)主叫端点接收到所述协商结果后，基于本地安全策略，决定是否继续利用协商结果进行后续的信令交互。
3.如权利要求1所述的方法，其特征在于，所述步骤(1)中的信令交互过程为网守发现过程或/和注册过程。
4.如权利要求1所述的方法，其特征在于，所述密钥支持能力为是否支持公钥密钥协商。
5.如权利要求1所述的方法，其特征在于，所述步骤(1)包括：
(1-1)通过网守发现请求或/和注册请求消息，端点向其归属网守报告其是否支持公钥密钥协商；
(1-2)网守根据端点与自身是否支持公钥密钥协商，通过网守发现确认或/和注册确认消息，向端点返回确定的端点本地安全策略，其中：
当端点与网守任何一方不支持公钥密钥协商时，确定端点本地安全策略为：希望由网守代为生成共享密钥；
当端点与网守都支持公钥密钥协商时，确定端点本地安全策略为：希望与被叫网守通过信令协商来生成共享密钥。
6.如权利要求1所述的方法，其特征在于，步骤(2)所述主叫端点向主叫网守发送的密钥协商请求为接入请求消息，该消息中包含有所述主叫端点的本地安全策略信息。
7.如权利要求6所述的方法，其特征在于，当主叫端点本地安全策略为希望与被叫网守通过信令协商来生成共享密钥时，所述接入请求消息中进一步包含有公钥信息。
8.如权利要求6所述的方法，其特征在于，步骤(2)所述主叫网守根据主叫端点的安全策略与自身的密钥支持能力，确定密钥协商规程的优先级的步骤，包括：
当该主叫端点本地安全策略为希望由网守代为生成共享密钥，且主叫网守不支持公钥密钥协商时，确定密钥协商规程的最高与最低优先级规程为：由被叫网守产生会话密钥；
当该主叫端点本地安全策略为希望由网守代为生成共享密钥，且主叫网守支持公钥密钥协商时，确定密钥协商规程的最高优先级规程为：主叫网守与被叫网守使用公钥密钥协商过程产生会话密钥；最低优先级规程为：由被叫网守产生会话密钥；
当该主叫端点本地安全策略为希望与被叫网守通过信令协商来生成共享密钥时，确定密钥协商规程的最高优先级规程为：主叫端点与被叫网守使用公钥密钥协商过程产生会话密钥；最低优先级规程为：由被叫网守产生会话密钥。
9.如权利要求6所述的方法，其特征在于，所述接入请求消息中，进一步包括有被叫端点信息，主叫网守根据该被叫端点信息，确定被叫端点是否与主叫端点分属不同的管理域。
10.如权利要求1所述的方法，其特征在于，所述步骤(2)中，主叫网守按照最高优先级规程向被叫网守转发主叫端点的密钥协商请求的步骤，是通过地址解析请求发送的，该地址解析请求中包含有所述确定的最高优先级规程信息。
11.如权利要求8所述的方法，其特征在于，所述步骤(3)中，被叫网守判断是否能够按照最高优先级规程来执行所述被转发的主叫端点的密钥协商请求的步骤，包括：
当所述最高优先级规程为由被叫网守产生会话密钥时，则判断为可以按照最高优先级规程来执行密钥协商；
当所述最高优先级规程为主叫网守与被叫网守使用公钥密钥协商过程产生会话密钥时，如果被叫网守支持公钥密钥协商，则判断为可以按照最高优先级规程来执行密钥协商；如果被叫网守不支持公钥密钥协商，判断为不能按照最高优先级规程来执行密钥协商；
当所述最高优先级规程为主叫端点与被叫网守使用公钥密钥协商过程产生会话密钥时，如果被叫网守支持公钥密钥协商时，则判断为可以按照最高优先级规程来执行密钥协商；如果被叫网守不支持公钥密钥协商，则判断为不能按照最高优先级规程来执行密钥协商。
CN200680035570.8A 2006-02-16 2006-02-16 跨域多网守分组网络密钥协商安全策略的实现方法 Active CN101273571B (zh)

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 (2)

Publication Number Publication Date
CN101273571A CN101273571A (zh) 2008-09-24
CN101273571B true CN101273571B (zh) 2010-05-19

Family

ID=38371164

Family Applications (1)

Application Number Title Priority Date Filing Date
CN200680035570.8A Active CN101273571B (zh) 2006-02-16 2006-02-16 跨域多网守分组网络密钥协商安全策略的实现方法

Country Status (2)

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

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101729531B (zh) * 2009-03-16 2016-04-13 中兴通讯股份有限公司 网络安全策略分发方法、装置及系统
CN102223355B (zh) * 2010-04-19 2015-09-16 中兴通讯股份有限公司 一种安全通信协商方法和装置
CN104363208B (zh) * 2014-10-29 2018-08-07 中国建设银行股份有限公司 一种计算机集群间密钥管理方法及系统
CN105302564B (zh) * 2015-11-09 2018-08-31 中国人民解放军91655部队 网络办公软件服务控件及实现方法
CN107566115B (zh) * 2016-07-01 2022-01-14 华为技术有限公司 密钥配置及安全策略确定方法、装置
EP3756326B1 (en) * 2018-02-19 2021-08-04 Telefonaktiebolaget Lm Ericsson (Publ) Security negotiation in service based architectures (sba)

Citations (2)

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

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2763769B1 (fr) * 1997-05-21 1999-07-23 Alsthom Cge Alcatel Procede destine a permettre une communication cryptee directe entre deux terminaux de reseau radiomobile et agencements de station et de terminal correspondants
GB0322891D0 (en) * 2003-09-30 2003-10-29 Nokia Corp Communication method
CN100334829C (zh) * 2004-02-07 2007-08-29 华为技术有限公司 一种消息传输的实现方法
CN1705261A (zh) * 2004-05-28 2005-12-07 华为技术有限公司 一种端对端加密通讯系统及方法

Patent Citations (2)

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

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
JP特開2005-223421A 2005.08.18

Also Published As

Publication number Publication date
WO2007093079A1 (fr) 2007-08-23
CN101273571A (zh) 2008-09-24

Similar Documents

Publication Publication Date Title
US9537837B2 (en) Method for ensuring media stream security in IP multimedia sub-system
CN100592731C (zh) 端到端加密数据电信的合法侦听
JP5106682B2 (ja) マシン・ツー・マシン通信のための方法及び装置
KR101078455B1 (ko) 보안 인터넷 프로토콜 권한 관리 아키텍쳐에 대한 키 관리프로토콜 및 인증 시스템
Hwang et al. A self-encryption mechanism for authentication of roaming and teleconference services
US8533462B2 (en) Verifying cryptographic identity during media session initialization
KR20040104538A (ko) 보이스-오버-ｉｐ시스템들에 대한 미디어 스트림 암호화키들의 종단 간 보호
WO2005112338A1 (fr) Procede de distribution de cles
Asokan Anonymity in a mobile computing environment
CN101420413A (zh) 会话密钥协商方法、网络系统、认证服务器及网络设备
CN103534975A (zh) 根据公开密钥发现用于密钥管理的安全关联
WO2011022999A1 (zh) 一种终端对视频会议数据进行加密的方法及系统
CN103581118A (zh) 一种资源汇聚网关及跨平台授权方法与系统
CN101145908A (zh) 保障业务网络安全的系统、装置及方法
CN101273571B (zh) 跨域多网守分组网络密钥协商安全策略的实现方法
WO2007073659A1 (fr) Methode d'acces des terminaux a base de protocole h.323 applique a un reseau de paquets
CN102893579B (zh) 用于在通信系统中发放票据的方法、节点和设备
CN100571133C (zh) 媒体流安全传输的实现方法
WO2005104423A1 (fr) Procede de communication secrete entre deux points limites
CN101207477A (zh) 一种跨域多网守端到端会话密钥协商方法
CN100544247C (zh) 安全能力协商方法
CN110035083A (zh) 基于会话密钥的通信方法、设备及计算机可读存储介质
CN102025485B (zh) 密钥协商的方法、密钥管理服务器及终端
CN101207480A (zh) 一种跨域多网守端到端会话密钥协商方法
CN100382484C (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