CN102223356B - 基于密钥管理服务器的ims媒体安全的合法监听系统 - Google Patents

Abstract

本发明公开了一种基于密钥管理服务器的IMS媒体安全的合法监听系统，包括推(PUSH)和拉(PULL)两种系统实现方案；其中，PULL模式的系统包括：信令截取单元，用于从所述IMS网元获得监听数据，并将其发送给所述KMS；KMS与信令截取单元相连，用于对所述监听数据进行解析，并将解析结果返回信令截取单元。采用本发明，能实现对基于KMS的IMS媒体安全的合法监听。

Description

基于密钥管理服务器的IMS媒体安全的合法监听系统

技术领域

本发明涉及网络通信安全技术，尤其涉及一种基于密钥管理服务器(KMS，Key Management Servicer)的IP多媒体子系统(IMS)媒体安全的合法监听系统。

背景技术

基于KMS的安全通信技术方案是一种保护媒体流端到端的技术方案，其是针对与信令和传输网络无关的具有更高要求的安全需求而提出的。

该基于KMS的安全通信技术方案是基于使用KMS和一个票据(Ticket)”的概念来实现的，其中，KMS用于负责提供安全、用户鉴权以及密钥生成等功能。KMS在IMS媒体面安全中，作为第三方服务器，主要起到发放Ticket，解析Ticket的作用，KMS也可以称为密钥管理系统。

所述基于KMS的安全通信技术方案主要是针对具有较高安全需求的用户，该基于KMS的安全通信技术方案可以完全不依赖于信令面的安全，也就是说，即便信令面的数据被窃取，攻击者也无法获取通话双方的媒体密钥，从而为用户提供较高的安全保障。然而，该基于KMS的安全通信技术方案需要增加新的网元，即增加一个KMS。

考虑到用户设备(UE)和IMS中各个网元的参与，基于KMS的安全通信技术方案可参见图1所示的系统架构。其中，代理-呼叫会话控制功能(P-CSCF)和服务-呼叫会话控制功能(S-CSCF)都属于IMS网元。

该基于KMS的安全通信技术方案的实现流程，包括如下步骤：

步骤1、用户A(即UE A)与KMS用通用认证机制(GBA)机制建立安全通道。

这里，GBA是3GPP定义的一种基于移动通信网络、轻量级的安全基础设施，可以为应用层业务提供统一的安全认证服务。KMS作为一个可信任的第三方，能实现密钥的管理和分发功能，KMS所在的位置还可以采用网络应用功能(NAF)。

步骤2、用户A向KMS申请一个用于与用户B(即UE B)通讯的媒体密钥和一张加密的Ticket(包括媒体密钥和用户B的信息)。

步骤3、KMS生成媒体密钥和加密的Ticket发送给用户A。

步骤4、用户A通过IMS核心网发送通讯请求和加密的Ticket给用户B。

步骤5、用户B接收到用户A发送的通讯请求和加密的Ticket。

步骤6、用户B与KMS用GBA机制建立安全通道。

步骤7、用户B发送接收到的加密的Ticket给KMS，请求得到Ticket中的媒体密钥。

步骤8、KMS解密用户B发来的Ticket，验证用户B和Ticket中的被叫用户信息是否一致，如果一致，发送Ticket中的媒体密钥给用户B。

步骤9、用户B获得媒体密钥后，接受用户A的通讯请求，这样用户A，用户B就可用这个媒体密钥进行通讯了。

以上所述的安全通信技术的解决方案是采用MIKEY-Ticket密钥协商机制来实现。

MIKEY-Ticket密钥协商机制是用来扩充MIKEY(RFC3830)协议的一种新的模式，这个新的模式使用了KMS和Ticket的概念。MIKEY-Ticket对MIKEY协议的扩展的需求来源于爱立信公司的基于Ticket的系统(TBS)方案，该方案中使用了Ticket这一概念，而实际中，该Ticket实体没有一个具体的协议来承载，使之能在信令中传输。在RFC4568的会话描述协议(SDP)的密钥协商协议扩展中，SDP已经能支持传输MIKEY，让MIKEY支持Ticket，则问题迎刃而解。

MIKEY-Ticket机制中包含三次交互，如图2所示，分别为：票据请求(TicketRequets)；票据传输(Ticket Transfer)和票据解决(Ticket Resolve)。

在图2中，用户I表示发起会话用户，用户R表示应答会话用户，KMS表示密钥管理服务器。下面针对上述三种交互过程分别进行详细说明，其中交互参数中可分为三类表示方式，即[]表示该参数可选，()表示可含一个或超过一个该类参数，{}表示不含或含超过零个该类参数。

一、针对Ticket Request而言，首先会话发起方即用户I向KMS发送一个REQUEST_INIT消息，用于向KMS请求一个Ticket，该REQUEST_INIT消息中包含了会话信息(例如，被呼叫者的标识)，并且这个REQUEST_INIT消息由基于用户I和KMS的共享密钥的消息认证码(MAC)来保护。

Ticket Request分为两种模式：1、共享密钥；2、公私钥机制。由于公私钥机制需要PKI的支持而不被采用，这里只介绍共享密钥模式。该REQUEST_INIT消息中所带的参数具体见图3所示，包括：HDR，T，RAND，[IDi]，[IDkms]，(IDre)，{SP}，IDtp，[KEMAC]，[IDpsk]，V，其中：

HDR表示消息头，T表示时间戳，RAND表示随机数；

IDi包含发送方的标识，这个标识一般存在Ticket中的“发送到”字段，由于发送方的标识可以从消息的发送方字段读取到，所以在REQUEST_INIT消息中该参数有时可以省去；

IDkms应包含在该消息中，但如果KMS只有一个惟一标识的时候可省；

IDre为接收方的标识，可为单个用户或者一组用户。如果超过一个接受方时，每个接收方的标识都必需放在一个单独的ID载荷中；

IDtp是所希望采用的Ticket策略的标识；SP为安全策略载荷；

KEMAC为密钥数据传输载荷，简单说就是用来存放传输各个密钥的地方，这里KEMAC＝E(encr_key，[MPK]||{TGK|TEK})，其中MPK(MIKEYProtection Key)为MIKEY消息保护密钥，即用encr_key将MPK，TGK或者TEK加密，TGK可以不止一个，encr_key即由PSK生成，该参数可选；

IDpsk不是必需参数，只有当PSK超过一个，需要指定是使用哪个PSK时使用；V是验证载荷，存放相应MAC值。

如果发起方被认证合法发起这个请求，那么KMS产生所需要的密钥，并将这些密钥进行编码放在Ticket中，在REQUEST_RESP消息中返回Ticket给发起方用户I，该消息中的具体参数见下图4所示，包括：HDR，T，[IDkms]，[IDtp]，[TICKET]，[KEMAC]，V，其中有[]的参数均为可选，其中Ticket包含Ticket类型以及Ticket数据，Ticket类型和数据均取决于IDtp。

上述T icket Request这一交互流程是可选的，当用户自身有能力产生Ticket而无需和KMS进行交互时，Ticket Request步骤可省略。

二、针对Ticket Transfer而言，收到KMS发回的REQUEST_RESP消息后，用户I将Ticket放在TRANSFER_INIT消息中发给被叫方用户R，即图2中步骤13所示。如果用户R检查策略为可接受，它就把Ticket放在RESOLVE_INIT消息中转发给KMS，让KMS返回包含在ticket中的密钥信息，见图2中的步骤14，其中RESOLVE_INIT消息也采用基于用户R和KMS的共享密钥的MAC保护。基于Ticket的类型，步骤14也是可选的，仅在用户R离开KMS的协助无法或者Ticket中所包含信息时使用。TRANSFER_INIT和RESOLVE_INIT消息中具体参数分别如图5，6所示：

TRANSFER_INIT消息中的IDi与IDr参数在有其他途径可以获取发送方和接收方的标识时，在该消息中可不包含。在最后面的验证载荷中，验证密钥auth_key由MPK生成。由于发送方和接收方此时并没有共享密钥，接收方不能在Ticket在处理前验证自己从接收方收到的消息，所以接收方首先需要检查自己接受的策略，如果所收到的消息中的IDtp自己不能接受，则拒绝该消息，不再与KMS进行交互。这也是提前预防对KMS的DoS攻击的一个方法。

三、针对Ticket Resolve而言，在RESOLVE_INIT消息中，Ticket载荷携带需要被KMS解密的Ticket，IDtp和IDi载荷必需和TRANSFER_INIT中相应参数一致。V是验证载荷，验证密钥auth_key由PSK生成。

KMS收到RESOLVE_INIT消息后，验证用户R是否是合法接受者，如果是，则KMS取回在Ticket中的密钥和其他信息，并给用户R发送RESOLVE_RESP消息，如果KMS不能正确解析收到的消息或者发送RESOLVE_INIT的用户R未通过验证，则KMS应该返回相应的错误消息。KMS在RESOLVE_RESP消息中将相关密钥和其他附加信息一起发给用户R，参见图2中的步骤15。

该RESOLVE_RESP消息中的具体参数见图7：其中HDR除了消息类型，下一个载荷以及V标签外，其他头部载荷需和RESOLVE_INIT消息中的头一致，时间戳类型和值需和RESOLVE_INIT消息中一致，KEMAC＝E(encr_key，MPK||[MPK]||{TGK|TEK})。如果是Forking情况，KMS则需要两个分叉MPK和多个TGK。这种情况下，第一个MPK用来保护TRANSFER_INIT消息，而第二个MPK用来保护TRANSFER_RESP消息。用来生成不同分叉密钥的修改因子包含在IDmod载荷中。

用户R收到该RESOLVE_RESP消息后，发送TRANSFER_RESP消息给用户I作为确认，见图2中的步骤16，在TRANSFER_RESP消息中可能包含用于密钥生成的一些信息，具体参数见图8。实际中的信令流程需要依赖具体的Ticket类型和KMS域的策略而定，其中，Ticket的类型由Ticket的策略决定。

以下对MIKEY-Ticket各密钥的派生方法进行说明：

针对非Forking场景下MIKEY-Ticket中使用的各层密钥以及它们之间互相生成的关系而言，TPK为保护Ticket的密钥，一般采用仅为KMS自己所知的密钥，Ticket中的随机数RAND由KMS生成，基于该随机数RAND和TPK，KMS使用密钥生成函数KDF生成相应的MPK、TGK及SALT，Ke为根据Pre-shared key生成的加密ticket中密钥材料的加密密钥，用Ke加密MPK、TGK和SALT放入KEMAC载荷中。由pre-shared key再生成用于验证的密钥Ka，计算出MAC值放在MAC载荷中。

在发送方发送TRANSFER_INIT消息给接收方时，它使用自己生成的RAND和从KMS获得的MPK基于KDF生成验证密钥Ka，用来计算出MAC值，根据HDR中的信息，随机数RAND以及TGK使用KDF生成TEK，和KEMAC中包含的SALT一起作为SRTP协议的密钥输入。

针对Forking场景下MIKEY-Ticket中密钥的生成而言，Forking情况下与非Forking情况的惟一的区别在于KMS中会为每一个终端生成一个修正因子MOD，用来生成新的MPK和TGK。基于MOD和MPK生成分叉MPK，该分叉MPK和HDR中的参数以及随机数RAND生成验证密钥Ka，用来计算MAC。基于MOD，HDR中的参数，随机数RAND和TGK生成分叉TEK，该TEK和KEMAC中的SALT作为SRTP协议的密钥输入。

由于各国法律都有规定，执法部门必须要能力对任何通话进行合法监听，所以基于KMS的端到端媒体安全解决方案也必须满足合法监听的需求。

目前公开成为标准的IMS控制面的合法监听解决方案如图9所示，包括：

监听中心(LEMF)、传送单元(DF2)、管理实体(ADMF)、被监听对象(Intercepted Subscriber)、与被监听对象通话一方(Other party)、P-CSCF、S-CSCF；LEMF通过P-CSCF和S-CSCF对Intercepted Subscriber进行监听。

由于该方案没有包含KMS网元，而仅仅从IMS核心网元截取数据，所以不具备对基于KMS的媒体安全机制的监听能力，从而无法实现对基于KMS的IMS媒体安全的合法监听。

发明内容

有鉴于此，本发明的主要目的在于提供一种基于KMS的IMS媒体安全的合法监听系统，能实现对基于KMS的IMS媒体安全的合法监听。

为达到上述目的，本发明的技术方案是这样实现的：

一种基于密钥管理服务器KMS的IMS媒体安全的合法监听系统，该系统包括：管理实体(ADMF)、IP多媒体子系统(IMS)网元和监听中心(LEMF)；该系统还包括：KMS和信令截取单元：

所述ADMF，用于向所述KMS发出监听命令；

所述KMS，与所述ADMF相连，用于从所述ADMF接收所述监听命令后，向所述信令截取单元发送监听数据；

所述信令截取单元，与所述KMS相连，用于将所述监听数据发送给LEMF；

所述信令截取单元或LEMF，将从所述信令截取单元中获得的监听数据与从IMS网元获得的监听数据进行关联；

所述LEMF，根据关联后的监听数据进行监听。

其中，所述信令截取单元单独设置或者与IMS网元中的信令截取单元DF2合设。

其中，所述信令截取单元与IMS网元中的信令截取单元DF2合设的情况下，

合设后的信令截取单元，用于将从所述IMS网元和所述KMS截取的监听数据先进行信息关联后，再发送给所述LEMF；或者，将从所述IMS网元和所述KMS截取的监听数据直接发送给所述LEMF，由所述LEMF进行信息关联。

其中，所述信息关联所采用的信息包括以下之一或任意组合：时间戳、呼叫方的用户地址、接收方的用户地址。

其中，所述信令截取单元单独设置的情况下，

所述IMS网元的信令截取单元DF2，用于将从所述IMS网元截取的监听数据发送给所述LEMF；

所述信令截取单元，用于将从所述KMS截取的监听数据发送给所述LEMF；

所述LEMF根据从DF2及所述信令截取单元中接收到的数据，进行信息关联。

其中，所述信息关联所采用的信息包括以下之一或任意组合：时间戳、呼叫方的用户地址、接收方的用户地址。

一种基于密钥管理服务器的IMS媒体安全的合法监听系统，该系统包括：ADMF、IMS网元和LEMF；其特征在于，该系统还包括：KMS和信令截取单元，

所述信令截取单元，用于从所述IMS网元获得监听数据，并将其发送给所述KMS；

所述KMS，与所述信令截取单元相连，用于对所述监听数据进行解析，并将解析结果返回信令截取单元。

其中，所述信令截取单元为IMS网元中的信令截取单元DF2的情况下，所述DF2，用于当所述监听数据发送给所述KMS，所述监听数据包含的MIKEY-Ticket信息。

其中，所述DF2将所述监听数据中包含的MIKEY-Ticket信息发送到所述KMS；

所述KMS，进一步用于根据所述MIKEY-Ticket信息解析，并将解析结果返回给所述DF2。

其中，所述信令截取单元为IMS网元中的信令截取单元DF2的情况下，

所述DF2，根据本地策略，识别出从IMS网元中获得不可信消息后，将从所述IMS网元和信令面获取的信息发送到KMS，从所述IMS网元获取的信息包括：被监听用户所使用的KMS-ID、事件的时间戳中的至少一种；从所述信令面获取的信息包括：呼叫方的用户标识符、接收方的用户标识符中的至少一种；

所述KMS，进一步用于根据DF2所提供的从所述IMS网元和信令面获取的信息，找到对应的MIKEY-Ticket信息，进行解析，并将解析结果发送给DF2。

本发明为了实现引入KMS这一新增网元后，对基于KMS的IMS媒体安全的合法监听，包括两种系统实现方案，即为：引入KMS这一新增网元后分别对应的推(PUSH)方案和拉(PULL)方案。其中，PUSH方案中，该系统包括：新增的KMS和信令截取单元；新增的KMS与ADMF相连，用于从ADMF接收监听命令，主动向信令截取单元发送监听数据；新增的信令截取单元，用于从KMS和IMS网元截取监听数据。

采用本发明，能实现对基于KMS的IMS媒体安全的合法监听，为基于KMS的安全通信技术方案，所对应提供的切实有效的监听方案。

附图说明

图1为现有MIKEY-Ticket的系统架构图；

图2为现有MIKEY-Ticket中定义的三个密钥协商交互流程的示意图；

图3为现有REQUEST_INIT消息的示意图；

图4为现有REQUEST_RESP消息的示意图；

图5为现有TRANSFER_INIT消息的示意图；

图6为现有RESOLVE_INIT消息的示意图；

图7为现有RESOLVE_RESP消息的示意图；

图8为现有TRANSFER_RESP消息的示意图；

图9为现有已标准化的控制面的IMS合法监听系统架构图；

图10为本发明系统的KMS-PUSH方案的系统架构图；

图11为应用本发明系统的KMS-PUSH架构下，KMS和其他监听网元的接口示意图；

图12为应用本发明系统的KMS-PUSH架构下，被叫方被布控时的监听流程示意图；

图13为应用本发明系统的KMS-PUSH架构下，呼叫方被布控时的监听流程示意图；

图14为本发明系统的KMS-PULL方案的系统架构图；

图15应用为本发明系统的KMS-PULL架构下，监控对象为被叫方时的消息流程示意图；

图16为应用本发明系统的KMS-PULL架构下，监控对象为呼叫方时的消息流程示意图。

具体实施方式

本发明的基本思想是：为了实现引入KMS这一新增网元后，对基于KMS的IMS媒体安全的合法监听，包括两种系统实现方案，即为：引入KMS这一新增网元后分别对应的PUSH方案和PULL方案。

下面结合附图对技术方案的实施作进一步的详细描述。

一种基于KMS的IMS媒体安全的合法监听系统，为了实现引入KMS这一新增网元后，对基于KMS的IMS媒体安全的合法监听，包括两种系统实现方案，即为：引入KMS这一新增网元后分别对应的PUSH方案和PULL方案，也可以称为KMS-PUSH系统架构方案和KMS-PULL系统架构方案。采用

KMS-PUSH系统架构时，系统即为基于KMS的PUSH模式的系统；采用

KMS-PULL系统架构时，系统即为基于KMS的PULL模式的系统。

这里需要指出的是：本发明既然是基于KMS的安全通信技术方案下所提供的切实有效的监听方案，由于基于KMS的安全通信技术方案不依赖于信令面的安全，因此，本发明的监听方案也不依赖于信令面的安全。本发明主要包括以下内容：

针对KMS-PUSH方案而言，如图10，图11所示即为KMS-PUSH方案的系统架构，从图10可以看出：ADMF作为用于向网元发送监听指令的实体，对IMS网元和KMS单独发出监听命令，IMS网元和KMS独立向DF2和DF2’发监听数据。

这里，DF2和DF2’即为信令截取单元的具体实现，DF2的全称为DeliveryFunction 2，可称为传送单元；DF2’也可称为传送单元，表示在功能上区别于DF2的传送单元。针对传送单元而言，传送单元在合法监听中用来截取信令面数据，并且将截取到的信息转换成标准格式，发送到监听中心(LEMF，LawEnforcement Monitoring Facility)。在实际应用中对于信令截取单元的处理包括两种方式：一种方式，可以将DF2和DF2’作为不同的网络实体，也就是说，在信令截取单元中分别独立配置两个功能单元，即DF2和DF2’，以各自实现不同的功能，这样进行的功能划分能提高系统整体运行速度和效率；另一种方式：可以将DF2和DF2’整合为同一个网络实体，也就是说，在信令截取单元中仅仅配置一个功能单元，该功能单元整合了DF2和DF2’的全部功能，并不作功能划分，比如，信令截取单元的具体实现可以仅仅是DF2，不过该DF2的含义指升级的DF2，既包括现有DF2的功能，也包括DF2’的功能，以区别于现有技术中的DF2。

这里，DF2和DF2’将监听数据发到LEMF进行信息关联，如果DF2和DF2’是同一个网络实体，则DF2可以将IMS网元和KMS发来的监听数据先关联后发给LEMF，或直接发给LEMF，由LEMF关联。如图11所示，KMS和ADMF有X1)1接口，用来接收来自ADMF的监听指令；KMS和DF2有X2接口，用来向DF2传送跟监听对象有关的票据解析请求(Resolve Init)，票据解析结果(Resolve Resp)，票据申请请求(Request Init)，票据申请响应(Request Resp)，事件发生的时间等信息。DF2和DF2’消息的关联可以通过无法通过信令面篡改的信息来关联，如时间的时间戳、呼叫方和接受方的用户地址等。

针对KMS-PULL方案而言，如图14所示即为KMS PULL方案的系统架构，DF2从IMS网元截取目标用户的会话消息，如果会话信息中包含MIKEY-Ticket消息，则DF2根据本地策略，比如分针对可信和不可信的不同策略来决定向KMS发送监听命令的内容，如果DF2从信令面截取到消息可信，DF2可以直接将截取到的Ticket发到KMS，获得Ticket的解析结果。如果DF2从信令面截取到的信息不可信，DF2从IMS网元中获得被监听用户的所使用的KMS-ID，将从IMS网元中获得事件的时间戳，和从信令面获取的不易被篡改的信息如呼叫双方的用户标识符等发送到指定KMS。KMS根据DF2提供信息，找到相关的Ticket，并将Ticket的解析结果发送给DF2。DF2可以将Ticket的解析结果发送给LEMF，由LEMF来做Ticket信息和呼叫信息的关联。也可以自己实现Ticket信息和呼叫信息的关联处理，并将处理过的信息发送给LEMF。DF2向KMS发送监听命令的时候，根据本地策略，决定发送到KMS的数据。

以下对本发明进行举例阐述。

系统实施例一：本发明系统的KMS-PUSH架构时的实施例，信令截取单元包括DF2和DF2’，且DF2和DF2’分别独立设置。本实施例中，DF2作为IMS网元的信令截取单元，DF2’作为KMS的信令截取单元。

如图10所示，该系统包括：ADMF、P-CSCF、S-CSCF、KMS、DF2、DF2’和LEMF；其中，P-CSCF和S-CSCF都属于IMS网元。

ADMF，用于向KMS发出监听命令。

KMS，与ADMF相连，还与DF2’相连，用于从ADMF接收监听命令后，向DF2’发送监听数据。

P-CSCF和S-CSCF，用于从ADMF接收监听命令，主动向DF2发送监听数据。

DF2，用于将从P-CSCF和S-CSCF截取的监听数据发送给LEMF，由LEMF进行信息关联。

DF2’，用于将从KMS截取的监听数据发送给LEMF，由LEMF进行信息关联。

LEMF，用于将从DF2和DF2’中获得的监听数据与从IMS网元获得的监听数据进行关联；根据关联后的监听数据进行监听。

这里需要指出的是：本系统实施例中的信令截取单元所包括的DF2和DF2’是分别独立设置的。也就是说，此时DF2和DF2’为不同的网络实体，分别起作用。

这里，KMS-PUSH架构时，信令截取单元所包括的DF2和DF2’能整合为一个升级的网络实体，信令截取单元即为升级的网络实体。与以上系统实施例一的不同之处仅在于：将DF2和DF2’整合后构成的一个升级的网络实体作为信令截取单元。也就是说，此时DF2和DF2’为同一个网络实体。

DF2和DF2’是同一个网络实体时，如图11所示的接口示意图可以看出：KMS和ADMF有X11接口，用来接收来自ADMF的监听指令；KMS和DF2有X2接口，用来向DF2传送跟监听对象有关的Resolve Init，Resolve Resp，Request Init，Request Resp，事件发生的时间等信息。

系统实施例二：本发明系统的KMS-PULL架构时的实施例，且信令截取单元为IMS网元的信令截取单元的情况，IMS网元的信令截取单元仍以DF2表示。如图14所示，该系统包括：ADMF、P-CSCF、S-CSCF、KMS、DF2和LEMF；其中，P-CSCF和S-CSCF都属于IMS网元。

DF2，用于从P-CSCF和S-CSCF截取监听数据目标用户的会话消息，根据所述监听数据采用不同的本地策略向KMS发送针对监听命令的内容。这里需要指出的是：监听数据也可以称为目标用户的会话消息。

KMS，与DF2相连，用于根据所述针对监听命令的内容进行解析，并将解析结果返回DF2。这里需要指出的是：此处涉及的监听命令与上述系统实施例一中涉及的监听命令表达不同含义，即为：二者虽然都属于监听命令，但是具体内容和格式可能不一样，上述系统实施例一中涉及的监听命令是ADMF和KMS之间的；而此处涉及的监听命令是DF2和KMS之间的，二者的接口和参数都可能不一样，不作赘述。

针对不同的本地策略，DF2向KMS发送针对监听命令的内容包括以下两种具体实现：

一：DF2用于当采用针对可信消息的本地策略时，DF2直接将截取到消息中的Ticket发送到KMS。

相应的，KMS用于根据Ticket直接解析，并将针对Ticket的解析结果返回给DF2。

二：DF2用于当采用针对不可信消息的本地策略时，DF2将从P-CSCF和S-CSCF和信令面获取的信息发送到KMS；其中，从P-CSCF和S-CSCF获取的信息包括：被监听用户所使用的KMS-ID、事件的时间戳中的至少一种；从信令面获取的信息包括：呼叫方的用户标识符、接收方的用户标识符中的至少一种。

相应的，KMS用于根据DF2所提供的从P-CSCF和S-CSCF和信令面获取的信息，找到相关的Ticket，并将Ticket的解析结果发送给DF2。

以下对应用本发明系统架构下的信令交互流程进行举例阐述。

应用实例一：当应用本发明系统的KMS-PUSH架构时的实例，如图12所示是当接收方(用户B)是监控对象时的消息流程，包括以下步骤：

步骤101：用户A向KMS_A发送Ticket请求消息。

步骤102：KMS_A收到用户A的请求后，将密钥和Ticket通过Request Resp消息发给用户A。

步骤103：用户A向IMS网络发送Transfer Init消息。

步骤104：IMS网络向DF2转发收到的Transfer Init消息。

步骤105：IMS网络向用户B转发Transfer Init消息

步骤106：用户B向KMS_B发送Ticket解析请求Resolve Init。

步骤107：KMS_B转发Ticket解析请求Resolve Init到DF2’。

步骤108：KMS_B发送Ticket解析请求Resolve Init到KMS_A。

步骤109：KMS_A发送Ticket解析结果Resolve Resp给KMS_B。

步骤110：KMS_B发送Ticket解析结果Resolve Resp给DF2’.

步骤111：KMS_B发送Ticket解析结果Resolve Resp发给用户B。

步骤112：用户B将向IMS网络发送Transfer Resp消息。

步骤113：IMS网络向DF2转发Transfer Resp消息。

步骤114：IMS网络向用户A发送Transfer Resp消息。

应用实例二：当应用本发明系统的KMS-PUSH架构时的实例，如图13所示是当发起方(用户A)是监控对象时的消息流程，包括以下步骤：

步骤201：用户A向KMS_A发送Ticket请求消息。

步骤202：KMS_A向DF2’转发Ticket请求消息。

步骤203：KMS_A收到用户A的请求后，将密钥和Ticket通过Request Resp消息发给用户A。

步骤204：KMS_A将Request Resp消息转发给DF2’。

步骤205：用户A向IMS网络发送Transfer Init消息。

步骤206：IMS网络向DF2转发收到的Transfer Init消息。

步骤207：IMS网络向用户B转发Transfer Init消息。

步骤208：用户B向KMS_B发送Ticket解析请求Resolve Init。

步骤209：KMS_B发送Ticket解析请求Resolve Init到KMS_A。

步骤210：KMS_A转发Resolve Init到DF2’。

步骤211：KMS_A发送Ticket解析结果Resolve Resp给KMS_B。

步骤212：KMS_A发送Ticket解析结果Resolve Resp给DF2’。

步骤213：KMS_B发送Ticket解析结果Resolve Resp给用户B。

步骤214：用户B将向IMS网络发送Transfer Resp消息。

步骤215：IMS网络向DF2转发Transfer Resp消息。

步骤216：IMS网络向用户A发送Transfer Resp消息。

应用实例三：当应用本发明系统的KMS-PULL架构时的实例，如图15所示，当信令面不可信，并且当用户B是监听对象时的监听流程，包括以下步骤：

步骤301：用户A向KMS_A发送Ticket请求消息。

步骤302：KMS_A收到用户A的请求后，将密钥和Ticket通过Request Resp消息发给用户A。

步骤303：用户A向IMS网络发送Transfer Init消息。

步骤304：IMS网络向DF2转发收到的Transfer Init消息，以及用户B的KMS-ID(及KMS B)，已经事件发生的时间戳等信息。

步骤305：DF2将事件发生的时间戳，和从Transfer Init消息中获取不易在信令面被篡改的信息比如呼叫上方的身份标识，发送到KMS_B。

步骤306：IMS网络向用户B转发Transfer Init消息。

步骤307：用户B向KMS_B发送Ticket解析请求Resolve Init。

步骤308：KMS_B发送Ticket解析请求Resolve Init到KMS_A。

步骤309：KMS_A发送Ticket解析结果Resolve Resp给KMS_B。

步骤310：KMS_B发送Ticket解析结果Resolve Resp给DF2。

步骤311：KMS_B发送Ticket解析结果Resolve Resp给用户B。

步骤312：用户B将向IMS网络发送Transfer Resp消息。

步骤313：IMS网络向DF2转发Transfer Resp消息。

步骤314：IMS网络向用户A发送Transfer Resp消息。

应用实例四：当应用本发明系统的KMS-PULL架构时的实例，如图16所示，当信令面不可信，并且当呼叫方(用户A)是监听对象时的监听流程，包括以下步骤：

步骤401：用户A向KMS_A发送Ticket请求消息。

步骤402：KMS_A收到用户A的请求后，将密钥和Ticket通过Request Resp消息发给用户A。

步骤403：用户A向IMS网络发送Transfer Init消息。

步骤404：IMS网络向DF2转发收到的Transfer Init消息，以及用户A的KMS-ID(及KMS_A)，已经事件发生的时间戳等信息。

步骤405：DF2将事件发生的时间戳，和从Transfer Init消息中获取不易在信令面被篡改的信息比如呼叫上方的身份标识，发送到KMS_A。

步骤406：IMS网络向用户B转发Transfer Init消息。

步骤407：用户B向KMS_B发送Ticket解析请求Resolve Init。

步骤408：KMS_B发送Ticket解析请求Resolve Init到KMS_A。

步骤409：KMS_A发送Ticket解析结果Resolve Resp给DF2。

步骤410：KMS_A发送Ticket解析结果Resolve Resp给KMS_B。

步骤411：KMS_B发送Ticket解析结果Resolve Resp给用户B。

步骤412：用户B将向IMS网络发送Transfer Resp消息。

步骤413：IMS网络向DF2转发Transfer Resp消息。

步骤414：IMS网络向用户A发送Transfer Resp消息。

这里，对以上文字包括附图中文字的中英文进行说明：BSF指服务功能；Media Key指媒体密钥；KMS指密钥管理服务器；NAF指应用服务器；Key-info指；P-CSCF指代理呼叫会话控制单元；S-CSCF指服务呼叫会话控制单元；Request Init指票据请求；Request Resp指票据请求结果；Transfer Init指票据传输请求；Transfer Resp指票据传输请求应答；Resolve Init指票据解析请求；Resolve Resp指票据解析结果信息。

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。

Claims (10)

1.一种基于密钥管理服务器KMS的IMS媒体安全的合法监听系统，该系统包括：管理实体(ADMF)、IP多媒体子系统(IMS)网元和监听中心(LEMF)；其特征在于，该系统还包括：KMS和信令截取单元：

所述ADMF，用于向所述KMS发出监听命令；

所述KMS，与所述ADMF相连，用于从所述ADMF接收所述监听命令后，向所述信令截取单元发送监听数据；

所述信令截取单元，与所述KMS相连，用于将所述监听数据与从IMS网元获得的监听数据进行关联，并将关联后的监听数据发送给LEMF；或者，将所述监听数据直接发送给LEMF；

所述LEMF，根据关联后的监听数据进行监听；或者，将从所述信令截取单元获得的监听数据与从IMS网元获得的监听数据进行关联，根据关联后的监听数据进行监听。

2.根据权利要求1所述的系统，其特征在于，所述信令截取单元单独设置或者与IMS网元中的信令截取单元DF2合设。

3.根据权利要求2所述的系统，其特征在于，所述信令截取单元与IMS网元中的信令截取单元DF2合设的情况下，

合设后的信令截取单元，用于将从所述IMS网元和所述KMS截取的监听数据先进行信息关联后，再发送给所述LEMF；或者，将从所述IMS网元和所述KMS截取的监听数据直接发送给所述LEMF，由所述LEMF进行信息关联。

4.根据权利要求3所述的系统，其特征在于，所述信息关联所采用的信息包括以下之一或任意组合：时间戳、呼叫方的用户地址、接收方的用户地址。

5.根据权利要求2所述的系统，其特征在于，所述信令截取单元单独设置的情况下，

所述IMS网元的信令截取单元DF2，用于将从所述IMS网元截取的监听数据发送给所述LEMF；

所述信令截取单元，用于将从所述KMS截取的监听数据发送给所述LEMF；

所述LEMF根据从DF2及所述信令截取单元中接收到的数据，进行信息关联。

6.根据权利要求5所述的系统，其特征在于，所述信息关联所采用的信息包括以下之一或任意组合：时间戳、呼叫方的用户地址、接收方的用户地址。

7.一种基于密钥管理服务器的IMS媒体安全的合法监听系统，该系统包括：ADMF、IMS网元和LEMF；其特征在于，该系统还包括：KMS和信令截取单元，

所述信令截取单元，用于从所述IMS网元获得监听数据，并将其发送给所述KMS；

所述KMS，与所述信令截取单元相连，用于对所述监听数据进行解析，并将解析结果返回信令截取单元。

8.根据权利要求7所述的系统，其特征在于，所述信令截取单元为IMS网元中的信令截取单元DF2的情况下，

所述DF2，用于将所述监听数据发送给所述KMS，所述监听数据包含MIKEY-Ticket信息。

9.根据权利要求8所述的系统，其特征在于，所述DF2将所述监听数据中包含的MIKEY-Ticket信息发送到所述KMS；

所述KMS，进一步用于根据所述MIKEY-Ticket信息解析，并将解析结果返回给所述DF2。

10.根据权利要求7所述的系统，其特征在于，所述信令截取单元为IMS网元中的信令截取单元DF2的情况下，

所述DF2，根据本地策略，识别出从IMS网元中获得不可信消息后，将从所述IMS网元和信令面获取的信息发送到KMS，从所述IMS网元获取的信息包括：被监听用户所使用的KMS-ID、事件的时间戳中的至少一种；从所述信令面获取的信息包括：呼叫方的用户标识符、接收方的用户标识符中的至少一种；

所述KMS，进一步用于根据DF2所提供的从所述IMS网元和信令面获取的信息，找到对应的MIKEY-Ticket信息，进行解析，并将解析结果发送给DF2。