在ip多媒体业务子系统网络中保障媒体流安全性的方法

文档序号:7610724阅读:128来源:国知局
专利名称:在ip多媒体业务子系统网络中保障媒体流安全性的方法
技术领域
本发明涉及通信网络中的媒体流安全技术,尤其涉及在IP多媒体业务子系统(IMS)网络中保障媒体流安全性的方法。
背景技术
IMS作为固定和移动网络的核心会话控制层,已成为目前业界讨论的重点,在3GPP以及TISPAN标准中定义了很多IMS相关的规范,包括网络架构、接口、协议等各个方面,其中安全是一个3GPP及TISPAN考虑的一个重要方面,目前规范中从安全的角度将IMS网络划分为接入域和网络域,并分别定义了接入域和网络域的安全规范,IMS网络的安全模型如图1所示。模型中定义了需要提供安全的接口,并在规范中有比较详细的描述,但这些都是针对IMS网络中控制面定义的,即如何保证IMS网络中会话协议的安全,而没有提到如何保证IMS网络中媒体面的安全,事实上,媒体面的安全也是非常重要的,否则会导致用户在通话过程中媒体流被篡改或窃听,导致用户服务质量的下降或机密信息的泄漏。
现有技术提出了一种保护IMS网络中媒体流的方案,其基本思路是在IMS网络架构中引入媒体流代理(RTP Proxy);通过GBA(也是3GPP规范中定义的一种通用的认证与密钥分配模型)方式实现用户终端(UE)和RTP Proxy的共享密钥;通过该共享密钥,UE和RTP Proxy之间实现对媒体流的机密性和完整性保护,实现媒体流在接入域的安全;媒体流在网络域的安全可以有两种方式,一是认为在网络域内网络是可信的或安全的,在RTP Proxy之间不提供安全保护;二是利用3GPP IMS网络域安全机制,通过IPSec ESP协议对RTP Proxy之间的媒体流进行保护。
GBA的架构模型如图2所示,图3是GBA模型在媒体流密钥分配中的应用。在该应用中将会话发起协议服务器(SIP Server,如3GPP IMS网络中定义的P-CSCF,其中P-CSCF为Proxy CSCF,即代理-呼叫会话控制功能))和RTPProxy看作一个整体,作为GBA中的网络应用功能实体(NAF),SIP Server从BSF(Bootstrapping Server Function)获取存储在BSF中的NAF和SIP Client共享的密钥,SIP Server再通过其它接口Is将密钥送给RTP Proxy,从而实现SIPClient和RTP Proxy之间的媒体流安全密钥共享。
在GBA模型中,网络应用功能(NAF)和BSF(Bootstrapping Server Function)是逻辑功能实体,所有应用服务器(AS)甚至呼叫会话控制功能(CSCF)实体都有可能作为NAF去利用GBA过程获取和UE之间的共享密钥;同样,具体实现BSF功能的可能是任何设备,如CSCF实体、用户归属服务器(HSS)、AAAServer和Web Portal等。
上述方案无疑是解决IMS网络媒体流安全一种比较可行的方案,但该方案存在如下缺点上述方案将媒体流划分为三段a、主叫SIP Client(UE)-主叫RTP Proxy;b、主叫RTP Proxy-被叫RTP Proxy;c、被叫RTP Proxy-被叫SIP Client(UE);媒体流的安全是通过分段的方式来保证的,结果导致媒体流在传输过程中需要经过三次加解密(即使认为主叫RTP Proxy和被叫RTP Proxy之间不需要提供安全保护,也需要二次加解密),而事实上加解密过程对于系统的性能带来极大的负担,导致系统的性能降低,同时增大了媒体流在网络传输过程中的延迟,使得媒体流服务质量的降低,特别是服务质量要求较高的实时语音业务。
此外,由于存在多次的加解密,存在加密信息泄漏的风险,而且在多次通话过程中,SIP Client和RTP Proxy之间采用同样的密钥进行加解密,也增大了加密媒体流被解密的可能。

发明内容
本发明提供一种在IMS网络中提高端到端媒体流安全性的方法,以解决现有技术中因端到端的媒体流需要多次加密和解密而导致安全性和媒体流服务质量降低的问题。
为解决上述问题,本发明提供以下技术方案一种在IP多媒体业务子系统网络中保障媒体流安全性的方法,包括如下步骤A、IMS网络中主叫或被叫注册的网络设备为主叫或被叫分配端到端的媒体流安全密钥,并由分配密钥的网络设备将媒体流安全密钥传送给对方所属的网络设备;B、所述主叫和被叫所属的网络设备分别利用与用户终端之间共享的会话密钥对所述媒体流安全密钥加密,并通过会话报文分别传送给主叫和被叫;C、主叫和被叫分别利用本端与所属网络设备之间共享的会话密钥解密出端到端的媒体流安全密钥,并利用该密钥加密或解密媒体流。
其中主叫和被叫所属的网络设备还根据主叫和被叫提供的安全能力指定主叫和被叫之间媒体流安全能力。
若需要对媒体流进行监听时,网络设备还将分配的端到端媒体流安全密钥传递给监听设备,该监听设备利用该密钥对加密的媒体流解密,实现对媒体流的监听。
主叫和被叫所属的网络设备之间在网络域的会话报文中以明文方式传送媒体流安全密钥,或者通过IMS网络域的安全机制传送媒体流安全密钥。
所述端到端的媒体流安全密钥为加密密钥或完整性保护密钥。
本发明由可以作为网络设备应用服务器或CSCF等网络设备为主叫和被叫分配端到端的媒体流安全密钥,在媒体流传输过程中只需主被叫终端对媒体流进行一次加密或解密,所以,对IMS网络设备基本上没有性能压力,同时有利于保证媒体流的服务质量;在安全性方面,由于密钥是在每次会话中动态分配的,会话结束后就失效了,因此本发明同时具有很高的安全性。
由于在协商媒体流安全密钥的同时还可交互协商主叫和被叫的安全能力,因此,能够实现主叫和被叫之间端到端的安全联盟的动态建立。


图1为现有的IMS网络安全模型示意图;图2为现有的GBA模型示意图;图3为GAB在媒体流安全中的应用示意;图4、图5为本发明的流程图。
具体实施例方式
IMS网络中定义的呼叫会话控制功能(CSCF)实体用于完成呼叫和会话时的控制和路由等功能,P/S/I-CSCF是为了实现不同的功能而区分的,代理-呼叫会话控制功能(P-CSCF)是完成用户UE的接入,所有UE通过P-CSCF接入网络;业务-呼叫会话控制功能(S-CSCF)提供会话控制和路由等核心功能;查询-呼叫会话控制功能(I-CSCF,Interrogating-CSCF)是用于S-CSCF的选择及不同运营商或不同区域网络之间的互通,实现网络屏蔽等功能,如可能作为不同运营商之间的唯一出入口;IMS网络中的应用服务器(AS)则是为用户提供业务,如呼叫等待、会议、即时消息等各种应用,不同的应用可能是不同的AS,S-CSCF实体负责根据业务情况将用户的会话请求转到不同的AS去处理。
为了避免在传输过程中对媒体流进行多次加密和解密,本发明直接在会话发起协议客户端(SIP Client)即主叫用户端和被叫用户终端(UE)之间建立安全联盟,在主叫和被叫之间直接进行加解密实现对媒体流的安全保护,即实现端到端媒体流安全保护。
端到端媒体流安全密钥协商可以通过两种方式实现,第一种方式是由CSCF实体分配端到端的媒体流安全密钥,第二种方式是由应用服务器(AS)来分配端到端的媒体流安全密钥。媒体流安全密钥为加密密钥CK或完整性保护密钥IK。
参阅图4所示,采用第一种方式实现端到端媒体流安全保护过程如下步骤1、在会话建立过程中,主叫或被叫UE注册的CSCF实体中的S-CSCF根据UE的签约信息或AS在会话报文中对媒体流安全保护的指示,决定本次会话媒体流是否需要保护,如果需要保护,则由该S-CSCF根据签约信息中要求的保护方式分配端到端的媒体安全密钥。如果要求保护的方式是加密方式,则分配端到端的加密密钥CK,如果要求的保护方式是完整性保护方式,则分配端到端的完整性保护密钥IK。
步骤2、主叫或被叫的S-CSCF分配媒体流安全密钥后,在网络域的会话报文中传递给对方UE所属的S-CSCF,主叫和被叫所属的S-CSCF再将密钥在会话报文中分别传送给主叫/被叫的P-CSCF。
若认为网络域内是可信的或安全的则可以明文方式传递密钥(即不对密钥进行任何加密保护),当然也可通过IMS网络域的安全机制来传递密钥。
步骤3、主叫和被叫UE接入的P-CSCF根据UE在注册AKA过程中协商得到的UE和P-CSCF之间的加密密钥对媒体流安全密钥进行加密。
步骤4、P-CSCF将加密后的媒体流安全密钥在会话报文中以密文的形式传递给主、被叫UE,保证媒体流安全密钥在非安全的接入侧网络中是安全传输的,主被叫UE通过和P-CSCF之间共享的会话密钥解密后获取主被叫UE之间端到端的媒体流安全密钥。
步骤5、主叫UE和被叫UE之间根据会话建立过程中协商的安全联盟(SA),用端到端的安全密钥对媒体流报文进行加密或完整性保护后传送,完成端到端的媒体流安全保证功能。
若只有主叫UE到被叫UE的媒体流需要保护,则主叫UE采用端到端的媒体流安全密钥对媒体流进行加密或完整性保护后发送给被UE,被叫UE则利用媒体流安全密钥认证及解密收到的媒体流,对发送的媒体流不用加密;若只有被叫UE到主叫UE的媒体流需要保护,其处理过程与此相同;若主叫UE和被叫UE发送的媒体流均需要保护,则双方均利用媒体流安全密钥对媒体流加密或完整性保护后发送,同时利用媒体安全密钥对收到的媒体流进行解密。
参阅图5所示,采用第二种方式实现端到端媒体流安全保护过程如下在发起会话前,主被叫UE在注册认证AKA过程中结合GBA流程同时实现了UE与网络侧应用层(NAF)安全密钥的协商,在后续UE发起或响应会话请求时,将在会话报文中或与NAF的交互过程中携带B-TID标识(UE和NAF之间或通过其它方式实现了应用层安全密钥的协商,具体方式不限于上述描述)。
步骤10、在会话建立过程中,主叫或被叫UE所属的应用服务器(AS)根据业务的需求或用户的签约信息等决定本次会话媒体流是否需要保护,如果需要保护,则根据签约信息或业务需求中要求的保护方式分配端到端的媒体安全密钥。如果要求保护的方式是加密方式,则分配端到端的加密密钥CK,如果要求的保护方式是完整性保护方式,则分配端到端的完整性保护密钥IK。
步骤11、通过网络域的安全机制,分配密钥的AS将媒体流安全密钥进行加密后在会话报文中传递给对方所属的AS。
若认为网络域是可信的,在网络域内也可以明文传输密钥。
步骤12、主叫和被叫所属的AS根据UE在会话交互报文中携带的B-TID标识,到BSF请求NAF与UE之间共享的应用层安全密钥。
应用层安全密钥也可保存在用户归属服务器(HSS)上,此时,主叫和被叫所属的AS则根据UE在会话交互报文中携带的B-TID标识到该HSS上获取密钥(当然,还可通过其它方式实现AS和UE之间的应用层密钥分配)。
步骤13、主叫和被叫所属的AS分别利用与UE之间共享的应用层安全密钥对媒体流安全密钥进行加密,并分别在会话报文中传递给主叫和被叫UE。
步骤14、主叫和被叫UE利用和AS共享的应用层密钥解密,获取主叫和被叫UE之间的端到端的媒体流安全密钥。
步骤15、主叫UE和被叫UE之间根据会话建立过程中协商的安全联盟(SA),用端到端的安全密钥对媒体流报文进行加密或完整性保护后传送,完成端到端的媒体流安全保证功能。
若只有主叫UE到被叫UE的媒体流需要保护,则主叫UE采用端到端的媒体流安全密钥对媒体流进行加密或完整性保护后发送给被UE,被叫UE则利用媒体流安全密钥认证及解密收到的媒体流,对发送的媒体流不用加密;若只有被叫UE到主叫UE的媒体流需要保护,其处理过程与此相同;若主叫UE和被叫UE发送的媒体流均需要保护,则双方均利用媒体流安全密钥对媒体流加密或完整性保护后发送,同时利用媒体安全密钥对收到的媒体流进行解密。
在步骤12中,应用服务器(AS)和用户终端(UE)之间的共享密钥也可以通过现有技术中的其它方式获得。
媒体流报文经过加密或完整性保护处理后的报文格式可以参考IETF的Draft“Security RTP”中对RTP报文格式的定义,该报文格式与RTP的报文格式基本相同,定义了报文加密范围、认证范围及加密和认证信息在报文中的位置等信息。
在会话建立过程中协商媒体流安全密钥的同时,可以同时交互协商主被叫UE的安全能力,如支持的加密或完整保护算法等信息,流程和机制与RFC 3329Security Mechanism Agreement for the Session Initiation Protocol(SIP)中的描述类似,主被叫的AS/S-CSCF在决定对媒体进行安全保护及分配安全密钥的同时,可以根据双方提交的安全能力完成主被叫UE之间媒体流安全能力的指定,从而完成主被叫UE之间端到端的安全联盟的动态建立。
虽然媒体流传输采用端到端的加密,但由于媒体流安全密钥是由AS/S-CSCF分配的,因此当对加密传输的媒体流有监听的需求时,AS/S-CSCF在对媒体流分配端到端的安全密钥的同时,可以通过将会话路由经过监听设备后再发给被叫来控制将用户的媒体流中继到监听设备,并在与监听设备会话报文的交互过程中将加密密钥CK送给监听设备,监听设备通过对加密的媒体流解密实现对媒体流的监听。
显然,本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样,倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内,则本发明也意图包含这些改动和变型在内。
权利要求
1.一种在IP多媒体业务子系统网络中保障媒体流安全性的方法,其特征在于包括如下步骤IP多媒体业务子系统(IMS)网络中主叫或被叫注册的网络设备为主叫或被叫分配端到端的媒体流安全密钥,并由分配密钥的网络设备将媒体流安全密钥传送给对方所属的网络设备;所述主叫和被叫所属的网络设备分别利用与用户终端之间共享的会话密钥对所述媒体流安全密钥加密,并通过会话报文分别传送给主叫和被叫;主叫和被叫分别利用本端与所属网络设备之间共享的会话密钥解密出端到端的媒体流安全密钥,并利用该密钥加密或解密媒体流。
2.如权利要求1所述的方法,其特征在于,主叫和被叫所属的网络设备还根据主叫和被叫提供的安全能力指定主叫和被叫之间媒体流安全能力。
3.如权利要求1所述的方法,其特征在于,若需要对媒体流进行监听时,网络设备还将分配的端到端媒体流安全密钥传递给监听设备,该监听设备利用该密钥对加密的媒体流解密,实现对媒体流的监听。
4.如权利要求1所述的方法,其特征在于,主叫和被叫所属的网络设备之间在网络域的会话报文中以明文方式传送媒体流安全密钥,或者通过IMS网络域的安全机制传送媒体流安全密钥。
5.如权利要求1至4任一项所述的方法,所述端到端的媒体流安全密钥为加密密钥或完整性保护密钥。
6.如权利要求5所述的方法,其特征在于,若网络设备为呼叫会话控制功能(CSCF)实体,该CSCF实体根据主叫用户或被叫用户的签约信息,或应用服务器在会话报文中对媒体流安全保护的指示确定分配加密密钥或完整性保护密钥。
7.如权利要求5所述的方法,其特征在于,由主叫或被叫所在CSCF实体中的业务-呼叫会话控制功能(S-CSCF)分配密钥,并在会话报文中将密钥送给对端所在的S-CSCF,主叫和被叫所在的S-CSCF再分别在会话报文中将密钥送给主叫和被叫的代理-呼叫会话控制功能(P-CSCF),主叫和被叫的P-CSCF通过和终端之间共享的会话密钥对媒体流安全密钥加密后在会话报文中传送给主叫和被叫。
8.如权利要求5所述的方法,其特征在于,若网络设备为应用服务器(AS),则根据主叫用户或被叫用户的签约信息或业务要求确定分配加密密钥或完整性保护密钥。
9.如权利要求8所述的方法,其特征在于,所述应用服务器利用主叫和被叫会话报文中携带的B-TID(Bootstrapping procedure Transaction identifier)标识,从BSF(Bootstrapping Server Function)或用户归属服务器(HSS)获取与用户终端之间共享的加密密钥。
全文摘要
本发明公开了一种在IMS网络中保障媒体流安全性的方法,该方法为IMS网络中主叫或被叫注册的网络设备为主叫或被叫分配端到端的媒体流安全密钥,并由分配密钥的网络设备将媒体流安全密钥通过会话报文传送给对方所属的网络设备;所述主叫和被叫所属的网络设备分别利用与用户终端之间共享的会话密钥对所述媒体流安全密钥加密,并通过会话报文分别传送给主叫和被叫;主叫和被叫分别利用本端与所属网络设备之间共享的会话密钥解密出端到端的媒体流安全密钥,并利用该密钥加密或解密媒体流。
文档编号H04L9/12GK1801698SQ20051000009
公开日2006年7月12日 申请日期2005年1月7日 优先权日2005年1月7日
发明者严军 申请人:华为技术有限公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1