多媒体通信系统中的安全密钥管理的制作方法

专利名称：多媒体通信系统中的安全密钥管理的制作方法
技术领域：
本申请涉及共同转让、同时提交的、由代理人申请案编号805922标识并且被命名为‘、ecure Key Management in Conference System”的美国专利申请，其中，该美国专利申请的公开内容通过参考引入于此。本发明一般涉及通信安全，并且特别涉及一种用于例如多媒体通信系统的媒体平面和电话会议系统的通信环境中的安全密钥管理协议。
背景技术：
多媒体通信系统中提供的现有多媒体应用不支持媒体平面中的安全性。关注媒体平面安全性是较新的问题。例如互联网协议(IP)多媒体子系统(IMS)的多媒体通信系统中的现有提案是基于某种基于令牌的对称密钥方法，其中，所述对称密钥方法使用可能创建和分发密钥的密钥管理服务器来管理。其公开内容通过参考引入于此的3GPP(第三代合作伙伴计划)技术报告(TR) 33，拟8讨论用于IMS媒体平面加密的现有提案。然而，这些现有解决方案不是可伸缩的(由于服务器应当高度可用并且一直在线)、不提供实体的认证以及另外在服务器处代管密钥。相反，例如SKYPE (卢森堡的Skype技术有限公司的商标)和其它客户端到客户端多媒体应用的非IMS应用为认证提供端到端保密性，以及没有任何密钥代管。然而，所述解决方案依赖于证书的使用，其中，证书的使用要求高度可用的公钥基础设施(PKI)，所述公钥基础设施管理起来极其昂贵。此外，所述解决方案对于小组会议应用不能很好伸缩，其在缺少PKI时也不提供对通信的合法拦截。此外，类似密钥管理安全性考虑存在于会议系统中，其中，在所述会议系统中，参与方通过会议服务器参与到呼叫会话中。由此，存在对一种安全密钥管理解决方案的的需求，所述安全密钥管理解决方案用于例如多媒体通信系统的媒体平面和电话会议系统的通信环境中。

发明内容
本发明的原理提供一个或多个安全密钥管理协议，所述安全密钥管理协议用于例如多媒体通信系统的媒体平面的通信环境中。例如，在一个方面，一种用于在第一方和第二方之间实施符合多媒体通信系统的认证密钥协定协议的方法包括在第一方处的以下步骤。从密钥服务获得用于第一方的至少一个私钥。从第一方将包括已加密第一随机密钥组件的第一消息发送到第二方，其中，已在第一方处计算出第一随机密钥组件，以及已使用第二方的公钥根据基于身份的加密运算对第一消息进行加密。在第一方处从第二方接收到包括已加密随机密钥组件对的第二消息，其中，已从
6第一随机密钥组件和在第二方处计算出的第二随机密钥组件形成所述随机密钥组件对，以及，已在第二方处使用第一方的公钥根据基于身份的加密运算对第二消息进行加密。由第一方使用由第一方从所述密钥服务获得的私钥对所述第二消息进行解密，以便获得第二随机密钥组件。从第一方将包括第二随机密钥组件的第三消息发送到第二方，其中，已使用第二方的公钥根据基于身份的加密运算对所述第三消息进行加密。所述第一方基于第二随机密钥组件计算出安全密钥，其中，使用所述安全密钥进行经由多媒体通信系统的媒体平面与第二方的至少一个呼叫会话。在第一方与第二方之间交换的一个或更多已加密消息包含关联于第一方的身份和关联于第二方的身份中的至少一个。从密钥服务获得至少一个私钥的步骤进一步可以包括交换，其中，在所述交换中， 第一方向密钥服务发送第一方标识符，以及从密钥服务接收至少一个私钥，所述至少一个私钥由所述密钥服务基于所述第一方标识符生成。所述第一方与所述密钥服务之间的所述交换可以基于以下中的至少一个来实施(i)基于时间的调度；(ii)基于呼叫会话频率的调度；以及(iii)基于订阅的调度。第一方可以从密钥服务获得两个或更多私钥，所述两个或更多私钥包括被用于与第二方的认证密钥协定的至少一个私钥。由第一方获得的两个或更多私钥中的剩余的可被用于实施单独的认证密钥协定运算。第一方可以具有两个或更多身份、以及用于两个或更多身份中的每个的单独的私钥。所述方法可以进一步包括在所述第一方处接收包括来自第二方的验证的第四消息，其中，已在第二方处使用第一方的公钥根据基于身份的加密算法对第四消息进行加密。被第一方和第二方用于实施所述基于身份的加密运算的各自的公钥可以包括对这样的信息应用哈希函数的结果，其中，所述信息指示该公钥所被指派给的各方的身份，以及其中，所述哈希函数的输出是椭圆曲线上的点。可以根据由所述第一方选择的第一随机数和从关联于给定秘密密钥协议的组中选出的值计算出第一随机密钥组件，以及，可以根据由第二方选择的第二随机数和从关联于给定秘密密钥协议的组中选出的值计算出第二随机密钥组件。可以在第一方处根据第一随机数和第二随机密钥组件计算出用于第一方与第二方之间的呼叫会话的安全密钥。在第二方处，可以根据第二随机数和第一随机密钥组件计算出相同的安全密钥。在一个实施例中，所述多媒体通信系统包括互联网协议多媒体子系统，以及，在所述第一方与所述第二方之间交换的消息中的一个或更多的格式是基于多媒体互联网密钥格式。在一个或更多进一步的实施例中，一种用于实施符合多媒体通信系统的认证密钥协定协议的方法被扩展为，提供包括分线、重定位目标(重定向)、延迟递送、合法拦截和会议管理的通信特征。应当认识到，尽管本发明的原理特别适用于互联网协议多媒体子系统，但本发明不旨在限于此。即，本发明的原理一般性地适用于在其中希望提供安全密钥管理特征的任何合适通信系统。
7
从以下对其示例性实施例的详细描述中，本发明的这些以及其它目的、特征和优点将变得显而易见，其中，所述示例性实施例应当结合附图来阅读。


图IA示出了根据本发明的一个实施例的私钥获得方法；图IB示出了根据本发明的一个实施例的基于身份的认证密钥交换方法；图2示出了根据本发明的一个实施例的密钥分线方法；图3示出了根据本发明的一个实施例的呼叫重定向方法；图4A示出了根据本发明的一个实施例的延迟递送方法；图4B示出了根据本发明的另一实施例的延迟递送方法；图5示出了根据本发明的一个实施例的合法拦截方法；图6A示出了根据本发明的一个实施例的会议管理方法；图6B示出了根据本发明的一个实施例的会议管理方法中的参与者添加；图6C示出了根据本发明的一个实施例的会议管理方法中的参与者删除；图7示出了根据本发明的基于IMS的实施例的用于安全密钥管理协议的网络体系结构；图8示出了根据本发明的基于IMS的实施例的密钥分线方法；图9示出了根据本发明的基于IMS的实施例的重定向方法；图10示出了根据本发明的基于IMS的实施例的具有三个参与者的会议方法；以及图11示出了数据网络和适于实现根据本发明的实施例的协议中的一个或更多的通信(计算)设备的一般化硬件体系结构。
具体实施例方式术语“多媒体通信系统”当用在此处时被一般性被定义为能够传输两种或更多种类型的媒体的任何通信系统，其中，所述媒体涉及但不限于基于文本的数据、基于图形的数据、基于语音的数据和基于视频的数据。术语“媒体平面”当用在此处时被一般性地定义为多媒体通信系统的这样的功能部分，其中，一个或更多类型的媒体根据所述功能部分在呼叫会话中的两方或更多方之间被交换。这与“控制平面”形成对比，其中，所述“控制平面”是多媒体通信系统的这样的功能部分，其中，根据所述功能部分实施呼叫协商/调度以建立所述呼叫会话。本发明技术可被用于的媒体平面应用的示例包括但不限于基于IP的语音(VoIP)、即时消息通信(IM)、视频/音频IM和视频共享。应当理解，媒体平面包含应用层流量。术语“密钥”当用在此处时被一般性地定义为，用于例如但不限于实体认证、保密性、消息完整性等的密码协议的输入。为便于引用，详细描述被划分如下。第I部分描述基于身份加密和基于身份认证密钥交换运算的一般原理。第II部分描述在一般通信环境上下文中的、根据本发明的示例性原理的安全密钥管理解决方案。第II部分描述在互联网协议(IP)多媒体子系统(IMS) 环境上下文中的、根据本发明的示例性原理的安全密钥管理解决方案。第IV部分描述用于实现根据本发明的一个或更多安全密钥管理协议的示例性计算系统。
I.基于身份加密(IBE)和基于身份认证密钥交换(IBAKE)在对本发明的安全密钥管理技术的示例性实施例的说明之前，提供IBE和IBAKE
的一般原理。A.基于身份加密基于身法加密(IBE)协议由Boneh和Franklin提出，参见密码学进展——CRYPTO 2001 ^ iX ^ (2001)中由 Dan Boneh、Matthew K. Franklin PJf M 的 “ Identity—Based Encryption from the Weil Pairing”(其公开内容通过参考引入于此)。该非对称密码加密协议允许参与者使用“身份”(例如电子邮件标识或域名)作为公钥，并且消除了对大规模公钥基础设施的需求，其中，所述大规模密钥基础设施通常关联于例如RSA(Rivest、 Siamir和Adleman)的公钥加密方法。Boneh和Franklin的问题解决方法使用在有限域上对椭圆曲线的双线性映射，以及依赖于双线性决策Diffie-Hellman问题。IBE涉及以下数学工具和参数假设E是跨有限域F的椭圆曲线，以及假设P是大素数阶的点。假设e :Ε χ E- — G是E上的双线性映射。典型示例如W^eil对，以及因此，G将是 η次单位根的组，其中，η是跨F的E上的点的数量。假设s为非零正整数，并且是存储于密钥生成函数(KGF)中的密码。这是系统级密码，并且不泄露到KGF之外。假设Ppub = sP是对所有参与者已知的系统的公钥。由于E是组，应当记得sP代表E中的点。假设Hl为已知的哈希函数，该哈希函数接受字符串，并且将其赋给椭圆曲线上的点，即，H1 (A) = E上的QA，其中，A通常是A的身份并且也是A的公钥。假设dA= sA为由KGF计算出并且递送到仅A的私钥。假设H2为接受G的元素并将其赋给字符串的已知哈希函数。假设m为必须被加密并且被发送到A的消息。由Boneh和Franklin描述的加密函数如下假设仏=e (Qa, Ppub)，以及假设r为随机数。加密A(m) = (rP，m XorH2 (gAr))；换句话说，m的加密输出具有两个坐标u和v，其中，u = rP以及v = m XorH2 (g/)。应当指出，“xor”是指异或逻辑函数。为对(u，ν)进行解密，A使用以下公式恢复m m = ν XorH2 (e (dA, u))。所述公式的证明以及A具有私钥dA (仅对A但不对其他参与者已知的私钥)的事实在双线性映射中是简单直接的。同样应当观察到，首先计算出dA的KGF也能对消息进行解密，这导致KGF是实际上的密钥代管服务器。B.基于身份的认证密钥交换基于身份的认证密钥交换(IBAKE)在于2009年2月17日提交的由序列号 12/372，242标识的美国专利申请中描述，该专利的公开内容通过参考引入于此。IBAKE协议允许设备相互进行认证，以及导出提供完美向前和向后保密性的密钥。在此处描述的IBAKE实施例中，该协议的基础建立涉及以上在小节A中讨论的数学结构和参数。应当记得该协议是非对称的但不需要任何PKI支持；相反该协议使用离线服务器，其中，所述离线服务器行使密钥生成功能。该协议的详细内容在下面概述假设A、B是正尝试进行认证和协定密钥的两个实体(或参与方，其中，A代表第一方的计算机系统，以及B代表第二方的计算机系统)。我们将使用A和B来代表其对应的身份，其中，所述身份根据定义还代表其公钥。假设Hl㈧=QA和Hl⑶=QB为对应于公钥的各自在椭圆曲线上的点。实际上， 可以将QA和QB也看作公钥，因为身份与通过应用Hl获得的曲线上的点之间存在一对一对应。假设χ为由A选择的随机数，以及，假设y为由B选择的随机数。A与B之间的协议交换包括以下步骤在第一个步骤中，A计算出xP ( S卩，使用E上的加法法则，将P与其自身相加χ次作为E上的点)，使用B的公钥对其进行加密，并且将其发送到B。在该步骤中，加密是指上面在小节A中描述的基于身份的加密。在第二个步骤中，当接收到所述已加密消息时，B对该消息进行解密并且获得xP。 随后，B计算出yP，使用A的公钥对{xP，yP}对进行加密，以及然后将其发送到A。在第三个步骤中，当接收到该消息时，A对该消息进行解密并获得yP。随后，A使用B的公钥对yP进行加密并将其发回B。这之后，A和B这两者都计算出xyP作为会话密钥。应当观察到，A随机选取χ以及在协议交换的第二个步骤中接收到yP。这允许A 通过将yP与其自身相加χ次来计算出xyP。相反地，B随机选取y以及在协议交换的第一个步骤中接收到xP。这允许B通过将xP与其自身相加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的真实性，因为仅在对第二个步骤中的内容进行正确解密之后，yP才可以已在第三个步骤中被发回，以及仅可能由A进行所述正确解密。最终，A和B这两者可以协定同一会话密钥。换句话说，该协议是基于IBE的相互认证的密钥协定协议。尽管以上描述为协议安全性提供推动，但安全性的密码学证明可以被容易地提供。协议的困难性依赖于椭圆曲线Diffie-Hellman问题的困难性，其中，椭圆曲线Diffie-Hellman问题的困难性受椭圆曲线选择的影响。-完美的向前和向后保密性由于χ和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 24. 2 和 TS 24. 930，其公开内容通过参考引入于此)的呼叫控制协议已被例如IETF和3GPP的各种组织标准化，并且跨固定和移动网络被各种层次地采用。同时，用于确保各种层次的安全信令的复杂机制已被引入。然而，在媒体平面中， 尽管例如传输层安全或TLS (例如见IETF RFC 2M6，其公开内容通过参考引入于此)、安全实时传输协议或SRTP (例如见IETF RFC3711，其公开内容通过参考引入于此)和安全多用途互联网邮件扩展或SMIME(例如见IETF RFC 2633，其公开内容通过参考引入于此)的协议为各种应用提供容器格式，但媒体平面中的安全性解决方案缺少用于在应用层中支持端到端安全密钥管理的一致和标准化的方法。本发明的原理主要解决该问题。特别地，本发明的原理为媒体平面提供可伸缩的应用和协议无关的安全密钥管理框架。在示例性框架中，本发明的解决方案使用上面在小节I. B中描述的基于非对称(因此是公钥)身份的认证密钥交换(IBAKE)协议。示例性实施例描述了用于支持各种特征的密钥交换机制，所述各种特征例如是两方媒体平面通信、 安全多方会议、安全电话分线、安全电话重定向和安全延迟递送应用。除提供用于安全密钥管理可伸缩框架之外，所述设计和框架的一些示例性方面包括-显著降低所需网络支持的复杂度的离线密钥管理服务器(KMS)的使用。应当记得，公钥设置中的非对称协议要求复杂、一直开启的用于包括废除的证书管理的公钥基础设施(PKI)支持。基于对称密钥的密钥管理服务器是根据定义具有持续同步和更新的“一直开启”的服务器。通过消除该“一直开启”要求，我们的框架显著降低成本和支持可伸缩性。-对在基于身份协议中固有的任何被动密钥代管的消除。应当记得，具有密钥管理服务器的对称密钥协议不能消除该问题。同样应当记得，现有的基于身份加密(上面在小
11节I. A中描述的)协议遭受密钥代管之苦；使用IBAKE (上面在小节I. B中描述的)来解决的问题。-所述协议框架固有地支持密钥交换中所涉及的实体的相互认证，其带来完美保密性。-本发明的示例性实施例重用现有网络单元体系结构，以及尽可能多地重用现有协议容器格式。作为示例，在会议应用中，示例性实施例重用会议服务器来使能进行会议， 但确保该会议服务器不获得用于通信的组密钥(如将在下面阐明的那样，除非其也是会议的一方)。-尽管本发明的原理消除了被动密码代管，但本发明的协议还提供当存在用于执法的对拦截电话的合法需求时对发现密钥的无缝支持。在基于基于身份非对称密码框架的示例性实施例中，每个参与者具有公钥和私钥。公钥是基于身份的。私钥对应于公钥，并且由密钥管理服务器或服务(KMS)发出。参与者可以离线地从KMS获得私钥。仅作为示例，参与者一个月(更一般地，为订阅的长度) 与其KMS联系一次以便获得私钥。私钥还可以根据使用频率被获得。假设KMS与参与者之间存在安全关联。密钥交换期间的消息加密和解密是基于IBE。应当指出，KMS的公共参数被假设为公开可用(例如在网站上在线)。一般地，根据本发明的示例性实施例的安全密钥管理方法包括两个主要阶段。在第一阶段，参与者(参与方)从例如KMS的密钥服务获得私钥。在第二阶段，在寻求在基于多媒体的呼叫会话中进行通信的两方或多方之间实施基于身份的认证密钥交换。在两方或多方之间交换的消息被基于消息接收者的各自身份进行加密。同样，在参与方之间交换的已加密消息包含关联于参与方的身份。图IA示出了安全密钥管理方法的第一阶段，即私钥获得。如所示的，两方的通信设备(更一般地为计算设备)102的每个都从各自的KMS 104请求和获得私有(或保密)密钥。私钥交换106被根据安全通信协议来实施。安全通信协议的示例包括但不限于互联网协议安全性 orIPkc(例如见 IETF RFC 2406、IETF RFC 2409、IETF RFC 4306 和 IETF RFC 4308，其公开内容通过参考引入于此)以及传输层安全性或TLS(例如见IETFRFC 2M6，其公开内容通过参考引入于此)。广义自举体系结构或GBA (例如见3GPP技术规范 (TS) 33. 220，其公开内容通过参考引入于此)可以被用于确定将用于每一方与KMS之间的安全通信协议的密钥。在一个示例中，可以让应用运行于连接到KMS服务器并且在应用层 (传输控制协议或TCP之上，例如见ISBN为0-201-63346-9的由W. Richard Stevens所著的 TCP/IP Illustrated 第一卷The Protocols ；ISBN 为 0-201-63354-X 的由 W. Richard Mevens 和 Gary R. Wright 所著的 TCP/IPIllustrated 第二卷The Implementation ；ISBN 为 0-201-63495-3 的由 W. Richard Stevens 所著的 TCP/IP Illustrated 第三卷TCP for Transactions, HTTP, NNTP, and the UNIX Domain Protocols，其公开内容通过参考引入于此)使用TLS的客户端设备中，客户端设备在网络层使用GBA密钥或IPkc，其中GBA密钥用作预共享密钥。应当指出，每个设备在其对KMS的请求中提供标识符，其中，KMS对所述请求响应以私有(保密)密钥。在发起方设备102-1的情况下，一个标识符被提供给KMS 104-1，以及一个私有密钥I-SK被在响应中提供给设备。在响应方设备102-R的情况下，两个单独的标识符被发送到KMS104-R，即R和R1。在响应中，KMS为响应方提供两个私钥R_SK和Rl_ SK0当然，每一方可以基于某个私钥获得调度来请求和获得更多或更少的私钥。这可以是基于时间的调度(例如一个月的周期)、基于呼叫会话频率的调度(例如，当为进行电话呼叫而需要时)以及基于订阅的调度(例如，参与方向KMS的密钥服务针对某个时间长度进行订阅，或基于订阅终止条件的发生)。还应当认识到，给定方可以具有多个公共标识符。例如，参与方B(“Bob”)可以具有两个标识符bob@work. com和bobOhome. com。对于这两个标识符，可以存在两个不同的公钥，并且因此存在两个不同的私钥。图IB示出了安全密钥管理方法的第二阶段，即认证密钥交换。在该实施例中，认证密钥交换是基于IBAKE (上面在小节I. B中描述的)。由于第一方与第二方之间的消息交换的优选格式是基于多媒体互联网密钥(MIKEY)格式，所以图IA和IB的整体安全密钥交换协议因此在此处被称为MIKEY-IBAKE协议。再次假设，左边的设备是发起方或发起者102-1，以及右边的设备是响应方或响应方102-R。认证密钥交换的步骤遵循与IBAKE协议类似的步骤。假设发起方的公钥IJ3K通过使用上面在小节I中描述的哈希函数被计算出。同样地，响应方的公钥R_PK以类似方式被计算出。应当记得，发起方和响应方的私钥分别为 I_SK*R_SK。S卩，假设 Hianitiator_ID) = I_PK 和 Hl (Responder_ID) = R_PK 为对应于公钥的各自在椭圆曲线上的点。假设a为由发起方102-1选择的随机数，以及假设b为由响应方102-R选择的随机数。102-1与102-R之间的协议交换包括以下步骤在步骤110中，发起方102-1计算出第一随机密钥组件aP (即，使用E上的加法法则将P与其自身相加a次作为E上的点)，使用响应方的公钥(R_PK)对该第一随机密钥组件进行加密，以及将其发送到响应方102-R。在该步骤中，加密是指上面在小节I. A中描述的基于身份的加密。应当指出，发起方和响应方的身份(分别为I_ID和R_ID)也被包括在步骤110中的已加密消息中。当接收到所述已加密消息时，响应方使用其私钥(在图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次来计算出apP。相反地，响应方102-R随机地选择b并在协议交换的第一个步骤中接收到aP。这允许响应方通过将aP与其自身相加 b次来计算出abP。还应当指出，a是随机的，但aP不提供任何关于a的信息。因此，aP被看作基于由发起方选择的随机密码的密钥组件。同样地，b是随机的，但bP不提供任何关于b的信息。因此，bP被看作基于仅对响应方已知的随机密码的密钥组件。现在参考图2，图2示出了 MIKEY-IBAKE协议的扩展。应当理解，由于这是上面已描述的MIKEY-IBAKE协议的扩展，为简单起见，MIKEY-IBAKE协议的并非全部特征被重复。 在该特定实施例中，图2示出了分线。分线是请求向多个位置的递送。这可以例如在响应方具有多于一个他/她可以在其上参与多媒体呼叫会话的通信(计算)设备时发生。分线的一个示例如，当参与方具有全部被配置为参与MIKEY-IBAKE协议的桌面电话、个人计算机(PC)客户端和移动电话时。一般地，分线是使来电呼叫能够同时使若干个分机响铃的多媒体会话发起协议的特征。第一个应答的电话将然后控制该呼叫。由此，如在图2中所示的，响应方具有与之关联的两个设备102-R1和102-R2。由此，如所示的，设备102-R1具有公钥RlJ3K和私钥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发送的消息使用R_PK进行加密，所以设备Rl和R2这两者都可以对该消息进行解密(因为这两者都具有R_SK)。然而，假设响应方当前关联于设备R2而非设备R1，则步骤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协议对重定位目标特征的扩展。应当理解，由于这是上面描述的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中的消息应当被重定向
14到设备R2的决定，见步骤310’。在此之前或与之结合地，假设R2在步骤308中经由功能单元发送的消息中接收到Rl的私钥。从Rl发送到R2的消息被使用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中的消息在MB处使用A的公钥进行加密。在步骤404中，功能单元 402将消息继续发送给A。A使用由A从密钥服务获得的私钥对来自MB的消息进行解密，以便获得第二随机密钥组件。A识别出在步骤404中接收到的消息来自MB(由于MB的身份被包括在该消息中)。在步骤405中，A向MB发送包括已加密随机密钥组件对的第三消息(经由步骤406 中的功能单元)，所述随机密钥组件对已根据第一随机密钥组件(χΡ)和第二随机密钥组件 (yP)来形成，以及在A处使用MB的公钥进行加密。该第三消息还包括在A处被计算出并且在A处使用B的公钥进行加密的已加密随机秘密密钥(sK)。MB经由步骤407和408向 A确认接收。MB不能对消息的后面部分进行解密(由于其被使用B的公钥进行加密，以及 MB不具有B的私钥)，并且由此不能得知sK。当B进行请求时，在B与MB之间的相互认证操作后，MB将已加密随机秘密密钥 (sK)提供给B。这在步骤409和410中示出。该秘密密钥然后被B用于获得由A在B的邮箱里留下的内容(例如语音消息)。在图4B中示出的图4A的延迟递送的变型中，假设在第一消息中，认证密钥协定协议未被实施，而是A发送被在A处计算出并且被在A处使用B的公钥进行加密的已加密随机秘密密钥(sK)(步骤411)。已确定B不可用的功能单元402将第一消息转发给MB (步骤 412)，MB对其进行确认(步骤413和414)。稍后，B可以通过与如上所描述相同的方式从 MB取回秘密密钥(步骤415和416)。图5示出了 MIKEY-IBAKE协议的又另一个扩展。再次地，应当理解，由于这是上面描述的MIKEY-IBAKE协议的扩展，所以为简单起见，MIKEY-IBAKE协议的并非所有特征被重复。图5中的扩展涉及对在多媒体通信系统中交换的消息的合法拦截的概念。合法拦截的概念是基于当执法机构需要能够对一方或更多方的通信进行“监听”时的情形。
在一种方法中，执法机构可以简单地通过搜查证获得102-1和102-R的私钥，以及在密钥协定协议期间扮演主动式“中间人”，以及然后搭线到流量中。在图5中所示的另一种方法中，执法服务器(Li服务器)502与发起方的 KMS(KMSI)和响应方的KMS(KMSR)进行活动，以便合法拦截被在设备102-1与102-R之间发送的消息。尽管图5为LI服务器、KMSI和KMSR示出了单独的服务器，但应当认识到，多媒体通信系统中的一个功能单元(例如拦截服务器)可以被用于实施KMS和拦截功能。相应地，如以上在图IA和IB的上下文中描述的MIKEY-IBAKE协议的被实施。然而，LI服务器对于被发送到响应方的消息模仿发起方，以及对于被发送到发起方的消息模仿响应方。例如，考虑当LI服务器模仿响应方时的消息流。假设102-1发送旨在被102-R 接收的包括已加密第一随机密钥组件的第一消息。第一消息被LI服务器拦截。LI服务器然后计算出第二随机密钥组件并将包括已加密随机密钥组件对的第二消息发送给102-1。 随机密钥组件对根据第一随机密钥组件和在LI服务器处计算出的第二随机密钥组件来形成。第二消息在LI服务器处使用102-1的公钥进行加密。第二消息使用由102-1从密钥服务获得的私钥进行解密，以便获得第二随机密钥组件。设备102-1然后发送旨在被102-R接收的包括第二随机密钥组件的第三消息，其中该消息被LI服务器拦截。由此，LI服务器能够计算出与设备102-1计算出的相同的安全密钥。应当理解，LI服务器还在认证密钥协定操作期间发送和接收消息时模拟发起方 (102-1)，从而响应方(102-R)建立与LI服务器的安全密钥，其中，响应方相信该安全密钥是由发起方协定的(但实际上是与LI服务器协定的)。应当认识到，上面描述的MIKEY-IBAKE协议特征中的一个或更多可以被扩展到会议系统场景。所述扩展在图6A至6C中示出。一般假设对多方通信进行中继(例如会议桥接器)的会议服务器(更一般地说是会议管理单元)不知道组密钥，而所有用户能访问相同的组密钥。该假设存在例外，即在端到端会议中，当充当会议桥接器的计算设备也是实质上参与会议的一方时。如图6A中所示，假设多方会议600包括会议服务器和用户(参与方)1至N，其中， 用户号码按照用户寻求加入会议的顺序来指派，即顺序地1、2、3. . . N。在步骤602中，每个用户单独执行与会议服务器的IBAKE协议。假设& = ^P为由用户“I”在与服务器进行认证期间发送到会议服务器的值。应当记得，aip是由参与方根据IBAKE计算出的随机密钥组件。在认证成功之后，在步骤604中，会议服务器将集合IaiPl发送给每个用户(或者组播或者单独地单播)。集合{^Ρ}由此是包括由参与方的每个计算出的随机密钥组件的集合。
在步骤606中，每个用户单独向会议服务器发回Xi = AlawP-^1PL应当指出， % IawP-^V1Pl是随机组密钥组件，其中，所述随机组密钥组件由每个参与方经由这样的计算而计算出，所述计算是基于由该参与方在密钥认证运算期间使用的随机数和由寻求参与会议的两个或更多参与方中剩余的那些的子集计算出的随机密钥组件。在该实施例中，用于给定参与方的随机组密钥组件MawP-^1Pl被计算为使得是由该给定参与方选择的随机数，ai+1P是由会议排序中紧随该给定参与方之后的参与方发送给服务器的随机密钥组件，Bi^1是由会议排序中仅接在该给定参与方之前的参与方发送的随机密钥组件，以及P是从关联于基于身份加密密钥认证运算的组中选出点(例如，如上面描述的，从椭圆曲线中选出的点)。在步骤608中，会议服务器然后与每个人共享集合{XJ (或者组播或者单独地单播)。即，集合{XJ是包括由参与方计算出的随机组密钥组件的集合。在步骤610中，每个参与方可以计算出用于通过会议服务器与每个其它参与方相互进行通信的相同组密钥。组密钥被计算如下=Nai (Ζ』+(N-I)&+(Ν-2)Χ +1+. . . . +X^，，其中，N代表寻求参与会议的参与方的数量，a,代表由给定参与方选择的随机数，Zi代表由给定参与方计算出的随机密钥组件，&代表有给定参与方计算出的随机组密钥组件，以及i代表N方会议中给定参与方的会议排序号码，其中，当i = 1时i-1 = N，以及当i = N时i+1 =1。如上面提到的，会议服务器不是会议中的参与方，以及由此不能计算出组密钥。然而，在端到端场景中，会议服务器是会议呼叫中的参与方，以及由此需要能够计算出组密钥。应当理解，会议服务器实施与每个寻求参与会议的参与方的相互认证运算。会议服务器还仅当至少两个条件被满足时准许给定参与方加入会议(i)给定参与方由会议管理单元进行了认证；以及(ii)给定参与方被确认为属于会议授权列表。还有，根据上面的MIKEY-IBAKE协议，寻求参与会议的参与方和会议服务器从一个或更多密钥管理服务 (KMS)获得各自的私钥。图6B示出了新的会议参与者(用户N+1)如何被添加到正在进行的会议中，由此导致被修改了的会议600’。在步骤612中，用户N+1执行与会议服务器的IBAKE。假设= aN+1P是由用户 “N+1”在与服务器进行认证期间发送到服务器的值。在用户N+1的认证成功之后，在步骤 614中，会议服务器宣布新用户N+1的准入，以及向每个人发送包括ZN+1的集合IaiPl (或者组播或者单独地单播)。在步骤616中，用户1、N、N+1向服务器发回Xi = Bi (BitlP-Bi^1Pj ；可替换地，其全部都可以执行该步骤。在步骤618中，会议服务器然后与每个人共享包括Xm的集合{XJ (或者组播或者单独地单播)。组密钥(N+1) a, (Zh) + (N) Xi+ (N-I) Xi+1+. . . . +Xi_2然后在步骤 620中被计算出。观察到，在新用户被准入后，组密钥改变。图6C示出了会议参与者如何退出正在进行的会议，由此导致被修改了的会议 600。假设用户3退出呼叫(应当理解，选择用户3仅是作为示例)。在步骤622中，会议服务器宣布哪个用户退出了呼叫(或者组播或者单独地单播)。在步骤624中，用户排序改变。用户1和2保持不变。对于所有i大于或等于4的用户，用户i变成用户i-1。 在步骤626中，用户4 (其现在是用户；3)重新计算&，并与会议服务器共享该贡献。在步骤628中，会议与所有参与者共享集合{XJ。在步骤630中，参与者重新计算组密钥(N-I) Bi (2^) + (^2)^+(^3)^+. . . . +&_2。再次观察到，在参与者退出呼叫之后，组密钥改变。本发明的原理还提供对上面描述的会议管理技术的扩展。该扩展涉及对会议消息的合法拦截。假设会议系统中存在N个参与者。假设参与者N是“有污点的”，以及执法机构已获得了搭线到去往和来自参与者N的会话中的搜查令。选择将参与者N声明为有污点的仅是作为示例和使描述更易于理解，以及，该解决方案绝不限于将第N个用户声明为有污点的用户。在会议呼叫之前，LI服务器(回顾图5中的)联系对应于参与者N的KMS，并且获得参与者N的私钥。这将允许LI服务器在组密钥交换过程中假装是参与者N，以及执行图 6A中的所有步骤，只是参与者N的贡献被用来自LI服务器的贡献代替。特别地，LI服务器将用、和)^来取代4和\。剩余参与者将不知道该不同，并且将计算出组密钥，称其为 GK，。接下来，LI服务器与会议服务器一起运转，并且在所有与参与者N的通信中用
和I代替乙和&。这将意味着参与者N将计算出不同于GK’的组密钥。称该新密钥为 GK ”。应当指出，在上面的步骤中，LI服务器可以以对于任何参与者用、和)^代替了 Zi和\’以及选择i = 1仅是作为示例。在呼叫被建立起来之后，来自参与者1至N-I的任何通信将使用GK’进行加密。由于LI服务器知道GK’，所以其可以然后拦截通信、对其进行解密，这随后其将用GK”对其重新进行加密并将其发送给参与者N。相反地，来自参与者N的任何通信将使用GK”进行加密，其将被LI服务器拦截，然后使用GK”进行解密，使用GK’重新进行加密以及发送给参与者1至N-1。III. IMS 实施例在下面的小节中，WiMIKEY-IBAKE的一般原理及其扩展被应用于IP多媒体子系统(IMS)环境。即，该小节中的多媒体通信系统被认为是IMS网络。IMS标准例如在3GPP 技术规范 TS 23. 218、TS 23. 228、TS24. 228、TS 24. 229 和 TS 24. 930 中被描述，其公开内容通过参考引入于此。我们首先描述特别是密钥管理的IMS媒体平面安全性的体系结构框架，基于其可以导出各种特征和用例。位于所述解决方案核心的是基于身份加密(IBE)概念，该概念类似于公开内容通过参考引入于此的RFC 5091, RFC 5408和RFC 5409。然而，这些RFC不提供认证，并且遭受固有的密钥代管问题之苦。我们通过将基础 IBE扩展为包括基于身份的认证密钥交换(IBAKE)协议来解决这些问题，其中，基于身份的认证密钥交换(IBAKE)协议提供相互认证、消除被动的密钥代管以及提供完美的密钥保密性。尽管IBAKE是基础协议构成，但我们使用MIKEY作为用于密钥递送的协议容器。关于本发明的IMS解决方案框架的关键观点在于，我们重新使用已提出的包括 KMS的体系结构，但特别地，我们不要求这些KMS服务器一直在线。换句话说，在所提出的框架中，KMS是周期性地(例如每个月一次)与终端用户客户端进行通信以创建安全的基于身份加密框架的离线服务器，而终端用户客户端之间的在线事务(对于媒体平面安全性)是基于允许参与的客户端在非对称的基于身份加密框架中交换密钥组件的IBAKE框架。除消除被动的代管之外，该框架还允许终端用户客户端相互与彼此进行认证(在IMS媒体平面
18层)，并且提供完美的向前和向后保密性。观察到，KMS到客户端的交换被少量地使用(例如一个月一次)——因此KMS不再被要求是高可用服务器，以及特别地，不同KMS不必与彼此进行通信(跨运营商边界)。此夕卜，假设使用非对称的基于身份加密框架，则消除了对昂贵的公钥基础设施O3KI)和证书管理和废除的所有运营成本的需求。另外，安全地支持各种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 RFC 4306，其公开内容通过参考引入于此)的其它类型的凭证可以被用于用户与KMS之间的该相互认证。在该事务期间，UE出示其订阅凭证，这之后，KMS生成私钥的集合(被用于IBAKE 中)。如果该事务被一个月实施一次，则KMS可以选择为每天生成一个密钥。密钥的数量和该交换的频率是策略问题，并且其可以被与订阅联系在一起。该灵活性对预付费客户特别有用。 应当指出，取代单一 KMS，可以涉及两个不同的KMS —个用于用户A，即KMS_A，以及一个用于用户B，即KMS_B。然而，KMS_A和KMS_B不必与彼此进行通信。该场景特别适用于运营商间场景。我们现在给出在IMS上下文中MIKEY-IBAKE中涉及的交换的简短概要。假设A、B是正尝试进行认证和协定密钥的两个用户。同时，A和B代表其对应的身份，该身份根据定义也代表其公钥。假设H1 (A) =(^和H1(B) = ( 为对应于公钥的各自在椭圆曲线上的点。实际上，可以将A和( 也看作公钥，因为身份与通过应用H1获得的曲线上的点之间存在一对一对应。假设χ是由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的一个或多个媒体秘密密钥，并将其发送给A。4.用户A的IMS UE计算出xP( S卩，使用E上的加法法则，将P与其自身相加χ次作为E上的点)，使用B的公钥对其进行加密，以及将其发送到用户B的IMS UE。5. IMS核心检测到邀请，并且以使得网络功能如果被授权则可以访问会话密钥的方式处理其。特别地，该步骤适用于仅支持对于满足任何合法拦截需求所需的主动代管特征。6.用户B的IMS UE接收到包括已加密的xP的INVITE。用户B的IMS UE对该消息进行解密并获得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接受INVITE和媒体安全的使用。观察到，A随机地选择X，以及在协议交换的第二个步骤中接收到yP。这允许A通过将yP与其自身相加χ次来计算出xyP。相反地，B随机地选择y，以及在协议交换的第一个步骤中接收到xP。这允许B通过将xP与其自身相加y次来计算出xyP。源自MIKEY-IBAKE协议的一些优势属性如下相互认证。可以观察到，步骤4和7中的净荷的内容使用B的公钥进行加密。因此，B且仅有B可以对这些消息进行解密。类似地，步骤6中的消息的内容可以由A且仅可以由A进行解密。还应当指出，步骤6和7允许B和A对彼此进行认证(通过证明消息被正确地进行解密)。该新颖特征允许A和B在没有任何在线服务器或证书机构的帮助情况下对彼此进行相互认证。完美保密性。观察到，χ和y是随机的。因此，会话密钥xyP是新的，并且不具有与过去或未来事务的任何相关性。消除被动代管。可以观察到，尽管KMS(或一对KMS)可以对交换中的消息进行解密，但在给定χΡ和yP的情况下难以确定xyP。该困难性假设依赖于椭圆曲线上的 Diffie-Hellman问题。还应当指出，用于IBE的曲线是特定于KMS的，并且此外不需要与用于生成会话密钥的曲线相同。该灵活性提供了大量选择，以及还消除了 KMS之间所需的任何协调。身份管理。如以上所描述的，为对消息进行加密，发送者使用接收者的公钥，该公钥使用接收者的身份(或多个身份中的一个)而生成。接收者的身份可以采用指定特定用户、一组用户或任何用户的格式。用户和用户组的命名可以遵循正常IMS惯例，以及可以通过使用通配符来扩展。在涉及组应用的特定场景中，具有这样的策略可以是自然而然的，该策略允许组中的所有接收者使用对应于该特定用户组的身份的秘密密钥。例如，对于企业用户，缺省地使对应于企业的身份的秘密密钥被分发给所有企业用户可以是自然而然的。 应当指出，由于基于身份加密的属性，尽管属于组的所有用户可能拥有该组的秘密密钥，但所有用户仍然不能获得在发送者与属于该同一组的某个其他用户之间建立的会话密钥。为确保该策略被执行，公开用户身份可以被安全地绑定到IMS UE也是有必要的。换句话说， 被用户用于向KMS进行认证的身份是一个公开身份(集合)，这是重要的。我们现在讨论用于各种基于IMS的用例场景的MIKEY-IBAKE协议的扩展。A.通过主动代管的合法拦截(Li)为能够提供被拦截通信的清晰副本，一下条件必须被满足1.必须有可能拦截流量(信令和媒体这两者的)。2.被用于实际流量保护的会话密钥必须可用。为使会话密钥可用，需要KMS功能服务。如上面说明的，被用于流量保护的实际会话密钥在发送者与接收者之间生成，由此不被KMS知道。因此，需要主动代管解决方案。在该场景中，对于要获得用户A与B之间的会话密钥的KMS，其需要建立其自己与用户A之间的主动会话密钥以及其自己与用户B之间的另一同时的主动会话。KMS对A假装是B，以及反之亦然。由KMS扮演的该“中间人”角色称为主动代管，并且类似于用于PKI环境中的方法，其中，在所述用于PKI环境中的方法中，证书机构生成‘伪造证书’并且在交换中间进行代理。用于常规CA中的技术与我们的主动代管方法之间的差别在于，KMS不必生成伪造密钥。通过使用被选路经由家乡网络的信令流量，在家乡网络中对信令流量的拦截可以在SIP(会话发起协议)服务器处完成。该信令流量然后需要被选路到合适的KMS以便该 KMS建立所需的与对应用户的会话密钥。在漫游情况下，由于SIP信令流量通常是在IMS UE与P-CSCF之间受保密性保护的，并且考虑到在当前部署中P-CSCF位于家乡网络中，所以 SIP信令仅在被访问网络中的承载层以已加密格式可用。对于漫游场景，尽管已加密SIP信令和内容将总是可用，为拦截SIP信令和对通信内容进行解密，被访问网络与处理KMS的实体之间必须存在互操作协定。典型地，KMS将驻留于家乡网络中，所以对于由被访问网络实施的Li，需要与家乡网络的协作。按照LI标准，当在加密中不涉及VPLMN(被访问公共陆地移动网络)时，仅已加密内容将对于VPLMN中的LI可用。B.不同KMS域中的用户不同KMS域中的用户将具有由不同KMS生成的其秘密密钥。于是，不同的公共参数(例如密码原料)集合可以被用于为不同KMS域中的生成公开和秘密密钥。为确保正确的加密/解密，发送者和接收者需要知道被每一边使用的精确公开参数。然而，如果一个 KMS域中的用户需要建立到另一 KMS域中的用户的安全呼叫，其中所涉及的KMS不需要协作。如在任何基于身份的密码协议或者其实任何公钥协议中那样，我们可以安全地假设，交换所需的公开参数是公开可用的或被公开地进行交换。C.端到中间场景在端到中间场景中，IMS UE与网络实体之间存在媒体保护。在其中呼叫被从IMS UE发起的场景中，呼叫的建立将遵循与端到端受保护呼叫相同的原理。发起方IMS UE如以上描述的那样使用网络实体(例如MGWC——媒体网关控制)的身份对xP进行加密并将其与INVITE —起进行发送。MGWC拦截该消息，并且以与接收方IMS UE将使用的相同的方式生成yP。MGWC然后建立MGW以便具有去往IMS UE的媒体安全性。媒体流量将在PSTN (公共电话交换网络)中被完全进行转发。对于IMS UE的来电呼叫，MGWC检查至少一个已注册为预期接收者的终端已注册了媒体安全功能和优先选择。如果不存在任何具有媒体保护功能的终端，则呼叫被完全进行转发。否则，MGWC选择y并且生成yP。MGWC然后将已加密的yP(使用IMS UE身份)插入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能够对已使用B的公开身份进行加密的从用户A接收到的消息进行解密，因此能够获得xP。然而，其不能对从B2发送的消息进行解密，因为该消息已使用A 的身份进行加密。由此，用户Bl不能获得yP。还应当指出，即使Bl能够获得yP，其将仍然不能计算出xyP。应当指出，在图7中，(M)_X表示消息M使用X的身份进行加密。E.重定向在本小节中，针对基于IMS的MIKEY-IBAKE的情况讨论会话重定向(重新定位目标)。应当记得，上面在图3的上下文中一般地描述了重定向。会话重定向是这样的场景， 在该场景中，功能单元决定将呼叫重定向到不同的目的地。会话重定向使能够进行典型服务“无条件会话转接”、“忙线会话转接”、“可变会话转接”、“选择性会话转接”和“无应答会话转接”。存在两种基本的会话重定向场景。在场景一中，功能单元(例如S-CSCF)决定使用SIP REDIRECT方法对会话进行重定向。换句话说，功能单元将新的目的地信息传送给发起方。于是，发起方发起与所重定向目的地的新会话，其中，所重定向目的地由功能单元提供。对于MIKEY-IBAKE的情况，这意味着发起方将发起与所重定向目的地的身份的新会话。在第二种场景中，功能单元决定在不通知发起方的情况下对会话进行重定向。通常的场景是这样的，在其中，目的地用户的S-CSCF确定会话将被进行重定向。由“Cx-pull” 在注册期间从HSS(家乡订阅服务器)获得的用户概要信息可以包含导致会话重定向的复杂逻辑和触发器。
在图9的步骤1至8中所示的示例中，在不失一般性的情况下，假设用户B建立到 C的会话转接。在此情况下，用户B在其用户概要中包括使用C的身份进行加密的其秘密密钥。因此，一旦S-CSCF从用户A接收到消息，并且决定该消息需要被进行重定向，则其将B 的已加密密钥包括在被重定向到C的消息中。当接收到该消息时，用户C对秘密密钥以及接着对来自A的消息进行解密。用户C然后选择随机的y并向A发送被使用A的公开身份进行加密的包括yP和其身份C的消息。当接收到该消息时，用户A对其进行解密，认识到其正在与用户C进行通信，并且发送被使用C的公开身份进行加密的包括所接收的yP的响应确认消息。在图9中，(M)_X表示消息M被使用X的身份进行加密。F.延迟递送在本小节中，针对基于IMS的MIKEY-IBAKE的情况讨论延迟递送。回顾在第II小节中，延迟递送是使得会话内容可以不在其被发送的时间被递送到目的地的这样一种服务 (例如，目的地用户当前不在线，或者决定不应答呼叫)。然而，发送者期望网络在接收者变得可用时尽快递送消息。延迟服务的典型示例如语音邮件。下面，呈现了针对基于IMS的MIKEY-IBAKE的情况的两个延迟递送的基本场景。对于第一个场景可以回头参考图4A,以及对于第二个场景参考图4B。在第一个场景中，用户A和B的邮箱在其对密钥达成协定之前实施相互认证，其中，所述密钥将被用于对旨在延迟递送的消息的内容进行解密，而在第二个场景中，相互认证不被实施。在第一个场景中(再次地，可以回头参考其中功能单元402为IMS服务器的图 4A)，假设用户A正尝试与当前不可用的用户B取得联系，因此呼叫被转发到B的‘语音邮件’(更一般地是延迟递送服务器)。按照MIKEY-IBAKE协议，由B的邮箱接收的消息被使用B的身份进行加密，因此B的邮箱将不能对其进行解密。B的邮箱选择随机的y并计算出yP，以及将已进行IBE加密的其身份和yP发送给用户A。用户A认识到，B未接收消息， 以及实际接收者由于缺少其身份和xP而不能对在第一个步骤中发送的消息进行解密。因此，用户发送全都被使用B的邮箱身份进行IBE加密的包含A的身份、B的邮箱身份、xP和 yP的新消息。当接收到该消息时，B的邮箱接受将“sK”作为用于旨在给B的消息的会话密钥，并且将A的身份和xP返回给用户A以完成认证。观察到，sK被使用B的公钥进行加密；因此邮箱B不能对该消息进行解密并获得 “sK”。随后，当B在线并且检查谓音邮件’(对延迟递送服务器进行检查)时，B可以从邮箱服务器获得已进行加密的sK的值。应当指出，B可以必须与邮箱进行认证来获得密钥—— 这可以基于已适当存在的现有认证机制。在第二种场景中(再次地，可以回头参考其中功能单元402为頂S服务器的图 4B)，保持同样的假设——用户A正尝试与当前不可用的用户B取得联系，因此呼叫被转发至IJ 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，则消息M被使用X的身份进行加密)。在图10中，这被表示成(M)_ X，(M)_X意思是消息M被使用X的身份进行IBE加密。在与会议服务器的第一个交换集合中，用户~為和^分别选择随机的％、％和％， 以及每个用户Ai向会议服务器发送Wi = BiP0在第二个交换集合中，会议服务器向每个用户全都发送 Ρ’，而每个用户发送Zi = AOv1P-^v1Ph在最后的交换中，会议服务器向每个用户全都发送Zi’s。此时，所有会议参与者能够如下计算出组密钥=Ki = ^+2ζΛζι+ιο注意，K1 = K2 = K30还应当指出，尽管用户ApA2和A3能够生成组密钥，但会议服务器不能，因为尽管其知道多个Zi’和&，但仅各个用户知道其随机选择的a。为简单起见，以上讨论聚焦于三个会议呼叫参与者。然而，以上过程可以被一般化为η个参与者。在η个参与者的情况下，组密钥被生成为Ki = Imi W1^1+(Xi-Dz1+^)
+Zi_2，其中，Wi和Zi被作如上定义。该协议的重要特征中的一个在于，每当新用户被准入或现有用户退出呼叫时，组密钥改变。这确保新用户不获得其被添加到呼叫之前的组密钥，以及过早离开呼叫的用户不获得对呼叫之后会谈的访问。观察到，当新用户被添加且系统中已存在N个用户时，则系统中将存在总共N+1个用户。当这些用户被放置成圆形时，则第N个用户的下一个用户现在是第(N+1)个用户(并且不为第1个用户，为第1个用户是在准许第N+1个用户进入之前的情况)。准许新用户进入的协议按如下这样运转新用户与每个用户类似地使用IBAKE与会议服务器进行认证。这允许该用户被准许进入(以及被授权到呼叫)，以及该新用户被保证了加入正确的会议(经由会议服务器的认证)。假设zN+1 = aN+1为由新用户在认证期间选择的值。会议服务器然后或者组播或者单播地将针对全部i = 1到N的集合IzJ发送给所有用户。这允许所有用户获悉新用户，并且确定其新邻居。观察到，仅对于用户1、N和N+1， 邻居列表改变。用户1、N和N+1然后计算出其对应值w，并将其发回会议服务器(单独地)。服务器然后向所有用户发送已更新的IwJ列表。所有参与者然后使用与上面相同的关系式重新计算出组密钥，除去N被N+1代替以及新的Zi和Wi值。当用户退出会议呼叫时，则没有任何新的认证过程必须被执行，但组密钥改变。该过程按如下这样运转会议服务器获悉用户退出会议呼叫。随后，会议服务器将该事件以及关于已退出会话的那个用户的信息(不仅是身
24份，而还包括顺序)通知到每个人。为简单起见，会议服务器可以重新发送新的列表{Zi}。这允许所有用户重新发现其邻居，以及如果必要则重新计算Wi。所有那些仍然在会话里的参与者中，对于那些其Wi已改变的，将把其新值通知给会议服务器。会议服务器然后发送已更新的列表{Wi}。所有参与者然后使用与上面相同的关系式重新计算出组密钥，除去N被N-I代替， 以及新的Wi值被使用。IV.示例性计算系统图11示出了网络环境和采用计算设备形式的通信设备的一般化硬件体系结构 1100，其中，所述计算设备适于实现根据本发明的两个实体之间的安全密钥管理协议。尽管图11示出了仅两个实体，但应当理解，其它实体可以具有相同的配置。由此，按照上面描述的安全密钥管理协议，两个实体可以是发起方102-1(第一方或A)和响应方102-R(第二方或B)。然而，KMS、会议服务器、LI服务器、功能单元、另外的客户端设备(参与方)以及另外的服务器可以使用与图11的计算设备中所示的相同的体系结构来实现。由此，为简单起见，并非所有可以参与本发明的协议的计算设备(通信设备)被在图11中示出。如所示的，被指定为1102的A的计算设备和被指定为1104的B的计算设备经由网络1106耦合。网络可以是任何这样的网络，其中，设备能够跨越所述网络例如像在上面所述的实施例中一样地进行通信，网络1106可以包括由网络运营商(例如VerizoruAT&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/O设备”当被用在此处时旨在包括用于将数据输入处理单元的一个或更多输入设备(例如键盘、鼠标)以及用于提供关联于处理单元的结果的一个或更多输出设备(例如CRT显示器)。
相应地，用于实施此处描述的本发明的方法的软件指令或代码可以被存储在例如 ROM、固定或可移除存储器的关联存储设备中的一个或更多中，并且在即将被使用时被加载到RAM中以及被CPU执行。尽管此处已参考附图描述了本发明的示例性实施例，但应当理解，本发明不限于那些具体实施例，以及，在不脱离本发明的范围和精神的情况下，可以由本领域的技术人员作出各种其它改变和修改。
权利要求
1.一种用于在第一方与第二方之间实施符合多媒体通信系统的认证密钥协定协议的方法，所述方法在所述第一方处包括以下步骤从密钥服务获得用于所述第一方的至少一个私钥；从所述第一方向所述第二方发送包括已加密第一随机密钥组件的第一消息，所述第一随机密钥组件已在所述第一方处被计算出，以及，所述第一消息已被使用所述第二方的公钥根据基于身份的加密运算进行加密；在所述第一方处从所述第二方接收包括已加密随机密钥组件对的第二消息，所述随机密钥组件对已由所述第一随机密钥组件和在所述第二方处计算出的第二随机密钥组件而构成，以及所述第二消息已在所述第二方处被使用所述第一方的公钥根据所述基于身份的加密运算进行加密；使用由所述第一方从所述密钥服务获得的所述私钥对所述第二消息进行解密，以便获得所述第二随机密钥组件；从所述第一方向所述第二方发送包括所述第二随机密钥组件的第三消息，所述第三消息已使用所述第二方的公钥根据所述基于身份的加密运算进行加密；以及在所述第一方处基于所述第二随机密钥组件计算安全密钥，所述安全密钥被用于进行经由所述多媒体通信系统的媒体平面与所述第二方的至少一个呼叫会话。
2.如权利要求1所述的方法，其中，在所述第一方与所述第二方之间被交换的一个或更多已加密消息包含关联于所述第一方的身份和关联于所述第二方的身份中的至少一个。
3.如权利要求1所述的方法，其进一步包括，在所述第一方处从所述第二方接收包括验证的第四消息，所述第四消息已在所述第二方处使用所述第一方的公钥根据所述基于身份的加密运算进行加密。
4.如权利要求1所述的方法，其中，所述从所述密钥服务获得所述至少一个私钥的步骤包括交换，在所述交换中，所述第一方向所述密钥服务发送第一方标识符，以及从所述密钥服务接收由所述密钥服务基于所述第一方标识符生成的所述至少一个私钥，进一步地， 其中被所述第一方和所述第二方用于实施所述基于身份的加密运算的各个公钥包括对这样的信息应用哈希函数的结果，所述信息指示所述公钥所被指派给的各方的身份，以及其中，所述哈希函数的输出是椭圆曲线上的点。
5.如权利要求1所述的方法，其中，所述第一随机密钥组件根据由所述第一方选择的第一随机数和从关联于给定秘密密钥协议的组中选出的值而计算出，以及，所述第二随机密钥组件根据由所述第二方选择的第二随机数和从关联于所述给定秘密密钥协议的组中选出的值而计算出，以及其中，用于所述第一方与所述第二方之间的所述呼叫会话的所述安全密钥被在所述第一方出根据所述第一随机数和所述第二随机密钥组件而计算出。
6.一种用于在第一方与第二方之间实施符合多媒体通信系统的认证密钥协定协议的方法，所述方法包括以下步骤从密钥服务获得用于所述第一方的至少一个私钥，其中，所述第二方具有多个与之关联的计算设备，从而存在所述第二方的第一计算设备和所述第二方的至少一个第二计算设备；从所述第一方向所述第二方发送包括已加密第一随机密钥组件的第一消息，所述第一随机密钥组件已在所述第一方处被计算出，以及，所述第一消息已使用所述第二方的公钥根据基于身份的加密运算进行加密；在所述第一方处从所述第二方的所述第一和第二计算设备中的一个接收包括已加密随机密钥组件对的第二消息，所述随机密钥组件对由所述第一随机密钥组件和在所述第二方的所述第一和第二计算设备中的所述一个处计算出的第二随机密钥组件而构成，所述第二消息已在所述第二方的所述第一和第二计算设备中的所述一个处使用所述第一方的公钥根据所述基于身份的加密运算进行加密，从而所述第一和第二计算设备中的另一个不能对所述第二消息进行解密；使用由所述第一方从所述密钥服务获得的所述私钥对所述第二消息进行解密，以便获得所述第二随机密钥组件；识别所述第二消息是来自所述第二方的所述第一和第二计算设备中的所述一个； 从所述第一方向所述第二方的所述第一和第二计算设备中的一个发送包含所述第二随机密钥组件的第三消息，所述第三消息使用所述第二方的所述第一和第二计算设备中生成所述第二消息的那个的公钥根据所述基于身份的加密运算进行加密；以及在所述第一方处基于所述第二随机密钥组件计算出安全密钥，所述安全密钥被用于进行经由所述多媒体通信系统的媒体平面与所述第二方的所述第一和第二计算设备中的所述一个的至少一个呼叫会话。
7.一种用于在第一方与另一方之间实施符合多媒体通信系统的认证密钥协定协议的方法，所述方法包括以下步骤从密钥服务获得用于所述第一方的至少一个私钥；从所述第一方向第二方发送包括已加密第一随机密钥组件的第一消息，所述第一随机密钥组件已在所述第一方处被计算出，以及，所述第一消息已使用所述第二方的公钥根据基于身份的加密运算进行加密，其中，所述多媒体通信系统中已确定所述第一消息被重定向到第三方、并且已接收到已使用所述第三方的公钥根据所述基于身份的加密运算进行加密的所述第二方的私钥的功能单元将所述第一消息与之前接收到的所述第二方的私钥一起重定向到所述第三方；在所述第一方处从所述第三方接收包括已加密随机密钥组件对的第二消息，所述随机密钥组件对由所述第一随机密钥组件和在所述第三方处计算出的第二随机密钥组件而构成，以及，所述第二消息已在所述第三方处使用所述第一方的公钥根据所述基于身份的加密运算进行加密；使用由所述第一方从所述密钥服务获得的所述私钥对所述第二消息进行解密，以便获得所述第二随机密钥组件；从所述第一方向所述第三方发送包括所述第二随机密钥组件的第三消息，所述第三消息已使用所述第三方的公钥根据所述基于身份的加密运算进行加密；以及在所述第一方处基于所述第二随机密钥组件计算出安全密钥，所述安全密钥被用于进行经由所述多媒体通信系统的媒体平面与所述第三方的至少一个呼叫会话。
8.一种用于在第一方与另一方之间实施符合多媒体通信系统的认证密钥协定协议的方法，所述方法包括以下步骤从密钥服务获得用于所述第一方的至少一个私钥；从所述第一方向第二方发送包括已加密第一随机密钥组件的第一消息，所述第一随机密钥组件已在所述第一方处被计算出，以及，所述第一消息已使用所述第二方的公钥根据基于身份的加密运算进行加密，其中，所述多媒体通信系统中已确定所述第二方不可用的功能单元将所述第一消息转发到关联于所述第二方的临时目的地；在所述第一方处从关联于所述第二方的所述临时目的地接收包含已加密第二随机密钥组件的第二消息，所述第二随机密钥组件被在所述临时目的地处计算出，以及，所述第二消息已在所述临时目的地处使用所述第一方的公钥根据所述基于身份的加密运算进行加密；使用由所述第一方从所述密钥服务获得的所述私钥对所述第二消息进行解密，以便获得所述第二随机密钥组件；识别所述第二消息是来自所述临时目的地；从所述第一方向所述临时目的地发送包括已加密随机密钥组件对的第三消息，所述随机密钥组件对由所述第一随机密钥组件和第二随机密钥组件而构成，并且已在所述第一方处使用所述临时目的地的公钥根据所述基于身份的加密运算进行加密，以及，所述第三消息还包括在所述第一方处被计算出并且在所述第一方处使用所述第二方的公钥根据所述基于身份的加密运算进行加密的已加密随机密钥；以及在所述第一方处从所述临时目的地接收包括所述已加密第一随机密钥组件的第四消息，所述第一随机密钥组件已在所述第一方处被计算出，以及，所述第四消息已使用所述第一方的公钥根据基于身份的加密运算进行加密。
9.一种用于在第一方与第二方之间实施符合多媒体通信系统的认证密钥协定协议的方法，所述方法包括以下步骤从密钥服务获得用于所述第一方的至少一个私钥；从所述第一方发送旨在被所述第二方接收的包括已加密第一随机密钥组件的第一消息，所述第一随机密钥组件已在所述第一方处被计算出，以及，所述第一消息已使用所述第二方的公钥根据基于身份的加密运算进行加密，其中，所述第一消息被所述多媒体通信系统中的至少一个功能单元拦截；在所述第一方处从所述功能单元接收包括已加密随机密钥组件对的第二消息，所述随机密钥组件对由所述第一随机密钥组件和在所述功能单元处计算出的第二随机密钥组件而构成，以及，所述第二消息已在所述功能单元处使用所述第一方的公钥根据所述基于身份的加密运算进行加密；使用由所述第一方从所述密钥服务获得的所述私钥对所述第二消息进行解密，以便获得所述第二随机密钥组件；从所述第一方发送旨在被所述第二方接收的包括所述第二随机密钥组件的第三消息， 所述第三消息已使用所述第二方的所述公钥根据所述基于身份的加密运算进行加密，其中，所述第三消息被所述功能单元拦截；以及在所述第一方处基于所述第二随机密钥组件计算出安全密钥，所述安全密钥被用于进行经由所述多媒体通信系统的媒体平面与所述第二方的至少一个呼叫会话；其中，所述功能单元能够计算出相同的安全密钥。
10.一种用于在第一方与第二方之间实施符合多媒体通信系统的认证密钥协定协议的装置，所述装置在所述第一方处包括存储器；以及至少一个处理器，所述处理器耦合到所述存储器并且被配置为 从密钥服务获得用于所述第一方的至少一个私钥；从所述第一方向所述第二方发送包括已加密第一随机密钥组件的第一消息，所述第一随机密钥组件已在所述第一方处被计算出，以及，所述第一消息已使用所述第二方的公钥根据基于身份的加密运算进行加密；在所述第一方处从所述第二方接收包括已加密随机密钥组件对的第二消息，所述随机密钥组件对由所述第一随机密钥组件和在所述第二方处计算出的第二随机密钥组件而构成，以及，所述第二消息已在所述第二方处使用所述第一方的公钥根据所述基于身份的加密运算进行加密；使用由所述第一方从所述密钥服务获得的所述私钥对所述第二消息进行解密，以便获得所述第二随机密钥组件；从所述第一方向所述第二方发送包括所述第二随机密钥组件的第三消息，所述第三消息已使用所述第二方的所述公钥根据所述基于身份的加密运算进行加密；以及在所述第一方处基于所述第二随机密钥组件计算出安全密钥，所述安全密钥被用于进行经由所述多媒体通信系统的媒体平面与所述第二方的至少一个呼叫会话。
全文摘要
本发明的原理提供用于例如多媒体通信系统的媒体平面的通信环境中的一个或多个安全密钥管理协议。例如一种用于在第一方与第二方之间实施符合多媒体通信系统的认证密钥协定协议的方法在第一方处包括以下步骤。应当指出，加密/解密根据基于身份的加密运算来实施。用于第一方的至少一个私钥被从密钥服务获得到。包括已加密第一随机密钥组件的第一消息从第一方发送到第二方，第一随机密钥组件已在第一方处被计算出，以及，第一消息已使用第二方的公钥进行加密。包括已加密随机密钥组件对的第二消息在第一方处被从第二方接收到，随机密钥组件对由第一随机密钥组件和在第二方处计算出的第二随机密钥组件而构成，以及第二消息已在第二方处使用第一方的公钥进行加密。第二消息被第一方使用由第一方从密钥服务获得的私钥进行解密，以便获得第二随机密钥组件。包括第二随机密钥组件的第三消息被从第一方发送到第二方，第三消息已使用第二方的公钥进行加密。第一方基于第二随机密钥组件计算出安全密钥，安全密钥被用于进行经由多媒体通信系统的媒体平面与第二方的至少一个呼叫会话。
文档编号H04L9/08GK102484583SQ201080038207
公开日2012年5月30日 申请日期2010年8月23日 优先权日2009年8月28日
发明者G·S·桑达拉姆, V·卡库莱夫 申请人:阿尔卡特朗讯公司