CN102025485B - 密钥协商的方法、密钥管理服务器及终端 - Google Patents

Abstract

本发明公开了一种密钥协商的方法、密钥管理服务器及终端，该方法包括：密钥管理服务器KMS接收来自被叫方的第一信息，第一信息中携带有由被叫方对应的呼叫方与KMS之间的第一共享密钥加密的第一载荷和由被叫方与KMS之间的第二共享密钥加密的第二载荷；KMS根据第一信息生成呼叫方和被叫方需要的媒体根密钥，并将媒体根密钥加密后发送给被叫方，以便于被叫方将加密后的媒体密钥根发送给呼叫方。通过本发明解决了相关技术中基于KMS的IMS媒体安全减少信令开销会带来安全隐患的问题，减少了信令的传送，保证了端到端的媒体流安全。

Description

密钥协商的方法、密钥管理服务器及终端

技术领域

本发明涉及通信领域，具体而言，涉及一种密钥协商的方法、密钥管理服务器及终端。

背景技术

在第三代合作伙伴计划(3rd Generation Partnership Project，简称为3GPP)关于因特网协议(Internet Protocol，简称为IP)多媒体子系统(IP Multimedia Subsystem，简称为IMS)的媒体安全的最新技术规范TS33.328v0.1.1中，提出了使用基于密钥管理服务器的方案来保护IMS媒体流的端到端安全。TS33.328中的方案是基于密钥管理服务器(Key Management Server，简称为KMS)和票据(ticket)的概念，该方案的实施过程如下：首先，会话呼叫方向KMS请求相关密钥和一个ticket，呼叫方向KMS请求得到的相关密钥在被加密之后保存在该ticket中；在得到相关密钥和ticket之后，呼叫方把该ticket发送给被叫方；由于被叫方无法解密该ticket以便获得其中包含的信息，被叫方将该ticket继续发送给KMS，由KMS解密ticket，并将其中的相关密钥返回给被叫方。

MIKEY-TICKET文档是对MIKEY协议的一个扩展，目的是将基于KMS和ticket的方案用具体协议承载，从而能够在信令中传输。在该文档中定义了上述方案的具体过程以及消息中所携带的参数。图1是根据相关技术的基于KMS的IMS媒体面安全的消息交互的示意图，如图1所示，该方案定义了包含三方(呼叫方，被叫方和KMS)参与的三组信令交互：票据请求(REQUEST_INIT，REQUEST_RESP)、票据传输(TRANSFER_INIT，TRANSFER_RESP)和票据处理(RESOLVE_INIT，RESOLVE_RESP)。TS33.328中的基于KMS的方案需要完整的三组信令交互流程，为了减少信令开销，目前，提出了两种方法：一、定义可以重复使用的ticket；二、为多个用户申请相同的ticket，例如，申请一个可以呼叫所有用户的ticket，这样可以在第一次票据请求后再次呼叫用户时省略掉该票据请求的过程，节省一次信令开销。但是，这两种方法也带来了很多安全相关问题。例如，用户向KMS请求ticket本身，或者是一个可以呼叫所有用户的ticket，可能被恶意用户用来发起对KMS的DDoS攻击，也可能被利用发起中间人攻击。为了避免这种攻击可能，需要在票据传输时跟数据绑定受保护的指明呼叫方的消息，但是，这样又增加了KMS的工作量。并且，可重复使用的ticket，有可能绕过KMS，使得合法监听无法实现。所以，该方案提出的两个减少信令开销的方法，为IMS媒体面带来了更多的安全隐患，而相应措施也大大增加了方案实施的复杂性。

发明内容

针对相关技术中基于KMS的IMS媒体安全减少信令开销会带来安全隐患的问题而提出本发明，为此，本发明的主要目的在于提供一种密钥协商的方案，以解决上述问题至少之一。

为了实现上述目的，根据本发明的一个方面，提供了一种密钥协商的方法。

根据本发明的密钥协商的方法包括：KMS接收来自被叫方的第一信息，第一信息中携带有由被叫方对应的呼叫方与KMS之间的第一共享密钥加密的第一载荷和由被叫方与KMS之间的第二共享密钥加密的第二载荷；KMS根据第一信息生成呼叫方和被叫方需要的媒体根密钥，并将媒体根密钥加密后发送给被叫方，以便于被叫方将加密后的媒体密钥根发送给呼叫方。

优选地，KMS根据第一信息生成媒体根密钥包括：KMS解密第一载荷和第二载荷；KMS根据解密后的第一载荷和第二载荷对呼叫方和被叫方进行认证，如果认证通过，则生成媒体根密钥。

优选地，KMS将媒体根密钥加密包括：KMS用第一共享密钥加密媒体根密钥得到第一媒体根密钥；KMS用第二共享密钥加密媒体根密钥得到第二媒体根密钥。

优选地，在KMS将媒体根密钥加密之后，被叫方接收来自KMS的第一媒体根密钥和第二媒体根密钥；被叫方解密第二媒体根密钥，并将第一媒体根密钥发送给呼叫方。

优选地，第一载荷至少包括：用呼叫方与KMS之间的共享密钥加密的呼叫方的随机数、呼叫方的用户标识和被叫方的用户标识；第二载荷至少包括：用被叫方与KMS之间的共享密钥加密的被叫方的随机数、呼叫方的用户标识和被叫方的用户标识。

为了实现上述目的，根据本发明的另一方面，提供了一种KMS。

根据本发明的KMS包括：第一接收模块，用于接收来自被叫方的第一信息，第一信息中携带有由被叫方对应的呼叫方与KMS之间的第一共享密钥加密的第一载荷和由被叫方与KMS之间的第二共享密钥加密的第二载荷；生成模块，用于根据第一信息生成呼叫方和被叫方需要的媒体根密钥；加密模块，用于将媒体根密钥加密；第一发送模块，用于向被叫方发送加密后的媒体根密钥以便于被叫方将加密后的媒体密钥根发送给呼叫方。

优选地，生成模块包括：解密子模块，用于解密第一载荷和第二载荷；认证子模块，用于根据解密后的第一载荷和第二载荷对呼叫方和被叫方进行认证；生成子模块，用于在认证子模块认证通过的情况下，生成媒体根密钥。

优选地，加密模块包括：第一加密子模块，用于利用第一共享密钥加密媒体根密钥得到第一媒体根密钥；第二加密子模块，用于利用第二共享密钥加密媒体根密钥得到第二媒体根密钥。

为了实现上述目的，根据本发明的又一方面，提供了一种终端。

根据本发明的终端包括：第二接收模块，用于接收来自呼叫方的第二信息，第二信息中携带有由呼叫方与KMS之间的第一共享密钥加密的第一载荷；添加模块，用于向第二信息中添加由终端与KMS之间的第二共享密钥加密的第二载荷，得到第一信息；第二发送模块，用于向KMS发送第一信息；第三接收模块，用于接收来自KMS的加密后的媒体根密钥；第一解密模块，用于解密加密后的媒体根密钥；第三发送模块，用于将加密后的媒体根密钥发送给呼叫方以便呼叫方获得媒体根密钥。

为了实现上述目的，根据本发明的再一方面，提供了另一种终端。

根据本发明的另一种终端包括：第四发送模块，用于向被叫方发送第二信息，第二信息中携带有由呼叫方与KMS之间的第一共享密钥加密的第一载荷；第四接收模块，用于接收来自被叫方的加密后的媒体根密钥；第二解密模块，用于解密加密后的媒体根密钥。

通过本发明，采用在票据中添加一个新的载荷，省去票据请求的信息交互，而只通过票据传输和票据处理来实现IMS媒体面端到端的安全的方式，解决了相关技术中基于KMS的IMS媒体安全减少信令开销会带来安全隐患的问题，进而达到了既减少了信令的传送又保证了端到端的媒体流安全的效果。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据相关技术的基于KMS的IMS媒体面安全的消息交互的示意图；

图2是根据相关技术的票据传输的示意图；

图3是根据相关技术的票据处理的示意图；

图4是根据相关技术的票据头载荷的示意图；

图5是根据本发明实施例的密钥协商的方法的流程图；

图6是根据相关技术的密钥管理系统的网络结构的示意图；

图7是根据本发明实施例的普通端对端的密钥协商的方法的流程图；

图8是根据本发明实施例的Forking场景的密钥协商的方法的流程图；

图9是根据本发明实施例的KMS的结构框图；

图10是根据本发明实施例的KMS的具体的结构框图；

图11是根据本发明实施例的一种终端的结构框图；

图12是根据本发明实施例的另一种终端的结构框图。

具体实施方式

功能概述

考虑到相关技术中基于KMS的IMS媒体安全减少信令开销会带来安全隐患的问题，本发明提供了一种密钥协商的方案，该方案的处理原则如下：KMS接收来自被叫方的第一信息，第一信息中携带有由被叫方对应的呼叫方与KMS之间的第一共享密钥加密的第一载荷和由被叫方与KMS之间的第二共享密钥加密的第二载荷；KMS根据第一信息生成呼叫方和被叫方需要的媒体根密钥，并将媒体根密钥加密后发送给被叫方，以便于被叫方将加密后的媒体密钥根发送给呼叫方。本发明对MIKEY-TICKET中的票据传输和票据处理流程的参数进行了修改，在ticket中增加新的载荷，使得无须在每次会话呼叫前先向KMS申请ticket，而只需要票据传输和票据处理两组流程来实现IMS媒体面安全，减少了信令交互，同时，还保证了端到端的媒体流安全。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本发明。

在以下实施例中，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

方法实施例

图2是根据相关技术的票据传输的示意图，如图2所示，TRANSFER_INIT消息中携带的参数为：消息头(HDR)，时间戳(T)，呼叫方生成的随机数(RANDi)，呼叫方用户标识(Identifier，简称为ID)(IDi，此项可选)，被叫方用户标识(IDr，此项可选)，安全策略(可为零个或者大于零个实例)，票据策略(IDtp，此项必选)，TICKET和密码校验码(V)。其中，有[]的参数为可选，TICKET中包含ticket类型以及ticket数据，ticket类型和数据均取决于IDtp。TRANSFER_RESP消息中携带参数为：消息头(HDR)，时间戳(T)，被叫方生成的随机数(RANDr，此项可选)，被叫方用户标识(IDr，此项可选)，KMS产生的修改数(IDmod，此项可选)，密钥校验码(V)。

图3是根据相关技术的票据处理的示意图，如图3所示，RESOLVE_INIT消息中携带的参数为：消息头(HDR)，时间戳(T)，被叫方生成的随机数(RAND)，被叫方用户标识(IDr，此项可选)，票据策略(IDtp)，TICKET，指明所使用的共享密钥标识(IDpsk)，密钥校验码(V)。RESOVLE_RESP消息中携带的参数为：消息头(HDR)，时间戳(T)，KMS的标识(IDkms，此项可选)，KMS产生的修改数(IDmod，此项可选)，密钥载荷(KEMAC)和密钥校验码(V)。

在相关技术中TICKET的默认载荷为：

TICKET data＝THDR，[Ti]，RAND，IDkms，(IDre)，Ts，Te，IDi，KEMAC，IDtpk，V

其中，THDR为TICKET头载荷，图4是根据相关技术的票据头载荷的示意图，如图4所示，TICKET头载荷包括：8比特的Nextpayload，指明下一载荷的标识；8比特的ticket type，指明该TICKET类型；6比特的Subtype，指明该TICKET的子类型；6比特的Version，指明版本号；1比特的R位标记，说明该TICKET是否可重复使用；lige的F位标记，说明是否使用forking密钥；1比特的G位标记，说明TGK是否是组密钥；5比特的X，为预留段；48比特的IssuerID，是一个KMS的全球唯一标识。

根据本发明实施例在TICKET中新增OR载荷，并修改TICKET中KEMAC为可选项，TICKET的载荷变为：

TICKET data＝THDR，[Ti]，RAND，IDkms，(IDre)，Ts，Te，IDi，[KEMAC]，IDtpk，OR，V

其中，新增OR载荷格式为：Encr_key(RAND||IDi||IDr)，即用密钥encr_key去加密随机数RAND、呼叫方的用户标识以及被叫方的用户标识，其中，符号“||”表示串接。encr_key为各个用户与KMS之间的共享密钥。

根据本发明的实施例，提供了一种密钥协商的方法。

图5是根据本发明实施例的密钥协商的方法的流程图，如图2所示，该方法包括如下的步骤S502至步骤S504：

步骤S502，KMS接收来自被叫方的第一信息，第一信息中包含由被叫方对应的呼叫方与KMS之间的第一共享密钥加密的第一载荷和由被叫方与KMS之间的第二共享密钥加密的第二载荷；

步骤S504，KMS根据第一信息生成呼叫方和被叫方需要的媒体根密钥，并将媒体根密钥加密后发送给被叫方，以便于被叫方将加密后的媒体密钥根发送给呼叫方。

通过上述方法，只需要票据传输和票据处理两组流程来实现IMS媒体面安全，减少了信令交互，并且保证了端到端的媒体流安全。下面对该方法进行具体的描述。

其中，第一信息的生成和发送过程包括：呼叫方生成含有新载荷的TICKET，并将该TICKET放在TRANSFER_INIT消息中，包含在会话启动协议(Session Initiation Protocol，简称为SIP)邀请(INVITE)消息中传给被叫方，被叫方收到TRANSFER_INIT后在TICKET中增加一个自己生成的新载荷，然后将从呼叫方接收到的消息以及增加载荷后的TICKET放在RESOLVE_INIT消息中发送给KMS。

在步骤S504中，KMS根据第一信息生成媒体根密钥包括：KMS解密第一载荷和第二载荷；在接收到RESOLVE_INIT消息之后，KMS对呼叫方和被叫方进行认证，根据解密后的第一载荷和第二载荷对呼叫方和被叫方进行认证，并在认证通过之后为呼叫方和被叫方生成各自所需的媒体根密钥。

在步骤S504中，KMS将媒体根密钥加密包括：KMS用第一共享密钥加密媒体根密钥得到第一媒体根密钥；KMS用第二共享密钥加密媒体根密钥得到第二媒体根密钥。

KMS将第一媒体根密钥和第二媒体根密钥放在RESOLVE_RESP消息中包含在KEMAC里发送给被叫方。被叫方接收来自KMS的第一媒体根密钥和第二媒体根密钥，用自己与KMS共享密钥解密第二媒体根密钥，获得所需密钥；将第一媒体根密钥信息放在TRANSFER_RESP消息中转发给呼叫方，呼叫方解密获得所需媒体根密钥。

第一载荷至少包括：用呼叫方与KMS之间的共享密钥加密的呼叫方的随机数、呼叫方的用户标识和被叫方的用户标识；第二载荷至少包括：用被叫方与KMS之间的共享密钥加密的被叫方的随机数、呼叫方的用户标识和被叫方的用户标识。

下面将结合实例对本发明实施例的实现过程进行详细描述。

图6是根据相关技术的密钥管理系统的网络结构的示意图，如图6所示，UE通过引导服务器BSF与KMS使用通用认证机制GBA(General Bootstrapping Architecture)建立可信通道，代理呼叫会话控制功能实体(Proxy-Call Session Control Function，简称为P-CSCF)、服务呼叫会话控制功能实体(Serving-CSCF，简称为S-CSCF)为IMS核心网的网元。每个用户都跟KMS通过GBA方式建立信任关系，通过密钥协商协议，每个用户都与KMS建立共享密钥，如果GBA无法使用，用户可以通过其它认证方式与KMS获得共享密钥。该步骤的具体实现属于本领域技术人员惯用技术手段，这里不再赘述。在下面的所有场景安全解决方法流程中，GBA过程将不再表示在图中，在未作特殊说明的情况下，所有附图实例中的IMS用户终端A、B、C与KMS的共享密钥分别为Ka，Kb，Kc，他们与KMS之间的均已经建立安全通道，相应的GBA标识为BTIDa、BTIDb、BTIDc。为了让流程看起来更加简洁，在具体流程中省略了与现有技术相同的必选参数，例如，HDR、T、V等。

实例一

图7是根据本发明实施例的普通端对端的密钥协商的方法的流程图，如图7所示，该方法包括以下步骤S701至S707：

步骤S701，呼叫方IMS用户A首先确定票据策略，根据该策略采取相应的方法，生成相应的参数。

步骤S702至步骤S703，用户A生成随机数Ra，将Ra写入TICKET中OR载荷Ea(Ra||ID-A||ID-B)，然后，将ID-A，ID-B和TICKET放入TRANSFER_INIT消息，并将TRANSFER_INIT消息放在SIP INVITE消息中通过IMS网络发给用户B，其中，Ea(Ra||ID-A||ID-B)为由用户A与KMS的共享秘钥Ka加密Ra||ID-A||ID-B，其中，ID-A，ID-B分别为用户A，B的公共用户标识，另外，在明文中还需要携带BTIDa，BTIDa用于指示KMS去BSF获取与用户A的共享密钥，并进行用户验证。

步骤S704，被叫用户B在接收到TRANSFER_INIT消息之后，创建RESOLVE_INIT消息，该消息除包括用户B从用户A收到的TRANSFER_INIT中的信息之外，还包括BTIDb，以及TICKET’，TICKET’为用户B向接收到的TICKET中增加的一个OR载荷所得到的新的TICKET。新增加的OR载荷为Eb(Rb||ID-A||ID-B)，即由用户B与KMS的共享密钥加密Rb||ID-A||ID-B，其中Rb为用户B生成的随机数，ID-A，ID-B为用户A，B的公共用户标识。用户B将RESOLVE_INIT消息发送到KMS。

步骤S705，根据BTIDa和BTIDb，KMS向BSF要求相应的共享秘钥以及用户的公共身份标识，即，Ka，ID-A，Kb，ID-B，然后，KMS分别解密TICKET中的两个OR载荷，并将解密得到的ID-A，ID-B与明文ID-A，ID-B进行比较，如果比较一致，则标识通过用户验证，KMS生成用户A和用户B所需的媒体根密钥K。KMS用Ka和Kb分别加密K得到Ea(K)和Eb(K)。

步骤S706，KMS创建RESOLVE_RESP消息，该消息中包含Ea(K)，Eb(K)，将该消息返回给用户B。

步骤S707至步骤S708，用户B用与KMS的共享密钥Kb解密Eb(K)得到媒体根密钥K，并将Ea(K)放在消息TRANSFER_RESP中，通过SIP 200OK消息返回给呼叫用户A。

步骤S709，用户A与用户B进行安全媒体流传输。

通过上述流程，用户A和用户B协商出加密媒体流所需的媒体根密钥。

实例二

图8是根据本发明实施例的Forking场景的密钥协商的方法的流程图，如图8所示，该方法包括以下步骤S801至步骤S810：

步骤S801：首先，呼叫方IMS用户A确定票据策略，根据策略采取相应的方法，生成相应的参数。

步骤S802b至步骤S803b，用户A生成随机数Ra，将Ra写入TICKET中OR载荷Ea(Ra||ID-A||ID-R)，然后，将ID-A，ID-R和TICKET放入TRANSFER_INIT消息，并将TRANSFER_INIT消息放在SIP INVITE消息中通过IMS网络发给用户B，其中，Ea(Ra||ID-A||ID-R)为由用户A与KMS的共享秘钥Ka加密Ra||ID-A||ID-R，其中，ID-A，ID-R分别为呼叫用户和被叫用户的公共用户标识，另外，在明文中还需要携带BTIDa，BTIDa用于指示KMS去BSF获取与用户A的共享密钥，并进行用户验证。

步骤S804b：被叫用户终端B在接收到TRANSFER_INIT消息之后，创建RESOLVE_INIT消息，该消息除了包括从用户A收到的TRANSFER_INIT中的信息之外，还包括BTIDb以及TICKET’，TICKET’为用户终端B向接收到的TICKET中增加的一个OR载荷所得的新的TICKET。该新增加的OR载荷为Eb(Rb||ID-A||ID-R)，即，由用户终端B与KMS的共享密钥加密Rb||ID-A||ID-R，其中Rb为用户B生成的随机数。然后，用户B将RESOLVE_INIT消息发送到KMS。

步骤S805b：根据BTIDa和BTIDb，KMS向BSF要求获得相应共享秘钥以及用户的公共身份标识，即，Ka，ID-A，Kb，ID-B，然后，分别解密TICKET中的两个OR载荷，并将解密得到的ID-A，ID-R与明文中的ID-A，ID-R进行比较，如果一致，并且ID-B与ID-R存在对应关系，则表示通过用户验证，KMS生成终端A和终端B所需的媒体根密钥K1。KMS用Ka和Kb分别加密K1得到Ea(K1)和Eb(K1)。

步骤S806b：KMS创建RESOLVE_RESP消息，该消息包含Ea(K1)，Eb(K1)，将该消息返回给用户B。

步骤S802c-S806c与步骤S802b-S806b相类似，区别仅在于RESOLVE_INIT消息中包含BTIDc，以及新增OR载荷为Ec(Rc||ID-A||ID-R)，即，用fork终端C与KMS的共享密钥Kc加密Rc||ID-A||ID-R，其中，Rc为终端C生成的随机数。KMS在验证用户通过后，KMS生成终端A和终端C所述的新的媒体根密钥K2，用Ka，Kc分别加密K2得到Ea(K2)，Ec(K2)。

步骤S807至步骤S808，用户B用与KMS的共享密钥Kb解密Eb(K1)得到媒体根密钥K1，然后，将Ea(K1)放在消息TRANSFER_RESP中，通过SIP 200OK消息返回给呼叫用户A。

步骤S809，IMS网络中相应网元向fork终端C发出的CANCEL信息，中止除用户终端B以外的用户终端继续应答该呼叫。

步骤S810，用户A与用户B进行安全媒体流传输。

通过以上步骤，用户A可以与用户B进行用K1作为根密钥的加密媒体会话，非应答用户终端无法获悉该媒体密钥，从而实现了forking场景下的安全。

装置实施例

根据本发明的实施例，提供了一种KMS。

图9是根据本发明实施例的KMS的结构框图，如图9所示，该装置包括：第一接收模块92、生成模块94、加密模块96、第一发送模块98，下面对该结构进行详细描述。

第一接收模块92，用于接收来自被叫方的第一信息，第一信息中携带有由被叫方对应的呼叫方与KMS之间的第一共享密钥加密的第一载荷和由被叫方与KMS之间的第二共享密钥加密的第二载荷；生成模块94连接至第一接收模块92，用于根据第一信息生成呼叫方和被叫方需要的媒体根密钥；加密模块96连接至生成模块94，用于将媒体根密钥加密；第一发送模块98连接至加密模块96，用于向被叫方发送加密后的媒体根密钥以便于被叫方将加密后的媒体密钥根发送给呼叫方。

图10是根据本发明实施例的KMS的具体的结构框图，如图10所示，生成模块94包括：解密子模块100、认证子模块102、生成子模块104，下面对该结构进行详细说明。

解密子模块100，用于解密第一载荷和第二载荷；认证子模块102连接至解密子模块100，用于根据解密后的第一载荷和第二载荷对呼叫方和被叫方进行认证；生成子模块104连接至认证子模块102，用于在认证子模块认证通过的情况下，生成媒体根密钥。

加密模块96包括：第一加密子模块106、第二加密子模块108，下面对该结构进行详细说明。

第一加密子模块106，用于利用第一共享密钥加密媒体根密钥得到加密后的第一媒体根密钥；第二加密子模块108，用于利用第二共享密钥加密媒体根密钥得到加密后的第二媒体根密钥。

其中，第一载荷至少包括：用呼叫方与KMS之间的共享密钥加密的呼叫方的随机数、呼叫方的用户标识和被叫方的用户标识；第二载荷至少包括：用被叫方与KMS之间的共享密钥加密的被叫方的随机数、呼叫方的用户标识和被叫方的用户标识。

根据本发明的实施例，提供了一种终端。

图11是根据本发明实施例的一种终端的结构框图，如图11所示，该结构包括：第二接收模块1102、添加模块1104、第二发送模块1106、第三接收模块1108、第一解密模块1110、第三发送模块1112，该终端作为被叫方使用，下面对该结构进行详细说明。

第二接收模块1102，用于接收来自呼叫方的第二信息，第二信息中携带有由呼叫方与KMS之间的第一共享密钥加密的第一载荷；添加模块1104连接至第二接收模块1102，用于向第二信息中添加由终端与KMS之间的第二共享密钥加密的第二载荷，得到第一信息；第二发送模块1106连接至添加模块1104，用于向KMS发送第一信息；第三接收模块1108，用于接收来自KMS的加密后的媒体根密钥；第一解密模块1110连接至第三接收模块1108，用于解密加密后的媒体根密钥；第三发送模块1112连接至第一解密模块1110，用于将加密后的媒体根密钥发送给呼叫方以便呼叫方获得媒体根密钥。其中，第一载荷至少包括：用呼叫方与KMS之间的共享密钥加密的呼叫方的随机数、呼叫方的用户标识和该终端的用户标识；第二载荷至少包括：用该终端与KMS之间的共享密钥加密的该终端的随机数、呼叫方的用户标识和该终端的用户标识。

根据本发明实施例，提供了另一种终端。

图12是根据本发明实施例的另一种终端的结构框图，如图12所示，该结构包括：第四发送模块1202、第四接收模块1204、第二解密模块1206，该终端作为呼叫方使用，下面对该结构进行详细说明。

第四发送模块1202，用于向被叫方发送第二信息，信息中携带有由呼叫方与KMS之间的第一共享密钥加密的第一载荷；第四接收模块1204，用于接收来自被叫方的加密后的媒体根密钥；第二解密模块1206连接至第四接收模块1204，用于解密加密后的媒体根密钥。其中，第一载荷至少包括：用该终端与KMS之间的共享密钥加密的该终端的随机数、该终端的用户标识和被叫方的用户标识。

综上所述，本发明只需要票据传输和票据处理两组流程来实现IMS媒体面安全，减少了信令交互，同时，还保证了端到端的媒体流安全。

本发明还可以有其他多种实施例，例如，延迟媒体会话安全保护，会议电话媒体流安全等。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (5)

1.一种密钥协商的方法，其特征在于，包括：

密钥管理服务器KMS接收来自被叫方的第一信息，所述第一信息中携带有由所述被叫方对应的呼叫方与所述KMS之间的第一共享密钥加密的第一载荷和由所述被叫方与所述KMS之间的第二共享密钥加密的第二载荷；

所述KMS根据所述第一信息生成所述呼叫方和所述被叫方需要的媒体根密钥，并将所述媒体根密钥加密后发送给所述被叫方，以便于所述被叫方将所述加密后的媒体密钥根发送给所述呼叫方，其中，

所述KMS根据所述第一信息生成所述媒体根密钥包括：

所述KMS解密所述第一载荷和所述第二载荷；

所述KMS根据解密后的所述第一载荷和所述第二载荷对所述呼叫方和所述被叫方进行认证，如果认证通过，则生成所述媒体根密钥；

所述KMS将所述媒体根密钥加密包括：

所述KMS用所述第一共享密钥加密所述媒体根密钥得到第一媒体根密钥；

所述KMS用所述第二共享密钥加密所述媒体根密钥得到第二媒体根密钥，其中，

所述第一载荷至少包括：用所述呼叫方与所述KMS之间的共享密钥加密的所述呼叫方的随机数、所述呼叫方的用户标识和所述被叫方的用户标识；所述第二载荷至少包括：用所述被叫方与所述KMS之间的共享密钥加密的所述被叫方的随机数、所述呼叫方的用户标识和所述被叫方的用户标识。

2.根据权利要求1所述的方法，其特征在于，在所述KMS将所述媒体根密钥加密之后，所述方法还包括：

所述被叫方接收来自所述KMS的所述第一媒体根密钥和所述第二媒体根密钥；

所述被叫方解密所述第二媒体根密钥，并将所述第一媒体根密钥发送给所述呼叫方。

3.一种密钥管理服务器KMS，其特征在于，包括：

第一接收模块，用于接收来自被叫方的第一信息，所述第一信息中携带有由所述被叫方对应的呼叫方与KMS之间的第一共享密钥加密的第一载荷和由所述被叫方与所述KMS之间的第二共享密钥加密的第二载荷；

生成模块，用于根据所述第一信息生成所述呼叫方和所述被叫方需要的媒体根密钥；

加密模块，用于将所述媒体根密钥加密；

第一发送模块，用于向所述被叫方发送加密后的所述媒体根密钥以便于所述被叫方将所述加密后的媒体密钥根发送给所述呼叫方，其中，

所述生成模块包括：

解密子模块，用于解密所述第一载荷和所述第二载荷；

认证子模块，用于根据解密后的所述第一载荷和所述第二载荷对所述呼叫方和所述被叫方进行认证；

生成子模块，用于在所述认证子模块认证通过的情况下，生成所述媒体根密钥；其中，

所述加密模块包括：

第一加密子模块，用于利用所述第一共享密钥加密所述媒体根密钥得到第一媒体根密钥；

第二加密子模块，用于利用所述第二共享密钥加密所述媒体根密钥得到第二媒体根密钥，其中，

所述第一载荷至少包括：用所述呼叫方与所述KMS之间的共享密钥加密的所述呼叫方的随机数、所述呼叫方的用户标识和所述被叫方的用户标识；所述第二载荷至少包括：用所述被叫方与所述KMS之间的共享密钥加密的所述被叫方的随机数、所述呼叫方的用户标识和所述被叫方的用户标识。

4.一种终端，其特征在于，包括：

第二接收模块，用于接收来自呼叫方的第二信息，所述第二信息中携带有由所述呼叫方与密钥管理服务器KMS之间的第一共享密钥加密的第一载荷；

添加模块，用于向所述第二信息中添加由所述终端与所述KMS之间的第二共享密钥加密的第二载荷，得到第一信息；

第二发送模块，用于向所述KMS发送所述第一信息；

第三接收模块，用于接收来自所述KMS的所述KMS根据所述第一信息生成并加密后的媒体根密钥；

第一解密模块，用于解密所述加密后的媒体根密钥；

第三发送模块，用于将所述加密后的媒体根密钥发送给所述呼叫方以便所述呼叫方获得所述媒体根密钥，其中，

所述第一载荷至少包括：用所述呼叫方与所述KMS之间的共享密钥加密的所述呼叫方的随机数、所述呼叫方的用户标识和所述被叫方的用户标识；所述第二载荷至少包括：用所述被叫方与所述KMS之间的共享密钥加密的所述被叫方的随机数、所述呼叫方的用户标识和所述被叫方的用户标识。

5.一种终端，其特征在于，包括：

第四发送模块，用于向被叫方发送第二信息，所述第二信息中携带有由呼叫方与密钥管理服务器KMS之间的第一共享密钥加密的第一载荷；

第四接收模块，用于接收来自所述被叫方的所述被叫方从所述KMS接收的所述KMS根据第一信息生成并加密后的媒体根密钥，其中，所述第一信息是通过向所述第二信息中添加由所述被叫方与所述KMS之间的第二共享密钥加密的第二载荷得到的；

第二解密模块，用于解密所述加密后的媒体根密钥，其中，

所述第一载荷至少包括：用所述呼叫方与所述KMS之间的共享密钥加密的所述呼叫方的随机数、所述呼叫方的用户标识和所述被叫方的用户标识；所述第二载荷至少包括：用所述被叫方与所述KMS之间的共享密钥加密的所述被叫方的随机数、所述呼叫方的用户标识和所述被叫方的用户标识。

Images