会议系统中的安全密钥管理的利记博彩app

专利名称：会议系统中的安全密钥管理的利记博彩app
技术领域：
本发明总体上涉及通信安全性，并且更具体地，涉及用于在诸如呼叫会议系统和多媒体通信系统的媒体平面这样的通信环境中使用的安全密钥管理协议。
背景技术：
在多媒体通信系统中提供的现有多媒体应用并不支持媒体平面中的安全性。关于媒体平面安全性的问题是相对新的问题。在诸如因特网协议(IP)多媒体子系统(IMQ这样的多媒体通信系统中的现有提议是以某种基于令牌的对称密钥方法为基础，该令牌是使用密钥管理服务器(其潜在地创建和分发密钥)来管理的。3GPP (第三代合作伙伴项目)技术报告(TR) 33.拟8讨论了用于 IMS媒体平面加密的现有提议，通过引用的方式将其公开内容合并于此。然而，这些现有解决方案是不可扩展的(因为服务器应当高度可用并且总是在线)，其并不提供实体的认证， 并且此外，其在服务器处托管(escrow)密钥。相反地，诸如SKYPE (卢森堡的Skype Technologies S. Α.的商品名称)这样的非 IMS应用以及其它客户端到客户端的多媒体应用在认证和无密钥托管的情况下提供了端到端的隐私性。然而，该解决方案依赖于使用要求高度可用的公共密钥基础设施(PKI)的证书，其中管理所述PKI是极其昂贵的。此外，该解决方案没有很好地扩展用于群组会议应用，它也没有提供在缺少PKI情况下对通信的合法拦截。此外，类似的密钥管理安全性问题存在于会议系统中，其中各方通过会议服务器来参与呼叫会话。因而，需要一种用于在诸如呼叫会议系统和多媒体通信系统的媒体平面这样的通信环境中使用的安全密钥管理解决方案。

发明内容
本发明的原理提供了用于在诸如会议系统这样的通信环境中使用的一个或多个安全密钥管理协议。例如，在一个方面中，一种用于在通信系统中管理两方或更多方之间的会议的方法包括以下步骤。在通信系统的会议管理元件与设法参与会议的所述两方或更多方中的每一方之间实施基于身份的认证密钥交换操作，其中，在所述会议管理元件与所述两方或更多方之间交换的消息是基于所述消息的接收者的相应身份来进行加密的，并且进一步地， 其中所述会议管理元件在密钥认证操作期间从每一方接收基于由该方选择的随机数所计算的随机密钥分量。所述会议管理元件向每一方发送包括由各方计算的随机密钥分量的集合。所述会议管理元件从每一方接收随机群组密钥分量，其中，由每一方经由基于以下内容的计算方法来计算所述随机群组密钥分量在密钥认证操作期间由该方所使用的随机数，以及由设法参与所述会议的所述两方或更多方中的其它方的子集所计算的随机密钥分量。所述会议管理元件向每一方发送包括由各方计算的随机群组密钥分量的集合，从而使得每一方可以计算相同的群组密钥以便在通过所述会议管理元件与每一个其它方进行通信时使用。在一个实施例中，所述会议管理元件不是所述会议中的参与方，并且由此不能计算群组密钥。在另一个实施例中，所述会议管理元件是会议呼叫中的参与方，并且由此能够计算群组密钥。在一个实施例中，由每一方计算的群组密钥被表示为=Nai (Zi-I) +(N-I)
Xi+1+. . . +Xi_2，其中N表示设法参与会议的各方的总数，ai表示由给定方选择的随机数,Zi表示由给定方计算的随机密钥分量，&表示由给定方计算的随机群组密钥分量，并且i表示在 N方会议中用于给定方的会议排序的编号，其中当i = 1时，i-1 = N，而当i = N时，i+1 =
Io在一个实施例中，用于给定方的随机密钥分量通过如下表示的计算方法来计算 BiP,其中％是由给定方选择的随机数，并且P是选自与基于身份加密的密钥认证操作相关联的群组的点(point)。在一个实施例中，用于给定方的随机群组密钥分量通过如下表示的计算方法来计算a, (BitlP-Bi^1P)，其中 是由给定方选择的随机数，ai+1P是由在会议排序中就在给定方之后的一方发送到会议管理元件的随机密钥分量，Bi^1P是由在会议排序中就在给定方之前的一方发送到会议管理元件的随机密钥分量，并且P是选自与密码密钥交换协议相关联的群组的点。应当理解，虽然本发明的原理特别适合因特网协议(IP)多媒体子系统(IMS)环境，但是本发明并不意在限制于此。也就是说，本发明的原理通常可应用于其中期望提供安全密钥管理特征的任何合适的通信系统。根据结合附图阅读的对本发明的说明性实施例的以下详细描述，本发明的这些和其它目的、特征和优点将变得显而易见。


图IA图示了根据本发明实施例的私有密钥获取方法；图IB图示了根据本发明实施例的基于身份的认证密钥交换方法；图2图示了根据本发明实施例的密钥分路(key forking)方法；图3图示了根据本发明实施例的呼叫重定向方法；图4A图示了根据本发明实施例的迟延递送(deferred delivery)方法；图4B图示了根据本发明另一实施例的迟延递送方法；图5图示了根据本发明实施例的合法拦截方法；图6A图示了根据本发明实施例的会议管理方法；
图6B图示了根据本发明实施例的在会议管理方法中对参与者的添加；图6C图示了根据本发明实施例的在会议管理方法中对参与者的删除；图7图示了根据基于IMS的本发明实施例的用于安全密钥管理协议的网络架构；图8图示了根据基于IMS的本发明实施例的密钥分路方法；图9图示了根据基于IMS的本发明实施例的重定向方法；图10图示了根据基于IMS的本发明实施例的具有三个参与者的会议方法；以及图11图示了适合实现根据本发明实施例的一个或多个协议的通信(计算)设备和数据网络的广义硬件架构。
具体实施例方式如在此所使用的，短语“多媒体通信系统”通常被定义为能够传输两个或更多类型的媒体(包括但不限于基于文本的数据、基于图形的数据、基于语音的数据和基于视频的数据)的任何通信系统。如在此所使用的，短语“媒体平面”通常被定义为多媒体通信系统的以下功能部分依照该功能部分，在呼叫会话中在两方或更多方之间交换一个或多个类型的媒体。这与 “控制平面”不同，“控制平面”是多媒体通信系统的以下功能部分依照该功能部分，执行呼叫协商/调度以便建立呼叫会话。可以与之一起使用本发明技术的媒体平面应用的例子包括但不限于基于IP的语音(VoIP)、即时消息收发(IM)、视频/音频IM，以及视频共享。应当明白，媒体平面含有应用层业务。如在此所使用的，术语“密钥”通常被定义为密码协议的输入，用于诸如但不限于实体认证、隐私性、消息完整性等等的目的。为了便于参考，详细的描述被划分如下。章节I描述了基于身份的加密和基于身份的认证密钥交换操作的一般原理。章节II描述了在一般通信环境上下文中根据本发明的说明性原理的安全密钥管理解决方案。章节III描述了在因特网协议(IP)多媒体子系统(IMS)环境上下文中根据本发明的说明性原理的安全密钥管理解决方案。章节IV描述了根据本发明的用于实现一个或多个安全密钥管理协议的说明性计算系统。I.基于身份的加密(IBE)和基于身份的认证密钥交换(IBAKE)在解释本发明的安全密钥管理技术的说明性实施例之前，提供了 IBE和IBAKE的一般原理。A.基于身份的加密基于身份的加密(IBE)协议由Boneh和Franklin提供，参见Dan Boneh,Matthew K. Franklin 的 “Identity-Based Encryption from the Weil Pairing，，Advances in Cryptology-Proceedings of CRYPTO 2001 (2001)，通过引用的方式将其公开内容合并于此。这种不对称密码加密协议允许参与者将‘身份’(示例电子邮件id或域名)用作公共密钥，并且不需要常常与公共密钥加密方法(诸如RSA(Rivest、Siamir和Adleman))相关联的大规模公共密钥基础设施。Boneh和Franklin的针对该问题的方法在有限域上使用基于椭圆曲线的双线性映射，并且依赖于双线性判定Diffie-Hellman问题。IBE涉及下面的数学工具和参数假设E是在有限域F上的椭圆曲线，并且假设P是大素数阶的点。
假设e =ExE- — G是在E上的双线性映射。典型的例子是W^eil配对，并且因此G 将是第η个单位根(n-th roots of unity)的群组，其中η是在F上的E上的点数的函数。假设s是非零正整数并且是在密钥生成函数(KGF)中存储的秘密。这是系统范围的秘密并且不表露在KGF之外。假设Ppub = sP是所有参与者已知的系统的公共密钥。记住sP表示E中的点，因为E是一个群组。假设H1是已知的散列函数，该散列函数获取串并且将其分派给椭圆曲线上的点， 艮口，在E上H1 (A) = A，其中A通常是身份，并且也是A的公共密钥。假设dA = sA是由KGF计算的并且仅递送给A的私有密钥。假设H2是已知的散列函数，该散列函数获取G的元素并且将其分派给串。假设m是必须被加密和发送给A的消息。由Boneh和Franklin描述的加密函数如下假设仏=e (Qa, Ppub)，并且假设r是随机数。EncryptionA(m) = (rP，m xor H2 (gAr))；换句话说，m的加密输出具有两个坐标u 和V，其中U = rp且V = m xor H2 (gAr)。注意到“xor”指的是异或逻辑函数。为了解密(u，ν)，A使用下面的公式来恢复m m = ν xor H2 (e (dA, u))。对该公式的证明是双线性映射中的简明练习(straight forward exercise)，并且实际上A具有秘密dA (仅是A知道私有密钥，而其它参与者并不知道私有密钥)。而且观察到，首先计算dA的KGF也可以解密该消息，从而导致KGF是事实上的密钥托管服务器。B.基于身份的认证密钥交换在2009年2月17日提交的通过序列号No. 12/372，242标识的美国专利申请中描述了基于身份的认证密钥交换(IBAKE)，通过引用的方式将其公开内容合并于此。IBAKE协议允许设备彼此相互认证，并且导出提供了完美前向和后向保密的密钥。在这里描述的IBAKE实施例中，该协议的基本设置涉及以上在子章节A中讨论的数学构造和参数。记住该协议是不对称的，但并不要求任何PKI支持；相反，该协议采用了充当密钥生成函数的离线服务器。下面概述了该协议的细节假设A、B是正在尝试认证和商定密钥的两个实体(或者两方，其中A表示第一方的计算机系统，并且B表示第二方的计算机系统)。将使用A和B来表示它们对应的身份，其按照定义也表示它们的公共密钥。假设H1OV) = A和氏⑶=%是与公共密钥相对应的在椭圆曲线上的相应点。实际上，也可将A和( 称为公共密钥，因为在身份与通过应用H1所获得的曲线上的点之间存
在一对一的对应性。假设χ是由A选择的随机数，并且假设y是由B选择的随机数。在A和B之间的协议交换包括以下步骤在第一步骤中，A计算xP(即，在E上使用加法定律，P与其自身相加χ次作为E上的点)，使用B的公共密钥来对其进行加密，并且将其传送到B。在该步骤中，加密指的是以上在子章节A中描述的基于身份的加密。在接收到已加密的消息时，B解密该消息并获得xP。随后B计算yP，并且使用A的公共密钥来加密该对IxP，yP}，并且然后在第二步骤中将其传送给A。在接收到该消息时，A解密该消息并获得yP。随后，A使用B的公共密钥来加密yP 并在第三步骤中将其发回给B。在此之后，A和B都将xyP计算为会话密钥。观察到A随机地选择χ并且在协议交换的第二步骤中接收到yP。这允许A通过使yP与其自身相加χ次来计算xyP。相反地，B随机地选择y并且在协议交换的第一步骤中接收到xP。这允许B通过使χΡ与其自身相加y次来计算xyP。注意到该协议的任何应用均可以利用具有身份的头部数据来确保协议正确地起作用。这是相对标准的并且几乎适用于针对密钥协定的任何协议交换。还注意到，χ是随机的但xP却不提供关于χ的任何信息。因此，xP是基于由A选择的随机秘密的密钥的分量。类似地，y是随机的但yP却不提供关于y的任何信息。因此， yP是基于仅B已知的随机秘密的密钥的分量。进一步注意到，xyP可以充当会话密钥。而且，该会话密钥可以是xyP的任何已知函数。也就是说，该会话密钥可以等于f(xyP)，其中f对于两方来说都是已知的并且不要求其是秘密(即，公诸于世)。对f的一个实践要求应当是在没有χ或y的知识的情况下是难以计算f的，并且从密码的角度来看，输出具有满意的长度，例如大约1 个比特或更多比特。 IBAKE协议的一些属性包括-免于密钥托管观察到在协议交换中的所有步骤都使用IBE来进行加密。因此显然KGF可以解密所有的交换。然而，KGF无法计算会话密钥。这是因为椭圆曲线 Diffie-Hellman问题的困难性。换句话说，给定xP和yP，在计算上难以计算xyP。-相互认证密钥协定观察到在协议交换中的所有步骤都使用IBE来进行加密。 特别地，在第一和第三步骤中仅B可以解密由A发送的消息的内容，并且类似地，在第二步骤中仅A可以解密由B发送的消息的内容。此外，在第二步骤结束时，A可以验证B的真实性，因为仅在由B在第一步骤中解密了内容之后才可在第二步骤中发送xP。类似地，在第三步骤结束时，B可以验证A的真实性，因为仅在正确地解密了第二步骤的内容(而这仅通过A才是可能的)之后才可在第三步骤中发回yP。最后，A和B都可以商定相同的会话密钥。换句话说，该协议是基于IBE的相互认证密钥协定协议。在以上描述提供了用于协议的安全性的动机时，可以容易地提供安全性的密码证明。该协议的困难性依赖于椭圆曲线 Diffie-He 1 Iman问题的困难性，其受到椭圆曲线的选择的影响。-完美前向和后向保密由于X和y是随机的，因此XyP总是新鲜的并且与A和B 之间的任何过去或未来的会话不相关。-无口令IBAKE协议并不要求在A和B之间的口令或秘密密钥的任何离线交换。 实际上，该方法显然适用于通过任何通信网络第一次通信的任何两方。唯一的要求是确保 A和B都知道彼此的公共密钥，例如，通过目录服务。II.安全密钥管理和说明性扩展已经意识到，因特网已从尽力而为数据网络快速演进到支持包括多媒体在内的各类业务的多服务IP(因特网协议)网络。这伴随着移动无线网络的快速成长，并且已经产生了技术挑战。从技术视角来看，已经很好地合理解决的中心挑战是呼叫控制功能(包括发信号通知建立呼叫)与应用层业务(常被称为“媒体平面”)的分离。诸如H323(参见例如国际电信联盟标准化组(ITU-T)建议H. 323，通过引用的方式将其公开内容合并于此)、 会话发起协议或SIP(参见例如因特网工程任务组IETF RFC 3沈1，通过引用的方式将其公开内容合并于此)和IMS(参见例如3GPP技术规范TS 23. 218、TS 23. 228、TS 24. 228、TS 对.2四和TS 24. 930，通过引用的方式将其公开内容合并于此)的呼叫控制协议已经由诸如IETF和3GPP的各种组织进行了标准化，并且处于在固定和移动网络上采用的各个阶段。同时，已经合并了用于确保各种级别的信令安全性的详细机制。然而，在媒体平面中，虽然诸如传输层安全性或TLS(参见例如IETF RFC 2M6，通过引用的方式将其公开内容合并于此)、安全实时传输协议或SRTP(参见例如IETF RFC 3711，通过引用的方式将其公开内容合并于此)和安全多用途因特网邮件扩展或SMIME(参见例如IETF RFC 2633，通过引用的方式将其公开内容合并于此)的协议提供了用于各种应用的容器格式，但是媒体平面中的安全性解决方案缺少用于支持应用层中的端到端安全密钥管理的一致性和标准化的方法。本发明的原理主要解决该问题。特别地，本发明的原理为媒体平面提供了一种可扩展的应用和协议不可知安全密钥管理框架。在说明性框架中，本发明的解决方案利用以上在章节I. B中描述的不对称(因此是公共密钥)基于身份的认证密钥交换(IBAKE)协议。说明性实施例描述了密钥交换机制以支持各种特征，举例来说，诸如安全的两方媒体平面通信、安全多方会议、安全呼叫分路、安全呼叫重定向，以及安全迟延递送应用。除了提供用于安全密钥管理的可扩展框架之外，该设计和框架的一些示例性方面还包括-使用离线密钥管理服务器(KMS)，其显著降低了所需网络支持的复杂性。记住在公共密钥设置要求中不对称协议总是精心设计了支持证书管理(包括撤回)的公共密钥基础设施(PKI)。基于对称密钥的密钥管理服务器按照定义是“永远在线(always on) ”服务器，具有恒定的同步和更新。通过消除“永远在线”要求，本发明的框架显著降低了成本并支持可扩展性。-消除在基于身份的协议中固有的任何被动密钥托管。记住具有密钥管理服务器的对称密钥协议无法消除该问题。而且，回想到(以上在章节I. A.中描述的)现有基于身份的加密协议存在密钥托管问题；使用(以上在章节I. B.中描述的)IBAKE来解决问题。-协议框架固有地支持在密钥交换中涉及的伴随有完美保密的实体的相互认证。-本发明的说明性实施例重用了现有网络元件架构，并且尽可能多地重用现有协议容器格式。例如，在会议应用中，说明性实施例重用了会议服务器来启用会议，但确保会议服务器不知道用于通信的群组密钥(除非其也是该会议的一方，如下面将解释的)。-尽管本发明的原理消除了被动密钥托管，但是当存在对拦截呼叫的执法的合法要求时，本发明的协议也提供对于发现密钥的无缝支持。在根据基于身份的不对称密码框架的说明性实施例中，每个参与者均具有公共密钥和私有密钥。公共密钥是基于身份的。私有密钥对应于公共密钥并且由密钥管理服务器或服务(KMS)来发布。参与者可以离线地从KMS获得私有密钥。仅举例来说，参与者一个月与他们的KMS联系一次(更一般地，针对预订的长度)来获得私有密钥。私有密钥也可以根据使用的频率来获得。假定安全性关联存在于KMS和参与者之间。在密钥交换期间对消息的加密和解密是基于IBE。注意到，假定KMS的公共参数是公共可用的(例如，在线于Web站点上)。通常，根据本发明的说明性实施例的安全密钥管理方法包括两个主要阶段。在第一阶段中，参与者(各方)从诸如KMS这样的密钥服务获得私有密钥。在第二阶段中，在设法在基于多媒体的呼叫会话中进行通信的两方或更多方之间实施基于身份的认证密钥交换。在所述两方或更多方之间交换的消息是基于消息的接收者的相应身份来加密的。而且， 在各方之间交换的已加密的消息含有与各方相关联的身份。图IA示出了安全密钥管理方法的第一阶段，S卩，私有密钥获取。如图所示，两方的通信设备(更一般地，计算设备)102分别从相应的KMS104请求和获得私有(或秘密) 密钥。根据安全通信协议来实现私有密钥交换106。安全通信协议的例子包括但不限于 因特网协议安全性或IPkc (参见例如IETF RFC 2406、IETF RFC 2409、IETF RFC 4306和 IETFRFC 4308，通过引用的方式将其公开内容合并于此)以及传输层安全性或TLS (参见例如IETF RFC 2M6，通过引用的方式将其公开内容合并于此)。广义的自举架构或GBA(参见例如3GPP技术规范(TS)33. 220，通过引用的方式将其公开内容合并于此)可用于确定要在每一方和KMS之间的安全通信协议中使用的密钥。在一个例子中，可以具有在连接到 KMS服务器并在应用层中使用TLS的客户端设备中运行的应用(以上的传输控制协议或 TCP,参见例如 W. Richard Stevens. TCP/IP Illustrated, Volume 1 :The Protocols, ISBN 0-201-63346-9 ；W.Richard Stevens and Gary R. Wright. TCP/IP Illustrated, Volume 2 :The Implementation, ISBN0-201-63354-X ；W. Richard Stevens. TCP/IP Illustrated, Volume 3 :TCP for Transactions, HTTP, NNTP, and the UNIX Domain Protocols, ISBN0-201-63495-3，通过引用的方式将其公开内容合并于此)，其在网络层使用GBA密钥或IPkc，并且GBA密钥作为预先共享的密钥。注意到，左边的设备被认为是发起者(I)而右边的设备是响应者(R)。该指定是源自以下事实在左边的设备设法发起与右边的设备的多媒体呼叫会话。如图所示，每个设备向KMS提供标识符及其请求，KMS用私有(秘密)密钥对此做出响应。在发起者设备102-1的情况下，一个标识符被提供给KMS 104-1，并且一个私有密钥I-SK被提供给该设备作为响应。在响应者设备102-R的情况下，两个分离的标识符被发送给KMS 104-R，即，R和R1。作为响应，KMS向响应者提供两个私有密钥R_SK和R1_SK。当然，每一方可以基于某种私有密钥获取调度来请求和获得更多或更少的私有密钥。这可以是基于时间的调度(例如，一个月的时段)、基于呼叫会话频率的调度(例如，当需要进行呼叫时)和基于预订的调度(例如，该方预订了 KMS的密钥服务达到某个时间长度，或者基于预订结束条件的发生)。而且，应当理解，给定方可以具有多个公共身份。例如，B方(“Bob”)可以具有两个身份bob@work. com和bob@home. com。对于这两个身份，可以存在两个不同的公共密钥以及因而存在两个不同的私有密钥。图IB示出了安全密钥管理方法的第二阶段，S卩，认证密钥交换。在该实施例中，认证密钥交换是基于IBAKE(以上在章节I. B.中描述的)。由于在第一方和第二方之间的消息交换的优选格式是基于多媒体因特网密钥(MIKEY)格式，因此图IA和图IB的整个安全密钥交换协议在此被称为MIKEY-IBAKE协议。再次假定左边的设备是发起方或发起者102-1，而右边的设备是响应方或响应者102-R。认证密钥交换的步骤遵循与IBAKE协议类似的步骤。假定通过使用如以上在章节I中描述的散列函数来计算发起者的公共密钥I_PK。 类似地，以类似的方式来计算响应者的公共密钥R_PK。记住发起者和响应者的私有密钥分别是 I_SK 和 R_SK。也就是说，假设 H1 (Initiator_ID) = I_PK 和 H1 (Responder_ID) = R_ 1 是与公共密钥相对应的椭圆曲线上的相应点。假设a是由发起者102-1选择的随机数，并且假设b是由响应者102-R选择的随机数。在102-1和102-R之间的协议交换包括以下步骤在步骤110中，发起者102-1计算第一随机密钥分量aP (即，在E上使用加法定律， P与其自身相加a次作为E上的点)，使用响应者的公共密钥(R_PK)来加密第一随机密钥分量，并且将其传送给响应者102-R。在该步骤中，加密指的是以上在子章节I. A.中描述的基于身份的加密。注意到在步骤110中，还包括在已加密的消息中的是发起者和响应者的身份(分别是I—ID和R_ID)。在接收到已加密的消息时，响应者使用(在图IA中获得的)其私有密钥来解密该消息并且获得aP。随后，在步骤112中，响应者计算第二随机密钥分量bP，使用发起者的公共密钥来加密该对laP，bP}，并且然后将该对传送给发起者。再者，在步骤112中已加密的消息包括发起者和响应者的身份(分别是I_ID和R_ID)。在从步骤112接收到该消息时，发起者使用(在图IA中获得的)其私有密钥来解密该消息并且获得bP。随后，在步骤114中，发起者使用响应者的公共密钥来加密bP并且将其发送回给响应者。再者，在步骤114中已加密的消息包括发起者和响应者的身份(分别是 I_ID 和 R_ID)。在步骤116中，响应者向发起者发送使用发起者的公共密钥来加密的验证消息。在此之后，发起者和响应者都计算abP，作为在经由多媒体通信系统的媒体平面 (应用层)的呼叫会话期间与彼此安全通信要使用的安全呼叫会话密钥。观察到，发起者102-1随机地选择a，并且在协议交换的第二步骤中接收到bP。这允许发起者通过将bP与其自身相加a次来计算abP。相反地，响应者102-R随机地选择b， 并且在协议交换的第一步骤中接收到aP。这允许响应者通过将aP与其自身相加b次来计算abP。还注意到。a是随机的但aP却不提供关于a的任何信息。因此，aP被认为是基于由发起者所选择的随机秘密的密钥的分量。类似地，b是随机的但bP却不提供关于b的任何信息。因此，bP被认为是基于仅响应者知道的随机秘密的密钥的分量。现在参考图2，图示了 MIKEY-IBAKE协议的扩展。应当明白，由于这是对上述 MIKEY-IBAKE协议的扩展，因此出于简单起见，没有重复MIKEY_IBAKE协议的所有特征。在该特定实施例中，图2图示了分路。分路是将请求递送到多个位置。这可以例如当响应者具有不止一个通信(计算)设备(他/她可以在该设备上参与多媒体呼叫会话)时发生。 分路的一个例子是当一方具有桌面电话、个人计算机(PC)客户端和移动手机时，它们全都被配置以便参与MIKEY-IBAKE协议。一般而言，分路是多媒体会话发起协议的特征，其使得来话呼叫能够同时对若干个扩展进行振铃。然后，应答的第一电话将控制该呼叫。因而，如图2所示，响应方具有与其相关联的两个设备102-R1和102-R2。因而，如图所示，设备102-R1具有公共密钥R1_PK和秘密密钥R1_SK。而且，设备102-R1知道响应方的公共和私有密钥，R_PK和R_SK。类似地，设备102-R2具有公共密钥R2_PK和秘密密钥 R2_SK。而且，设备102-R2知道响应方的公共和私有密钥，R_PK和R_SK。在分路情形中，MIKEY-IBAKE协议步骤210、212、214和216基本上与图IB的一般情境中的MIKEY-IBAKE协议步骤110、112、114和116相同，但是有下面的例外。注意到，因为在步骤210中由设备102-1发送的消息是用RJ3K来加密的，所以设备Rl和R2都可以解密该消息(因为它们都具有R_SK)。然而，假定响应方当前与设备R2而不是设备Rl相关联，那么在步骤212中，返回消息包括由R2依照IBAKE来计算的随机密钥分量Id2P(其中1^2 是由R2选择的随机数)。而且，在步骤212中已加密的消息包括发起者、响应者和设备R2 的身份(分别是I_ID，R_ID和R2_ID)。设备102-1使用其私有密钥来解密从R2接收到的消息，以便获得b2P和在该消息中包括的身份。发起者因而标识出在步骤212中的消息来自R2。依照MIKEY-IBAKE协议， 发起者然后在步骤214中发送包括Id2P、I_ID、和R2_ID的消息。该消息是使用R2的公共密钥来加密的。注意到这无法由Rl来解密，因为Rl仅具有R_SK和R1_SK，而没有R2_SK。 步骤216是与图IB中的步骤116类似的验证消息。然后可以在设备102-1和设备102-R2 处将呼叫会话密钥计算为ab2P。图3图示了 MIKEY-IBAKE协议对重定目标特征(retargeting feature)的扩展。 应当明白，由于这是对上述MIKEY-IBAKE协议的扩展，因此出于简单起见，没有重复MIKEY_ IBAKE协议的所有特征。重定目标或重定向是以下情形通信系统中的一个或多个功能元件决定将呼叫重定向到不同的目的地。这种重定向会话的决定可以出于不同的原因由多个不同的功能元件并在会话建立中的不同点处进行。这也被称为呼叫转发。图3的例子示出了进行重定向确定的应用服务器302。在分路情形中MIKEY-IBAKE 协议步骤310、312、314和316基本上与图IB的一般情境下的MIKEY-IBAKE协议步骤110、 112、114和116相同，但是有下面的例外。设备102-1在步骤310中在该协议中发送第一消息，预计其去往设备102-R1 (用 Rl的公共密钥来加密该消息)。然而，功能元件302作出决定在310中的消息应当被重定向到设备R2，参见步骤310’。在此之前，或者与其相结合地，假定R2经由该功能元件在步骤308所发送的消息中接收到Rl的私有密钥。使用R2的公共密钥来加密从Rl发送到R2 的消息。因而，功能元件302无法解密在308中的该消息，但是R2可以在310’中解密该消息并且在步骤312中对发起者做出响应。从这一点来看，步骤312、314和316与图2的分路情形中的步骤212、214和216相同。图4A示出了 MIKEY-IBAKE协议的迟延递送扩展。应当明白，由于这是对上述 MIKEY-IBAKE协议的扩展，因此出于简单起见，没有重复MIKEY_IBAKE协议的所有特征。迟延递送是使得会话内容在其被发送时无法被递送到目的地的一类服务(例如，目的地用户当前不在线)。然而，发送者希望在接收者一变得可用时网络就递送该消息。迟延递送的一个例子是语音邮件。在图4A中，假设A是设备102-1，B是102-R，设备402是诸如应用服务器的功能元件，并且MB是与B相关联的邮箱102-MB (更一般地，是临时目的地)。在步骤401中，A向B发送包括已加密的第一随机密钥分量(xP)的第一消息。在 A处计算第一随机密钥分量，并且使用B的公共密钥来加密第一消息。功能元件402确定B不可用，并且在步骤402中将该第一消息转发到MB。在步骤403中，MB向A发送包括由MB计算的已加密的第二随机密钥分量(yP)的第二消息。在步骤403中使用A的公共密钥在MB处加密该消息。在步骤404中，功能元件 402将该消息发送到A。A使用由A从密钥服务获得的私有密钥来解密来自MB的消息，以便获得第二随机密钥分量。A标识出在步骤404中接收到的消息来自MB (由于MB的身份被包括在该消息中)。在步骤405中，A(在步骤406中经由功能元件)向MB发送包括已加密的随机密钥分量对的第三消息，所述随机密钥分量对是根据第一随机密钥分量(χΡ)和第二随机密钥分量(yP)来形成的，并且使用MB的公共密钥在A处进行加密。该第三消息还包括在A处计算的并且使用B的公共密钥在A处加密的已加密随机秘密密钥(SK)0经由步骤407和步骤408，MB向A确认接收。MB无法解密该消息的后面部分(因为是使用B的公共密钥来对其加密的并且MB并不具有B的私有密钥)，并且因而无法知道sK。在B和MB之间的相互认证操作之后，经B请求，MB向B提供已加密的随机秘密密钥(sK)。这在步骤409和410中示出。该秘密密钥然后由B用来获得由A留在B的邮箱中的内容(例如，语音消息)。在图4A的迟延递送的变体中，如图4B中所示，假定没有实施认证密钥协定协议， 而是在第一消息中，A发送在A处计算的并且在A处使用B的公共密钥来加密的已加密随机秘密密钥(sK)(步骤411)。功能元件402(其已经确定B不可用)将第一消息转发到MB(步骤412)，MB对其进行确认(步骤413和414)。稍后，B可以按照与上述相同的方式从MB中检索秘密密钥(步骤415和416)。图5示出了 MIKEY-IBAKE协议的又一扩展。再次应当明白，由于这是对上述 MIKEY-IBAKE协议的扩展，因此出于简单起见，没有重复MIKEY_IBAKE协议的所有特征。图 5中的扩展涉及在多媒体通信系统中交换的消息的合法拦截的概念。合法拦截的概念是基于当执法机构需要能够“侦听”一方或多方的通信时的情形。在一个方法中，执法机构可以简单地通过搜查证来获得102-1和102-R的私有密钥，并且在密钥商定协议期间扮演有效的“中间人”，然后接入(tap into)到业务中。在图5中示出的另一个方法中，执法服务器(Li服务器)502与发起者的KMS (KMS1) 和响应者的KMS(KMSk) —起起作用，以便合法地拦截在设备102-1和设备102-R之间发送的消息。虽然图5示出了用于LI服务器、KMS1和KM&的分离的服务器，但是应当理解，多媒体通信系统中的一个功能元件(例如，拦截服务器)可用于实现KMS和拦截功能。因此，实现了如以上在图IA和IB的情境下所描述的MIKEY_IBAKE协议。然而，LI 服务器针对被发送到响应者的消息来模仿发起者，并且针对被发送到发起者的消息来模仿响应者。例如，考虑当LI服务器模仿响应者时的消息流。假定102-1发送希望由102-R接收的第一消息，其包括已加密的第一随机密钥分量。第一消息被LI服务器拦截。LI服务器然后计算第二随机密钥分量并且将包括了已加密的随机密钥分量对的第二消息发送到 102-1。随机密钥分量对是根据第一随机密钥分量和在LI服务器处计算的第二随机密钥分量来形成的。使用102-1的公共密钥在LI服务器处加密第二消息。
使用由102-1从密钥服务获得的私有密钥来解密第二消息，以便获得第二随机密钥分量。设备102-1然后发送希望由102-R接收的包括第二随机密钥分量的第三消息，但是其被LI服务器拦截。因而，LI服务器能够计算设备102-1所计算的相同的安全密钥。应当明白，LI服务器还模仿发起者(102-1)在认证密钥协定操作期间发送和接收消息，从而使得响应者(102-R)与LI服务器建立响应者认为是发起者同意的(但实际上是 Ll服务器同意的)安全密钥。应当理解，上述MIKEY-IBAKE协议特征中的一个或多个特征可以扩展到会议系统情形。图6A至图6C中描述了这样的扩展。一般的假设是中继了多方通信(例如，会议桥)的会议服务器(更一般地，会议管理元件)并不知道群组密钥，尽管所有的用户都取得了相同的群组密钥。该假设存在例外，即，在对等会议中，当充当会议桥的计算设备实质上也是参与该会议的一方时。如图6A所示，假定多方会议600包括会议服务器和用户(各方)1至N，其中，按照用户设法加入会议的顺序来分派用户编号，即，依序地1，2，3，... N。在步骤602中，每个用户单独地与会议服务器执行IBAKE协议。假设& = ^P是在与服务器认证期间由用户“I”发送到会议服务器的值。记住af是依照IBAKE由该方所计算的随机密钥分量。在认证成功之后，在步骤604中，会议服务器(广播或单独单播地)将集合IaiPl 发送给每个用户。集合IaiPl因而是包括由各方中的每一方所计算的随机密钥分量。在步骤606中，每个用户单独地将Xi = a, (BitlP-Bi^1Pj发送回给会议服务器。注意到AlawP-^v1Pl是随机群组密钥分量，其中，由每一方经由基于以下内容的计算方法来计算随机群组密钥分量在密钥认证操作期间由该方所使用的随机数，以及由设法参与会议的两方或更多方中的其它方的子集计算的随机密钥分量。在该实施例中，用于给定方的随机群组密钥分量hk+iP-aHP}被这样计算，即， 是由给定方选择的随机数，ai+1P是由在会议排序中就在给定方之后的一方发送到服务器的随机密钥分量，Bi^1P是由在会议排序中就在给定方之前的一方所发送的随机密钥分量，并且P是选自与基于身份加密的密钥认证操作相关联的群组的点(例如，如上所述选自椭圆曲线的点)。在步骤608中，会议服务器(广播或单独单播地)然后与每一个人共享集合{XJ。 也就是说，集合{XJ是包括由各方所计算的随机群组密钥分量的集合。在步骤610中，每一方均可以计算用于在通过会议服务器与每个其它方的通信中使用的相同的群组密钥。群组密钥被计算如下=Nai (Zh) +(N-I)· · · +X"，其中N表示设法参与会议的各方的总数，a,表示由给定方选择的随机数，Zi表示由给定方计算的随机密钥分量，&表示由给定方计算的随机群组密钥分量，并且i表示在N方会议中对于给定方的会议排序的编号，其中当i = 1时，i-1 = N，并且当i = N时，i+Ι = 1。如上所述，会议服务器不是会议中的参与方，并且由此不能计算群组密钥。然而， 在对等情形下，会议服务器是会议呼叫中的参与方，并且由此需要能够计算群组密钥。应当明白，会议服务器实施与设法参与会议的每一方的相互认证操作。仅当满足至少两个条件时，会议服务器才批准给定方到会议(i)给定方被会议管理元件认证；以及 ( )给定方被确认属于会议授权列表。而且，依照以上MIKEY-IBAKE协议，设法参与会议的各方以及会议服务器从一个或多个密钥管理服务(KMS)获得相应的私有密钥。
图6B图示了如何将新的会议参与者(用户N+1)添加到正在进行的会议，因而得到了经修改的会议600’。在步骤612中，用户N+1与会议服务器执行IBAKE。假设ZN+1 = aN+1P是在与服务器认证期间由用户“N+1”发送到服务器的值。在用户N+1的认证成功之后，在步骤614中， 会议服务器宣告批准新的用户N+1并且(广播或单独单播地)将包括ZN+1的集合IaiPl发送给每一个人。在步骤616中，用户1、N、N+1将Xi = Bi (BitlP-Bi^1Pj发送回给服务器；交替地，他们全都可以执行该步骤。在步骤618中，会议服务器然后(广播或单独单播地)与每一个人共享包括Xiw的集合{XJ。然后在步骤620中重新计算群组密钥(Ν+1) (Ζη)+ (N)Xi+(N-I) Xi+1+. . . . +Χ"。观察到，群组密钥在批准新用户之后发生改变。图6C图示了会议参与者如何退出正在进行的会议，因而得到了经修改的会议 600”。假定用户3退出呼叫(应当明白，选择用户3仅是示例)。在步骤622中，会议服务器(广播或单独单播地)宣告哪一个用户退出了呼叫。在步骤624中用户排序发生改变。用户1和2保持相同。对于大于或等于4的所有i，用户i变为用户i-Ι。在步骤626 中，用户4 (其现在是用户3)重新计算&并且与会议服务器共享该结果(contribution)。 在步骤6 中，会议与所有参与者共享集合{XJ。在步骤630中，参与者重新计算群组密钥 (N-Dai (2^) + (^2)^+(^3)^+. . . . +Χ"。再次观察到，在参与者退出呼叫之后，群组密钥发生改变。本发明的原理还提供了对以上描述的会议管理技术的扩展。该扩展涉及对会议消息的合法拦截。假设会议系统中存在N个参与者。假定参与者N“受污染(tainted) ”并且执法机构已经获得许可证来接入到去往和来自参与者N的呼叫中。选择宣称参与者N受污染仅用于说明，并且使得描述易于理解，并且该解决方案决不限于将第N个用户宣称为受污染用户。在会议呼叫之前，LI服务器(回想在图5中)接洽与参与者N相对应的KMS并且获得参与者N的私有密钥。这将允许LI服务器在群组密钥交换过程期间假装是参与者N 并且执行图6A中的所有步骤，除了参与者N的贡献被替换为来自LI服务器的贡献。特别地，LI服务器用L和Xu来替换\和\。其余的参与者将不知道该差别，并且将计算群组密钥，称其为GK’。接下来，LI服务器与会议服务器一起工作，并且在与参与者N的所有通信中将Z1 和&替换为、和1。这将意味着参与者N将计算出与GK’不同的群组密钥。将该新的密钥称为GK”。注意到，在以上的步骤中，对于任何参与者，LI服务器都会将τ、和\替换为L和 I，并且选择i = 1仅用于说明。在建立呼叫之后，将使用GK’来加密来自参与者1至N-I的任何通信。由于LI服务器知道GK’，因此它然后可以拦截该通信，对其进行解密，之后它将用GK”对其进行重新加密，并将其发送给参与者N。相反地，将使用GK”来加密来自参与者N的任何通信，其将被 LI服务器拦截，然后使用GK”进行解密，使用GK’重新加密，并且发送到参与者1至N-I。
III. IMS 实施例在下面的章节中，MIKEY_IBAKE的以上一般原理及其扩展被应用于IP多媒体子系统(IMQ环境。也就是说，在该章节中，多媒体通信系统被认为是IMS网络。例如，在3GPP 技术规范 TS 23. 218、TS 23. 228、TS24. 228、TS 24. 229 和 TS 24. 930 中描述了 IMS 标准， 通过引用的方式将其公开内容合并于此。首先描述用于IMS媒体平面安全性的架构框架，具体针对密钥管理，基于这些可以导出各种特征和使用情况。该解决方案的核心是基于身份的加密(IBE)概念，类似于RFC 5091、RFC 5408和 RFC 5409，通过引用的方式将其公开内容合并于此。然而，这些RFC并没有提供认证并且存在固有的密钥托管问题。在此通过扩展基本IBE以便包括基于身份的认证密钥交换(IBAKE)协议(其提供相互认证)来解决这些问题，消除了被动密钥托管，并且提供了密钥的完美保密。虽然IBAKE是基本协议构造，但这里使用MIKEY作为用于密钥递送的协议容器。关于本发明的IMS解决方案框架的一个关键思想是重用包括KMS的所建议的架构，但是明显地并不要求这些KMS服务器总是在线。换句话说，在所建议的框架中，KMS是定期(例如，一个月一次)与终端用户通信的离线服务器，以便创建基于安全身份的加密框架，而终端用户客户端之间的在线事务(针对媒体平面安全性)是基于允许参与的客户端在不对称的基于身份的加密框架中交换密钥分量的IBAKE框架。该框架除了消除被动托管之外，还允许终端用户客户端(在IMS媒体平面层)彼此相互认证并提供完美的前向和后向保密。观察到，KMS到客户端的交换被保守地(sparingly)使用(例如，一个月一次)_因此不再要求KMS是高可用性服务器，并且特别地，不同的KMS不必(跨运营商边界)彼此通信。此外，假定使用不对称的基于身份的加密框架，则消除了对高成本公共密钥基础设施 (PKI)以及有关证书管理和撤回的所有操作成本的需要。另外，各种IMS媒体平面特征得到安全的支持-这包括安全分路、重定目标、迟延递送、预编码的内容、媒体剪辑以及匿名性。该解决方案的扩展实现了安全会议应用，其中IMS会议应用服务器认证用户进入到呼叫，但是该呼叫的所有参与者(在每个人的贡献下)决定群组密钥，而会议服务器自身却不知道该群组密钥。此外，该群组密钥可以被修改以便反映新的参与者以及退出呼叫的参与者。基于IMS的密钥管理框架的附加特征是尽管消除了被动密钥托管，但是它支持在使用主动托管概念的执法情况下对安全性凭证进行合法共享。图7提供了在IMS媒体平面中的示例性端到端密钥交换协议中所涉及的示意性架构以及实体。应当明白，由于IMS架构是公知的，因此没有详细描述图7中所示的功能组件。 可以参考用于详细解释它们的功能的IMS标准。注意到，如已知的，CSCF指的是呼叫会话控制功能，由此，P-CSCF是代理CSCF并且S-CSCF是服务CSCF。NAF指的是网络应用功能。在图示的情形中，两个支持IMS的终端用户电话参与了端到端(e2e)密钥交换以便保证应用层中的通信安全。注意到，该图示包括在UE(用户设备)与KMS之间的离线事务以及通过IMS的在UE之间的在线事务。观察到，UE和KMS共享预配置的安全性关联，其中，用户可以与密钥管理服务器建立安全连接，并且其中提供了相互认证。在3GPP系统的情境中的一个自然例子是使用广义的自举架构(参见例如3GPP TS 33. 220，通过引用的方式将其公开内容合并于此)。在图 7中，通过BSF(自举服务器功能)来启用在KMS和UE之间的事务，并且记住该事务被保守地执行(例如，一个月一次)。注意到，如果GBA不可用，则诸如具有预共享密钥或证书的 IKEv2这样的其它类型的凭证(参见例如IETF RFC4306，通过引用的方式将其公开内容合并于此)可用于建立在用户和KMS之间的该相互认证。在该事务期间，UE呈现其预订凭证，之后KMS生成(在IBAKE中使用的)私有密钥集合。如果该事务一个月执行一次，那么KMS可以选择为每一天生成一个密钥。密钥的数目以及该交换的频率是策略的问题，并且其可以与预订相关。该灵活性对于预付费消费者尤其有用。注意到，不是单个KMS，而可能涉及两个不同的KMS ；—个用于用户A，S卩，KMS_A，而一个用于用户B，S卩，KMS_B。然而，KMS_A和KMS_B不必彼此通信。该情形尤其适用于运行商之间的情形。现在给出在IMS情境下MIKEY-IBAKE中所涉及的交换的简短总结。假设A、B是正在尝试认证和商定密钥的两个用户。同时，A和B表示它们的对应身份，按照定义其还表示它们的公共密钥。假设H1 (A) = * ^) = ( 是与公共密钥相对应的椭圆曲线上的相应点。实际上，也可以将A和( 称为公共密钥，因为在身份与通过应用H1所获得的曲线上的点之间存在一对一的对应性。假设X是由A选择的随机数，并且假设y是由B选择的随机数。下面的加密指的是如上在章节I中所描述的基于身份的加密。基于IMS的MIKEY-IBAKE协议交换包括以下步骤(参考图7中示出的组件)1.属于用户A的IMS UE向BSF自举以便能够与充当NAF的KMS建立安全连接。 这允许BSF认证该用户并且该用户间接认证KMS。如果无法使用GBA，则IMS UE连接到KMS 并对其进行认证，并且基于预先建立的安全性关联来建立共享密钥。2. IMS UE从事与KMS的MIKEY交换，并且请求秘密密钥(或者多个秘密密钥，例如用于每一天的一个秘密密钥)。3. KMS为用户A的IMS UE生成(一个或多个)媒体秘密密钥并且将其发送给用户 A04.用户A的IMS UE计算xP ( S卩，在E上使用加法定律，将P与其自身相加χ次作为E上的点)，使用B的公共密钥对其进行加密，并且将其传送给用户B的IMS UE。5. IMS核心检测到INVITE并且按照以下方式对其进行处理网络功能如果被授权则可以获取会话密钥。特别地，该步骤仅适用于支持满足任何合法拦截要求所需要的主动托管特征。6.用户B的IMS UE接收包括已加密的xP的INVITE。用户B的IMSUE解密该消息并获得xP。随后B计算yP，并且使用用户A的IMS UE的公共密钥来加密该对{xP，yP}， 然后在响应消息中将其传送到A。7.在收到该消息时，用户A的IMS UE解密该消息并获得yP。随后用户A的IMS UE使用B的公共密钥来加密yP，并且在响应确认消息中将其发送回给B。之后，A和B都计算xyP作为会话密钥。8.此时，用户B的IMS UE接受该邀请和对媒体安全性的使用。观察到A随机地选择X，并且在协议交换的第二步骤中接收到yP。这允许A通过将yP与其自身相加χ次来计算xyP。相反地，B随机地选择y，并且在协议交换的第一步骤中接收到χΡ。这允许B通过将χΡ与其自身相加y次来计算xyP。从MIKEY-IBAKE协议产生的一些有利属性如下。相互认证。观察到，使用B的公共密钥来加密在步骤4和7中的有效载荷的内容。 因此B并且仅是B可以解密这些消息。类似地，在步骤6中的消息的内容可以由A并且仅可由A来解密。还注意到，步骤6和7允许B和A(通过证明消息被正确解密)进行彼此认证。该新颖的特征允许A和B在没有任何在线服务器或证书机构的帮助下相互认证。完美保密。观察到，χ和y是随机的。因此会话密钥xyP是新鲜的并且与过去或未来的事务没有关系。消除了被动托管。观察到，虽然KMS(或一对KMS)可以对交换中的消息进行解密，但是在给定χΡ和yP的情况下却难以确定xyP。该困难性假定取决于椭圆曲线上的 Diffie-Hellman问题。还注意到，用于IBE的曲线是特定于KMS的，并且此外不需要与用来生成会话密钥的曲线相同。该灵活性提供了大范围的选择性，并且还消除了 KMS之间所需的任何协调。身份管理。如上所述，为了加密消息，发送者使用接收者的公共密钥，该公共密钥是使用接收者的身份(或身份之一)来生成的。接收者的身份可以采用指定了特定用户、 一组用户或任何用户的格式。用户和用户群组的命名可以遵循标准的IMS管理并且可以通过使用通配符来进行扩展。在涉及群组应用的某些情形下，可能自然的是采用以下策略 允许该群组中的所有接收者使用与该特定用户组的身份相对应的秘密密钥。例如，对于企业用户，可能自然的是默认与企业的身份相对应的秘密密钥被分发到所有的企业用户。 注意到，由于基于身份的加密的属性，因此，尽管属于一个群组的所有用户都可能拥有该群组的秘密密钥，但是不是所有用户都可以获得在发送者与属于该相同群组的某个其它用户之间所建立的会话密钥。为了确保实施策略，还需要公共用户身份可以被安全地绑定到 IMSUE。换句话说，对用户所使用的身份来说，重要的是针对KMS来对公共身份(的集合) 进行认证。现在讨论MIKEY-IBAKE协议对于各种基于IMS的使用情况的那些情形的扩展。注意到，在章节II中总体上描述了这些扩展。下面的描述是在IMS环境的情境下。A.通过主动托管的合法拦截(Li)为了能够提供被拦截通信的清楚备份，必须满足下面的条件1.必须有可能拦截业务(信令和媒体这两者)。2.实际业务保护所使用的会话密钥必须可用。为了使会话密钥可用，要求KMS功能/服务。如上所述，业务保护所使用的实际会话密钥是在发送者和接收者之间生成的，因而不为KMS所知。因此，需要主动托管解决方案。在该情形下，对于KMS来说，为了获得用户A和B之间的会话密钥，需要在其自身与用户A之间建立有效会话密钥并且在其自身与用户B之间建立另一同时的有效会话。对于A，KMS假装是B，并且相反地，对于B，KMS假装是A。由KMS所扮演的该“中间人”角色被称为主动托管，并且类似于在PKI环境(其中证书机构生成“假证书”并处于交换的中间)中所使用的方法。在常规CA中使用的技术和本发明针对主动托管的方法之间的差别在于KMS不必生成假密钥。
在经由归属网络路由的信令业务的情况下，对归属网络中的信令业务的拦截可以在(一个或多个)SIP (会话发起协议)服务器处完成。然后，该信令业务需要被路由到合适的KMS，以便该KMS与对应的用户建立所需要的会话密钥。在漫游情形下，因为在IMS UE 和P-CSCF之间通常对SIP信令业务进行机密性保护，并且考虑到在当前部署中P-CSCF位于归属网络中，所以在受访网络中SIP信令仅以加密格式在承载级处可用。对于漫游情形，虽然已加密的SIP信令和内容将总是可用，但是为了拦截SIP信令并解密通信的内容，在受访网络和处理KMS的实体之间必须存在操作间协定。通常，KMS将驻留在归属网络中，从而使得对于由受访网络所实施的Li，需要与归属网络协作。与LI标准一致，当在加密中不涉及VPLMN(受访的公共陆地移动网络)时，在 VPLMN中仅已加密的内容将可用于Li。B.在不同的KMS域中的用户在不同的KMS域中的用户将通过不同的KMS来生成它们的秘密密钥。结果，不同集合的公共参数(例如，密码材料)可用于为不同的KMS域中的用户生成公共密钥和秘密密钥。为了确保适当的加密/解密，发送者和接收者需要知道由每一侧使用的确切公共参数。然而，如果一个KMS域中的用户需要向另一个KMS域中的用户建立安全呼叫，则所涉及的KMS并不需要协作。如在任何基于身份的密码协议中或者针对该问题的任何公共密钥协议那样，可以安全地假定交换所需要的公共参数是公共可用或进行公共交换的。C.端到中间(end-to-middle)的情形在端到中间的情形中，媒体保护是在IMS UE和网络实体之间。在从IMS UE发起呼叫时的情形下，呼叫的建立将遵循与用于端到端保护的呼叫相同的原理。进行发起的IMS UE使用网络实体的身份(例如，MGWC-媒体网关控制)，以便如上所述来加密xP，并且将其与INVITE —起进行发送。MGWC拦截该消息，并且按照进行接收的IMS UE会实施的相同方式来生成yP。然后，MGffC建立MGW以便具有针对IMS UE的媒体安全性。在PSTN(公共交换电话网络)中对媒体业务进行简单转发。对于针对IMS UE的来话呼叫，MGWC检查被注册用于所希望的接收者的至少一个终端是否已经注册了媒体安全性能力和偏好。如果没有能够进行媒体保护的终端，则简单转发该呼叫。否则，MGWC选择y并且生成yP。然后，MGWC(使用IMS UE身份)将已加密的 yP插入到INVITE中，并且针对在MGW和IMS终端之间的媒体业务发起对MGW中的媒体安全性的使用。D.密钥分路在该章节中，对基于IMS的MIKEY-IBAKE的情况讨论了分路。回想到以上在图2 的情境下在总体上描述了分路。分路是将请求(例如，INVITE消息)递送到多个位置。这发生在不止一次注册了单个IMS用户时。分路的例子是当用户使得桌面电话、PC客户端和移动手机全都用相同的公共身份进行注册的时候。在下面描绘的以及在图8的步骤1至8的情境下所示出的例子中，假定用户B的 IMS UE具有用单个公共用户身份B注册的多个联系地址。换句话说，Bl和B2都获得与公共身份B相对应的秘密密钥。在这种情况下，如果用户A的IMS UE想要联系用户B的IMS UE，则请求会被递送到Bl和B2这二者。假定B2对呼叫做出响应，那么B2首先使用与身份 B相关联的秘密密钥来解密所接收到的消息。然后，B2选择随机的y并向A发送包括了使用A的公共身份来加密的yP及其身份B2的消息。在接收到该消息时，用户A将其解密，意识到它正在与用户B2通信，并且发送响应确认消息，该响应确认消息包括使用B2的公共身份来加密的所接收到的yP。观察到，Bl能够解密从用户A接收到的使用B的公共身份来加密的消息，因此能够获得xP。然而，其不能解密从B2发送的消息，因为该消息是使用A的身份来加密的。因而，用户Bl不能获得yP。还注意到，即使Bl能够获得yP，它也仍然不能计算xyP。注意到， 在图7中，(M)_X表明使用X的身份来加密消息M。E.重定向在该章节中，对基于IMS的MIKEY-IBAKE的情况讨论了会话重定向(重定目标)。 回想到以上在图3的情境下在总体上描述了重定向。会话重定向是以下情形功能元件决定将呼叫重定向到不同的目的地。会话重定向启用了典型服务“无条件会话转发”、“忙会话转发”、“可变会话转发”、“选择性会话转发”和“无应答会话转发”。会话重定向存在两种基本情形。在一种情形下，功能元件(例如，S-CSCF)决定使用SIP REDIRECT方法来重定向会话。换句话说，功能元件将新的目的地信息传递到始发方。 结果，始发方向功能元件所提供的重定向目的地发起新会话。对于MIKEY-IBAKE的情况，这意味着始发方将在重定向目的地的身份的情况下发起新会话。在第二种情形下，功能元件决定在不通知始发方的情况下重定向会话。常见情形是目的地用户的S-CSCF确定会话要被重定向。在注册期间由'Cx-pull'从HSS(归属订户服务器)获得的用户简档信息可以含有复杂的逻辑以及引起会话重定向的触发器。在图9的步骤1至8所描绘的例子中，在不失一般性的情况下，假定用户B设置了会话转发到用户C。在该情况下，用户B在其用户简档中包括使用C的身份来加密的其秘密密钥SK_B。因此，一旦S-CSCF从用户A接收到消息并且判定该消息需要被重定向，则其在重定向到用户C的消息中包括B的已加密的密钥。在接收到该消息时，用户C对秘密密钥进行加密，并且进而对来自A的该消息进行加密。然后，用户C选择随机的y并且向A发送包括了使用A的公共身份来加密的yP及其身份C的消息。在接收到该消息时，用户A将其解密，意识到其正与用户C进行通信，并且发送响应确认消息，该响应确认消息包括使用 C的公共身份来加密的所接收到的yP。在图9中，(M)_X表明使用X的身份来加密消息M。F.迟延递送在该章节中，对基于IMS的MIKEY-IBAKE情况讨论了迟延递送。从章节II想到 迟延递送是使得会话内容在其被发送时无法被递送到目的地(例如，目的地用户当前不在线或决定不应答该呼叫)的一类服务。然而，发送者希望在接收者一变得可用时网络就递送该消息。迟延递送的典型例子是语音邮件。下面呈现了对基于IMS的MIKEY-IBAKE情况的迟延递送的两种基本情形。可以返回参考用于第一情形的图4A和用于第二情形的图4B。在第一种情形下，用户A和B的邮箱在它们商定要用于解密打算迟延递送的消息内容的密钥之前实施相互认证，而在第二种情形下不实施相互认证。在第一种情形下(再次，可以返回参考图4A，其中功能元件402是IMS服务器)， 假定用户A正在尝试与用户B取得联系，用户B当前不可用，因此该呼叫被转发到B的‘语音邮箱’(更一般地，转发到迟延递送服务器)。遵循MIKEY-IBAKE协议，使用B的身份来加密由B的邮箱接收到的该消息，因此，B的邮箱将不能对其进行解密。B的邮箱选择随机的 y和计算yP，并且将IBE加密的yP及其身份发送到用户A。用户A认识到B没有接收到该消息并且实际的接收者由于缺少其身份和xP而不能解密在第一步骤中发送的该消息。因此，该用户发送含有全都使用B的邮箱身份来IBE加密的xP、yP、A的身份和B的邮箱身份的新消息。在接收到该消息时，B的邮箱接受“sK”作为用于针对B的消息的会话密钥，并且将A的身份和xP返回给用户A以便完成认证。观察到，使用B的公共密钥来加密sK ；因此邮箱B无法解密该消息和获得“sK”。 随后，当B在线并且检查‘语音邮件’(检查迟延递送服务器)时，B可以从邮箱服务器获得 sK的加密值。注意到，B可能必须与邮箱进行认证以便获得密钥-这可以基于已经存在的现有认证机制。在第二种情形下(再次，可以返回参考图4B，其中功能元件402是IMS服务器)， 相同的假定成立-用户A正在尝试与用户B取得联系，用户B当前不可用，因此该呼叫被转发到B的语音邮箱。然而，在这种情况下，B的邮箱和用户A并不实施认证。相反，B的邮箱仅接受sK作为会话密钥并且向用户A返回OK消息以便对其进行确认。G.群组和会议呼叫在该章节中，MIKEY-IBAKE的密钥管理协议被扩展到群组和会议呼叫。注意到，从 MIKEY-IBAKE协议产生的有利属性因此在会议环境中得到实现。回想到以上在图6A至图 6C的情境下总体上描述了会议。注意到，在图10中IMS例子用于N = 3。在图10的步骤1至18中描绘的基于IMS的情形下，假定存在邀请用户到会议呼叫的会议服务器(AS/MRFC-应用服务器/多媒体资源功能控制器)。这可能是由于例如先前从另一用户接收到的REFER请求导致的。备选方法会是将该功能委派给用户之一(例如， 会议主席)。尽管图10中没有示出该备选方法，但是该方法将是类似的并且对群组密钥的计算会是相同的。在下面的描述中，假定所有的消息都是使用合适的身份来进行IBE加密的(例如， 如果用户Y在向用户X发送消息M，那么使用X的身份来加密消息M)。在图10中，这被表示为(M)_X，意味着使用X的身份来对消息M进行IBE加密。在与会议服务器的第一交换集合中，用户ApA2和A3分别选择随机的 、 和 并且每个用户Ai向会议服务器发送Wi = ^P15在第二交换集合中，会议服务器向每一个用户发送所有的 Ρ，而每个用户发送Zi = (SwP-^1P)。在最后的交换中，会议服务器向每个用户发送所有的Zi。此时，所有会议参与者都能够将群组密钥计算如下=Ki = ^+2ζΛζι+ιο注意到,K1 = K2 = K30还注意到，虽然用户ApA2和A3能够生成群组密钥，但是会议服务器不能，因为虽然它知道Zi和^，但是仅用户单独知道它们随机选择的％。出于简单的原因，以上讨论集中于三个会议呼叫参与者。然而，以上过程可以推广到η个参与者。在η个参与者的情况下，群组密钥被生成为Ki = Imi 1^+(11-1)2,+ (11-2) zi+1+. · · +Zi_2，其中Wi和Zi的定义如上。该协议的重要特征之一在于每当批准了新用户或者现有用户退出呼叫时，群组密钥就改变。这确保新用户在他们被添加到该呼叫之前不知道群组密钥，并且过早离开呼叫的用户不能接入在该呼叫之后的会话。观察到，当添加新用户并且在系统中已经存在N个用户时，那么在系统中将总共
22存在N+1个用户。当将这些用户放置于圆中时，那么与第N个用户相邻的用户现在是第 (N+1)个用户(而不是第一个用户，这是在批准第N+1个用户之前的情况)。批准新用户的协议如下工作新用户使用IBAKE来与会议服务器进行认证，类似于每一个用户那样。这允许用户被批准(和被授权于该呼叫)，并且新用户被确保(经由会议服务器的认证)加入正确的会议。假设zN+1 = aN+1P是由新用户在认证期间选择的值。然后，会议服务器广播或单播地向所有用户发送针对所有i = 1至N+1的集合 {Zi}。这允许所有用户了解该新用户并确定他们的新邻居。观察到，邻居列表仅对于用户 1、N禾口 N+1发生改变。然后，用户1、N和N+1计算它们的w的对应值，并且(单独地)将其发送回给会议服务器。然后，服务器向所有用户发送已更新的IwJ列表。然后，所有参与者使用与以上相同的关系(除了的新值以及将N替换为 N+1之外)来重新计算群组密钥。当用户退出会议呼叫时，那么不必执行任何新的认证过程，但是群组密钥发生改变。该过程如下工作会议服务器获知退出会议呼叫的用户。随后，会议服务器向每一个人通知该事件以及与哪个用户(不仅是身份，而且还包括顺序)退出了该呼叫有关的信息。为了简化该问题，会议服务器可以重新发送新的列
表 IzJ。这允许所有用户重新发现他们的邻居，并且(如果需要的话)重新计算Wi。留在该呼叫中的所有那些参与者(对其来说Wi发生改变)将向会议服务器通知他们的新值。然后，会议服务器发送已更新的列表{Wi}。然后，所有参与者使用与以上相同的关系(除了使用Wi的新值以及将N替换为N-I 之外)来重新计算群组密钥。IV.说明性计算系统图11图示了根据本发明的按照适于实现两个实体之间的安全密钥管理协议的计算设备的形式的通信设备和网络环境的广义硬件架构1100。虽然图11仅示出了两个实体，但是应当明白其它实体也可以具有相同的配置。因而，就以上描述的安全密钥管理协议而言，这两个实体可以是发起者102-1(第一方或A)和响应者102-R(第二方或B)。然而， KMS、会议服务器、LI服务器、功能元件、附加客户端设备(各方)和附加服务器可以用相同的架构来实现，如图11的计算设备所示。因此，出于简单起见，图11中没有示出可以参与本发明的协议的所有计算设备(通信设备)。如图所示，标为1102的A的计算设备和标为1104的B的计算设备经由网络1106 耦合。网络可以是设备能够由此通信的任何网络，例如，如在以上所描述的实施例中，网络1106可以包括公共可接入的广域通信网络，诸如由网络运营商(例如，Verizon、AT&T、 Sprint)运营的蜂窝通信网络。然而，本发明不限于特定类型的网络。典型地，设备可以是客户机。在此描述的可以由参与协议的各方采用的客户端设备的例子可以包括但不限于 蜂窝电话、智能电话、桌上型电话、个人数字助理、膝上型计算机、个人计算机等等。然而，一个或多个设备可以是服务器。因而，应当明白，本发明的通信协议不限于计算系统分别是客户端和服务器的情况，而是可适用于包括两个网络元件的任何计算设备。如对本领域普通技术人员来说易于显见的，服务器和客户端可以被实现为在计算机程序代码的控制下操作的编程计算机。计算机程序代码将被存储在计算机可读存储介质 (例如，存储器)中，并且代码将由计算机的处理器来执行。给定本发明的该公开内容，本领域技术人员可易于产生合适的计算机程序代码以便实现在此描述的协议。尽管如此，图11总体上图示了用于在网络上通信的每个计算机系统的示例性架构。如图所示，设备1102包括I/O设备1108-A、处理器1110-A、和存储器1112-A。设备1104 包括I/O设备1108-B、处理器1110-B和存储器1112-B。应当理解，如在此所使用的，术语 “处理器”意在包括一个或多个处理设备，包括中央处理单元(CPU)或其它处理电路，包括但不限于一个或多个信号处理器、一个或多个集成电路等等。而且，如在此所使用的，术语 “存储器”意在包括与处理器或CPU相关联的存储器，诸如RAM、ROM、固定存储设备(例如， 硬驱动器)或可装卸的存储设备(例如，磁盘或CDR0M)。另外，如在此所使用的，术语“I/ 0设备”意在包括用于向处理单元输入数据的一个或多个输入设备(例如，键盘、鼠标)，以及用于提供与处理单元相关联的结果的一个或多个输出设备(例如，CRT显示器)。因此，在此描述的用于实施本发明的方法的软件指令或代码可以被存储在一个或多个相关联的存储设备中，例如，ROM、固定或可装卸的存储器，并且当准备好被利用时，被加载到RAM中并由CPU来执行。尽管在此已经参考附图描述了本发明的说明性实施例，但是应当明白本发明并不限于这些确切的实施例，并且在不脱离本发明的范围或精神的情况下，本领域技术人员可以做出各种其它改变和修改。
权利要求
1.一种用于在通信系统中管理在两方或更多方之间的会议的方法，所述方法包括步骤在所述通信系统的会议管理元件与设法参与所述会议的所述两方或更多方中的每一方之间实施基于身份的认证密钥交换操作，其中，在所述会议管理元件与所述两方或更多方之间交换的消息是基于所述消息的接收者的相应身份来加密的，并且进一步地，其中所述会议管理元件在所述密钥认证操作期间从每一方接收基于由该方选择的随机数所计算的随机密钥分量；从所述会议管理元件向每一方发送包括由各方所计算的随机密钥分量的集合；在所述会议管理元件处从每一方接收随机群组密钥分量，其中，所述随机群组密钥分量是由每一方经由基于以下内容的计算方法来计算的在所述密钥认证操作期间由该方所使用的随机数，以及由设法参与所述会议的所述两方或更多方中的其它方的子集所计算的随机密钥分量；以及从所述会议管理元件向每一方发送包括由各方所计算的随机群组密钥分量的集合，从而使得每一方能够计算相同的群组密钥来在通过所述会议管理元件与每个其它方进行通信时使用。
2.根据权利要求1所述的方法，其中，由每一方计算的群组密钥被表示为 Nai (Ζ』+(N-I)&+(Ν-2)Χ +1+. . . +X"，其中N表示设法参与所述会议的各方的总数，ai表示由给定方选择的随机数，Zi表示由所述给定方计算的随机密钥分量，Xi表示由所述给定方计算的随机群组密钥分量，并且i表示在N方会议中用于所述给定方的会议排序的编号，其中当i = 1时，i-1 = N，并且当i = N时，i+Ι = 1。
3.根据权利要求2所述的方法，其中，用于给定方的随机密钥分量是通过如下表示的计算方法来计算的％Ρ，其中％是由所述给定方选择的随机数，并且P是选自与基于身份加密的密钥认证操作相关联的群组的点。
4.根据权利要求2所述的方法，其中，用于给定方的随机群组密钥分量是通过如下表示的计算方法来计算的 (BitlP-Bi^1P)，其中 是由所述给定方选择的随机数，ai+1P是由在会议排序中就在所述给定方之后的一方发送到所述会议管理元件的随机密钥分量，Bi^1P是由在所述会议排序中就在所述给定方之前的一方发送到所述会议管理元件的随机密钥分量，并且P是选自与密码密钥交换协议相关联的群组的点。
5.根据权利要求1所述的方法，其中，设法参与所述会议的所述两方或更多方从一个或多个密钥管理服务获得相应的私有密钥。
6.根据权利要求1所述的方法，其中，每当以下情况之一时所述群组密钥就发生改变 新的一方被添加到所述会议中，以及参与方离开所述会议。
7.根据权利要求1所述的方法，其中，功能元件模仿设法参与所述会议的受污染方，从而使得所述功能元件能够拦截去往和来自所述受污染方的会议消息。
8.一种用于在通信系统中管理在两方或更多方之间的会议的装置，所述装置包括存储器；以及耦合到所述存储器的至少一个处理器，并且所述处理器被配置以便在所述通信系统的会议管理元件与设法参与所述会议的所述两方或更多方中的每一方之间实施基于身份的认证密钥交换操作，其中，在所述会议管理元件与所述两方或更多方之间交换的消息是基于所述消息的接收者的相应身份来加密的，并且进一步地，其中所述会议管理元件在所述密钥认证操作期间从每一方接收基于由该方选择的随机数所计算的随机密钥分量；从所述会议管理元件向每一方发送包括由各方所计算的随机密钥分量的集合； 在所述会议管理元件处从每一方接收随机群组密钥分量，其中，所述随机群组密钥分量是由每一方经由基于以下内容的计算方法来计算的在所述密钥认证操作期间由该方所使用的随机数，以及由设法参与所述会议的所述两方或更多方中的其它方的子集所计算的随机密钥分量；以及从所述会议管理元件向每一方发送包括由各方所计算的随机群组密钥分量的集合，从而使得每一方能够计算相同的群组密钥来在通过所述会议管理元件与每个其它方进行通信时使用，但是其中，所述会议管理元件无法计算所述群组密钥。
9.一种用于在参与通信系统中的各方之间的会议时使用的方法，在给定方处的所述方法包括步骤在所述通信系统的会议管理元件与所述给定方之间实施基于身份的认证密钥交换操作，其中，所述会议管理元件还与设法参与所述会议的其它方实施所述基于身份的认证密钥交换操作，其中，在所述会议管理元件与所述各方之间交换的消息是基于所述消息的接收者的相应身份来加密的，并且进一步地，其中所述会议管理元件在所述密钥认证操作期间从每一方接收基于由该方选择的随机数所计算的随机密钥分量；在所述给定方处从所述会议管理元件接收包括由各方所计算的随机密钥分量的集合；从所述给定方向所述会议管理元件发送随机群组密钥分量，其中所述会议管理元件还从所述其它方中的每一方接收随机群组密钥分量，其中，所述随机群组密钥分量是由每一方经由基于以下内容的计算方法来计算的在所述密钥认证操作期间由该方所使用的随机数，以及由设法参与所述会议的所述各方中的其它方的子集所计算的随机密钥分量；在所述给定方处从所述会议管理元件接收包括由各方所计算的随机群组密钥分量的集合；以及在所述给定方处计算与由所述其它方计算的群组密钥相同的群组密钥，用于在通过所述会议管理元件与每个其它方进行通信时使用。
10.一种用于在参与通信系统中的各方之间的会议时使用的装置，在给定方处的所述装置包括存储器；以及耦合到所述存储器的至少一个处理器，并且所述处理器被配置以便 在所述通信系统的会议管理元件与所述给定方之间实施基于身份的认证密钥交换操作，其中，所述会议管理元件还与设法参与所述会议的其它方实施所述基于身份的认证密钥交换操作，其中，在所述会议管理元件与所述各方之间交换的消息是基于所述消息的接收者的相应身份来加密的，并且进一步地，其中所述会议管理元件在所述密钥认证操作期间从每一方接收基于由该方选择的随机数所计算的随机密钥分量；在所述给定方处从所述会议管理元件接收包括由所述各方计算的随机密钥分量的集合；从所述给定方向所述会议管理元件发送随机群组密钥分量，其中，所述会议管理元件还从所述其它方中的每一方接收随机群组密钥分量，其中，所述随机群组密钥分量是由每一方经由基于以下内容的计算方法来计算的在所述密钥认证操作期间由该方所使用的随机数，以及由设法参与所述会议的所述各方中的其它方的子集所计算的随机密钥分量；以及在所述给定方处从所述会议管理元件接收包括由所述各方计算的随机群组密钥分量的集合；以及在所述给定方处计算与由所述其它方计算的群组密钥相同的群组密钥，用于在通过所述会议管理元件与每个其它方进行通信时使用。
全文摘要
本发明的原理提供了用于在诸如会议系统的通信环境中使用的一个或多个安全密钥管理协议。例如，一种用于在通信系统中管理两方或更多方之间的会议的方法包括以下步骤。在所述通信系统的会议管理元件与设法参与会议的所述两方或更多方中的每一方之间实施基于身份的认证密钥交换操作，其中，在所述会议管理元件与所述两方或更多方之间交换的消息是基于所述消息的接收者的相应身份来加密的，并且进一步地，其中所述会议管理元件在密钥认证操作期间从每一方接收基于由该方选择的随机数所计算的随机密钥分量。所述会议管理元件向每一方发送包括由各方计算的随机密钥分量的集合。所述会议管理元件从每一方接收随机群组密钥分量，其中所述随机群组密钥分量是由每一方经由基于以下内容的计算方法来计算的在密钥认证操作期间由该方所使用的随机数，以及由设法参与会议的所述两方或更多方中的其它方的子集所计算的随机密钥分量。所述会议管理元件向每一方发送包括由各方计算的随机群组密钥分量的集合，从而使得每一方能够计算相同的群组密钥来在通过所述会议管理元件与每个其它方进行通信时使用。
文档编号H04L9/08GK102484582SQ201080038198
公开日2012年5月30日 申请日期2010年8月23日 优先权日2009年8月28日
发明者G·S·桑达拉姆, V·卡库莱夫 申请人:阿尔卡特朗讯公司