安全关联的发现的制作方法
【专利摘要】公开了用于发现通信环境中形成的安全关联的技术。例如，一种用于形成第一计算装置（例如，第一客户端）和第二计算装置（例如，第二客户端）之间的可发现安全关联的方法包括以下步骤。第一计算装置被提供由所述第一计算装置使用以生成秘密数的种子，所述秘密数由所述第一计算装置使用以计算与第二计算装置进行安全通信时使用的密钥。其中所述秘密数能基于所述种子的知识被重新计算并且所述密钥能基于所述秘密数的知识被重新计算，以使得第三计算装置（例如，拦截服务器）能使用重新计算的密钥在所述第一计算装置和所述第二计算装置不知情的情况下拦截所述第一计算装置和所述第二计算装置之间的通信。例如，所述密钥可以是基于验证密钥交换的身份的结果。
【专利说明】安全关联的发现
[0001]本申请主张序列号为61/478，153的美国临时专利申请的优先权，该临时申请于 2011 年 4 月 22 日提交，题为 “Out-of-Band Lawful Discovery of SecurityAssociations”，其公开的全部内容在此引入作为参考。
【技术领域】
[0002]本发明的本发明一般涉及通信安全，更具体地，涉及在通信环境中发现安全关联的技术。
【背景技术】
[0003]互联网协议(IP)通信和电话系统已经得到了广泛的普及。两个客户端之间端到端IP通信的早期的例子之一包括即时消息，但很快随后出现了的基于IP的语音，现在许多供应商(例如，网络运营商和应用提供商)提供端到端基于IP的视频。然而，考虑到无线移动网络接入一直被窄带电路交换接入网络占据着，这些趋势在很大程度上受限于有线固定网络。然而，最近的4G (第四代)的宽带无线网络为所有形式的基于IP的多媒体端到端通信提供了舞台，而与接入类型无关。
[0004]随着向端到端的IP会话的过渡，市场已经在收益方面复苏并且也意识到在这些开放的IP网络中的安全和隐私性的重要。作为第一步，端到端的加密和验证的典范，获得了广泛的关注。虽然当代网上事务，涉及电子商务和企业内联网访问已经被确保安全端到端通信达十年之久，确保基于IP会话应用的问题已经在很大程度上留给了应用提供商，例如，SKYPE? (卢森堡的Skype技术S.A.的商标)。
[0005]随着全IP网络的来临，越来越有必要为网络运营商或其他人提供语音、视频和消息服务以提供安全端到端通信，同时遵守需求以支持合法拦截和安全关联发现。这种合法拦截和发现的安全关联，可能有必要作执法用途，或者只是用于一些非执法的目的，由此能够对几方及/或设备之间传输的加密信息进行解密，是有必要或者令人期待的。
【发明内容】
[0006]本发明的基本原理是提供用于发现在通信环境中形成的安全关联的技术。
[0007]例如，在本发明的一个方面，一种用于形成第一计算装置和第二计算装置之间的可发现安全关联的方法包括以下步骤。第一计算装置被提供由所述第一计算装置使用以生成秘密数的种子，所述秘密数由所述第一计算装置使用以计算与第二计算装置进行安全通信时使用的密钥。所述秘密数能基于所述种子的知识被重新计算并且所述密钥能基于所述秘密数的知识被重新计算，以使得第三计算装置能使用重新计算的密钥在所述第一计算装置和所述第二计算装置不知情的情况下拦截所述第一计算装置和所述第二计算装置之间的通信。
[0008]通过进一步举例的方式，在本发明的第二个方面，一种用于发现第一计算装置和第二计算装置之间形成的安全关联的方法包括以下步骤。第三计算装置从第四计算装置获得秘密数，其中，所述秘密数与所述第一计算装置生成的秘密数相同，其中，所述第一计算装置基于由所述第四计算装置向其提供的种子生成秘密数，并且其中所述第一计算装置使用所述种子生成所述秘密数，并使用所述秘密数计算与第二计算装置进行安全通信时的使用的密钥。第三计算装置基于所述秘密数重新计算所述密钥，以便在所述第一计算装置和所述第二计算装置不知情的情况下拦截所述第一计算装置和所述第二计算装置之间的通f目。
[0009]本发明的说明性原理提供方法以合法发现安全关联，包括但不限于对密钥和其他加密数据，对于端到端的加密的会话，使用的技术特别适用于但不限于依赖于公开钥密钥方法进行密钥管理的系统。例如，本发明的技术可以用在根据实现非对称相互验证的密钥交换和/或任何基于的DifTie-Hellman密钥交换的系统和协议。特别是，本发明的覆盖过程是检测不到的，同时满足各种兼容性要求。可以理解，而本发明的原理特别适合因特网协议多媒体子系统(頂S)的环境中，但是本发明并不局限于此。也就是说，本发明原理的一般适用于任何合适的通信系统，在该系统中希望提供合法安全关联发现功能。仅仅作为例子，这样的本发明的技术可应用于其它的通信系统，这样的系统是基于MS信令框架或任何其它信令框架的电话会议系统。
【专利附图】
【附图说明】
[0010]图1示出基于密钥传输方法的客户端。
[0011]图2示出了网络辅助密钥传输方法。
[0012]图3示出对称的相互验证的密钥交换方法。
[0013]图4示出基于身份的验证密钥交换方法。
[0014]图5示出中间人密钥发现方法。
[0015]图6示出根据本发明的实施例的伪随机生成器。
[0016]图7示出根据本发明的实施例的利用秘密数再生的合法的会话密钥发现方法。
[0017]图8示出根据本发明的实施例的利用秘密数再生的合法会话密钥发现的呼叫流。
[0018]图9示出根据本发明的实施例在会议呼叫环境中利用秘密数再生的合法的会话密钥发现方法。
[0019]图10示出概括的数据网络硬件体系结构和适于执行根据本发明实施例的的一个或多个方法和协议的通信(计算)装置。
【具体实施方式】
[0020]这里所用的术语“多媒体通信系统”一般定义为能够通过媒体面输送一个或多个包括但不限于基于文本的数据、基于图形的数据、基于语音的数据和基于视频的数据的媒体类型的任何通信系统
[0021]用在这里的术语“媒体平面”通常被定义为多媒体通信系统的功能部分，可以使用本发明的媒体平面的例子包括但不局限于一个或多个类型的媒体在呼叫会话中的两方或多方之间进行交换。这与“控制平面”是相对的，控制平面是多媒体通信系统的功能部分，根据控制平面执行呼叫协商/调度，以建立呼叫会话。可以使用本发明的技术的媒体平面应用可包括，但不仅限于，基于IP的语音(VoIP)、即时消息(IM)、视频/音频IM、视频分享以及基于IP的视频。可以理解，媒体平面包含应用层业务量。然而，本发明的合法的安全关联的发现技术，本发明的技术可以适用于通信系统的任何平面或层。
[0022]本文所用的术语“密钥” 一般定义为加密协议的输入，例如，用于但不限于实体验证、隐私、消息的完整性等。
[0023]这里所用的术语“安全关联”，一般是指在通信环境中跨越两方或两方以上通信和/或设备通信的安全定义。在一个实施例中，安全定义可以包括但不限于会话密钥。
[0024]本文所用的“种子”一词一般指的是包括至少一个随机数的一组数字。
[0025]本文所用的“客户机”一般是指通信设备或一些其它计算系统或设备，允许一个或多个用户、当事人或实体在通信环境中，与一个或多个其它通信装置和其他计算系统，例如另一个客户端进行通信。本文所用的“客户端”也可能一般指的是在计算装置上的应用程序或其他计算机程序。因此，尽管术语客户端可以在下文中指代设备，应当理解，术语“客户端”并不限于硬件，但也可以是软件，或者它们的组合。
[0026]这里所用的“通信会话” 一般是指用于两个设备之间的通信的目的至少两个通信设备或其他计算系统(例如，客户端)之间的连接。因此，如本文所用的“端至端”通信通常是指从一个装置(例如，客户端)到其他装置(例如，客户端)的整个连接路径。此外，所述两个或更多参与通信会话的客户端的被称为“端点设备”“终端设备”或简单的“端点”。然而，本发明的合法的安全关联的发现技术可以被应用到任何计算或通信的移动设备，而不是仅仅一个客户端。
[0027]本文所用的“应用”(或“应用程序”)，一般是指一个或多个计算机程序，当执行时，执行一个或多个给定的功能。
[0028]本文所用的术语“合法”通常被定义为满足一个或多个必须遵守的要求或与政府或私人权威实体相关联的指导原则。这种权威实体可能服务于执法功能或者非执法功能。也就是说，术语“合法的”不打算限于法律的实施，而是还可以包括符合非执法意义上的遵守。
[0029]为了便于参考，详细描述如下划分。第I节描述了可应用于本发明原理的示意性的用例和供应商。第II部分介绍了现有的端到端的密钥管理方法。第III节介绍了现有的主要解决方法。第IV部分描述了根据本发明原理的示例性互联网协议(IP)多媒体子系统(IMS)环境中合法的安全关联发现解决方案。第V节描述了根据本发明的示例性的原贝U，在电话会议环境中的合法安全关联发现解决方案，第VI节描述用于实现根据本发明的一个或多个合法的安全关联的发现方法的示例性计算系统。
[0030]1.说明性的用例和提供商
[0031]本文所描述的可应用于本发明原理示例性的用例，包括一个端到端的加密的客户端至客户端的通信会话。仅通过举例的方式，而不是旨在以任何方式限制，这样的用例包括:
[0032]1.基于文本的頂或即时消息应用程序。
[0033]2.基于Internet协议的端到端的多媒体消息的应用(包括音频和/或视频)。
[0034]3.通过各种数据包交换接入网络的基于IP的语音，。
[0035]4.通过各种分组交换接入网络的基于IP的视频。
[0036]5.涉及一组参与者的文本会议和多媒体应用。[0037]这些说明使用的情况也同样适用于各种供应商。通过举例的方式，可以将供应商分为三类:
[0038]1.服务提供商可以是企业(首席信息官或CIO控制转出、管理和应用的操作)。注意这里企业可能是一个公司或政府实体。
[0039]2.服务提供商可能是应用程序提供商(例如，Skype和GoogleTalk等),并跨网络和跨类型提供这样的服务。
[0040]3.月艮务提供商可能是网络提供商(例如,Verizon无线，AT & T公司，Sprint,T-Mobile 公司，Vodafone 等)。
[0041]根据本发明原理的描述的问题和解决方案的示例性范围也同样适用于所有的供应商，特别是对于端到端的通信类型或应用程序不可知的。
[0042]I1.端到端密钥管理
[0043]给定端到端IP会话，并且希望提供安全的端到端通信，已经设计了端到端密钥管理方。例如，可以将这些方案划分为四类:(I)基于客户端的密钥传输协议；(2)网络辅助密钥传输协议；(3)对称相互验证密钥交换协议；以及(4)不对称相互验证密钥交换协议。
[0044](I)基于客户端的密钥传输协议。如图1所示的协议100。被称为“发起者”(即，启动特定通信会话的客户端)的客户端装置102-1使用已建立的逐跳安全消息传送方案，该传送方案适于确保通过一个或多个网络单元104-1,104-2向被称为”响应方“(即，响应特定的通信会话的发起者的客户端)的客户端装置102-R的信号传输安全。然后，所有各方在通信会话使用密钥(或从该密钥的推导)，以确保会议安全。图1所示的例子基于会话描述协议(SDP)，这是一个用于对安全实时传输协议进行密钥协商的协议，例如，2006年7月公开的会话描述协议(SDP)互联网工程任务组(IETF)征求意见(RFC) 4568，“SecurityDescriptions for Media Streams, ”,其公开的全部内容在此引入作为参考。在这种情况下，客户端102-1跨网络(端到端)发送SDP提议到客户端102-R，并且客户端102-R以SDP应答作为响应，从而建立用于保护特定会话相关联的通信安全安全密钥。
[0045](2)网络辅助密钥传输协议。如图2所示的协议200，图2中，客户端装置202-1 (发起方)从运营商网络中(或数据中心)的服务器204 (密钥管理服务器或KMS)请求给定会话密钥，然后从服务器204向发起方传送密钥和密钥“指针”(以标签或令牌的形式)。发起者然后利用已建立的逐跳的安全关联安全地与客户端装置202-R (响应方)共享“指针”，这之后，响应方通过提出向服务器204呈现“指针”从其获得密钥。网络辅助协议的两个例子包括2005年7月 IETF RFC4120描述的Kerberos系统在,“Kerberos Network AuthenticationService”，以及 2011 年 3 月 IETF RFC6043 中描述的 MIKEY 标签系统“Ticket-based Modesof Key Distribution in Multimedia Internet Keying”,其公开的全部内容在此引入作为参考。
[0046](3)对称的相互验证密钥交换协议。如图3所示的协议300，发起方(302-A)和响应方(302-B)共享对称密钥，然后他们使用该密钥执行相互验证密钥交换协议，包括随机数字和/或同步计数器。这种协议的一个例子在1994Springer出版社的LNCS773，加密’ 93，密码学的进展，M.Bellare和P.Rogaway,Entity Authentication and Key Distribution”(作者Ed.D.Stinson)中有所描述，其公开的全部内容在此引入作为参考。
[0047](4)验证密钥交换使用非对称公共密钥协议。在这种类型的协议中，发起方和响应各具有一对密钥(私有和公共的)。典型的例子包括使用他们的私人密钥来验证，但公共密钥互相寻址，以及使用公共密钥方法用于密钥交换。图4的协议400显示了 IBAKE(基于身份的验证密钥交换)协议和使用非对称公共密钥方法。IBAKE协议在2009年2月17日提交的、序列号为12/372,242的美国专利申请中进行了描述，其公开的全部内容在此引入作为参考。
[0048]如图4所示的协议400，IBAKE协议定义了两个端点之间的相互验证和密钥交换:发起方A (客户端402-A)和响应方B (客户端402-B)。无论是发起者和响应方每拥有一对密钥，分别是公共密钥和私有密钥。在公共密钥加密的情况下，公共密钥用于加密而和私有密钥用于解密。标准公共密钥的方法和基于身份公共密钥方法之间的根本差别是，在后者中，公共密钥对应的“身份”和相应私有密钥是由受信任的服务器(称为密钥管理服务器或KMS)生成。
[0049]所示的协议中的主要概念是，在发起方和响应方彼此进行身份验证，并使用密钥管理服务器(未示出)提供的私有密钥生成会话密钥，但服务器不能确定该会话密钥
[0050]观察图4，发起方A选择一个随机的秘密数(secret) “x”计算值“xP”(其中P是有限域上的椭圆曲线上的点)，然后发送“xP”至响应方B。同样，响应方选择计算一个随机的秘密“y”并计算“yP”的值，之后将“yP”发送给发起方A。使用“x”和“yP”，发起方计算“xyP” ；同样使用“y”和“xP”，响应方计算“xyP”。这让双方就通信会话的密钥达成一致。然而，密钥管理服务器(KMS)可以得知“xP”和“yP”，但不能计算“xyP”。
[0051 ] 意识到这一点，在所有上面列举(四)密钥传输/交换协议中，独立于通信类型或供应商，存在监管和/或合规性要求，由此，供应商可能被要求合法发现和分享端到端安全密钥(称为“合法的发现”)。
[0052]协议类型I和2的这个要求可以相对容易地满足。在协议类型I (图1)，感兴趣的安全密钥以逐跳保护的方式在网络节点之间的传输，并因此被称为参与传输的网络节点(例如，图1中的网络单元104-1、104-2)所知。在协议类型2 (图2)中，会话密钥由服务器(例如，图2的KMS204)生成，因此提供者可得到。
[0053]通常情况下，在协议类型3 (图3)中，供应商参与置备这些成对的共享秘密数，因此了解这些秘密数。在这种情况下，提供商相当直接地发现会话密钥和满足法律及合规要求。
[0054]但是当提供商只是密钥管理事务的推动者，而不是事务参与者时，这种合法的发现问题尤其对于协议第4类(图4)形成挑战。总之，问题是发现端到端安全密钥，特别是当非对称的公共密钥用于端到端密钥管理时。此外，这样的发现，需要在通信会话期间不引人注目且检测不到。
[0055]II1.在不对称的公开密钥协议中的密钥解决方案
[0056]本节介绍了现有的用于端到端的密钥管理协议的非对称公共密钥协议的密钥解决方法。
[0057](I)通用协议说明
[0058]这里我们特别注重利用Diffie-Hellman型密钥交换(例如，见IETF RFC2631协议，“Diffie-HeIIman Key Agreement Method, ” 1999 年 6 月，
[0059]其中披露的全部内容在此引入作为参考)。在有限域模素数P的乘法群中，我们描述的协议典型地由Diffie和Hellman在其里程碑式的论文(W.Diffie, M.Heilman, “NewDirections in Cryptography,，，IEEE Transactions on Information Theory, vol.1T-22, 1976 年 11 月，第 644 - 654，the disclosure of which is incorporated byreference herein in its entiretyIEEE 事务信息理论，第一卷 IT-221976 年 11 月，PP:644-654中，其公开的全部内容在此引入作为参考)。然而，众所周知的是Diffie-Hellman协议可以扩展到任何组，但该协议的安全性依赖于该组的属性。
[0060]在这个协议中，两个端点(A和B)每个为G (生成器)和P (大素数)选择公开的数值，G是非零整数乘法群的生成器模大素数P。
[0061]要执行该协议，A选择一个随机的秘密数X和计算a=G~x (modP)。同样，B选择一个随机的秘密数I和计算b=G~y (modP)o但是应当理解的是,秘密x和y是小于P的随机正整数。
[0062]A发送值a到B，和B的发送值b到a。
[0063]接收值b时,A计算k=b*x(mod P),同样,在收到值a时,B计算k=a*y (mod P)。很容易看到，k= (a) *y (mod P) = (b) *x (mod P), k是相互计算的公共会话密钥
[0064](2) IBAKE 中 Diffie-Hellman 的特殊用途
[0065]IBAKE协议(在图4中示出)在有限域上的椭圆曲线上的点的组，因此依赖于有限域上的椭圆曲线的在一组点中的相应的Diffie-Hellman问题。每个端点(如A)有一个已知的公开身份，可以被任何其他的端点(如B)使用以为A创建公共密钥(PUB_A)。同样，知道B的公开身份，任何其他端点可以创建PUB-B。
[0066]偶尔并定期地，每个端点(如A)接触特殊的基于网络的功能，密钥管理服务器(KMS)，收到特别计算的私有密钥(例如，PR_A)，该私有密钥与相应的公共密钥(PUB-A)计算上相关。同样，其他端点做同样的工作。结果，每个端点具有公-私密钥对，而公共密钥是基于端点的身份。
[0067]要执行该协议，每个端点选择一个随机的秘密数。设X是由A选择的随机数，并设y是由B选择的随机数。
[0068]在第一步骤中，A计算xP，其中P是椭圆曲线E上的公知点(即，使用加法定律P添加到自身X次)，使用B的公共密钥PUB_B对其加密，并把它发送到B。在这一步中，加密是指基于身份的加密，这在Dan Boneh, Matthew K.Franklin 的“ Identity-Based Encryptionfrom the Weil Pairing” Advances in Cryptology-Proceedings of CRYPT02001 (2001),以及在IETF RFC5408和5409中有描述，其公开的全部内容在此引入作为参考。
[0069]收到加密的消息后，B对消息进行解密，并获得xP。
[0070]随后B计算yP，使用A的公共密钥PUB_A加密{xP，yP}，接着将其传输到A。
[0071]在收到此消息后，A对消息进行解密，并获得yP。随后，A用B的公共密钥加密yP并将其发送回至B。
[0072]在此之后,A和B计算k=xyP作为会话密钥。具体而言，A通过将接收和解密yP加到其自身X次计算k=xyP。同样，B通过将接收和解密的xP加到其自身X次计算k=xyP
[0073](3)用于合法会话密钥发现的中间人密钥解决方法
[0074]Diffie-Hellman密钥交换方法的典型的和众所周知的密钥发现基于所谓的“中间人”(MitM)方法。在这种方法中，积极的中介C将其自身至于端点A和B之间的通信链路上。中介C将其本身对A呈现为B，对B呈现为A。
[0075]中介C创建自己的秘密数，x’和y’。当C从A接收到a时,它以b’ =G~y’(modP)响应，同样发送a，=G~x，(modP)到B。
[0076]当交换完成后，A和 C 生成 kl= (G~x (modP)) *y’ (mod P) = (G~y，(modP)) *x) (modP)，而 C 和 B 生成 k2=(G~x’ (modP)) *y (mod P) = (G~y (modP)) *x’ (mod P)。结果，通过维持A和B之间两个独立的安全会话保持，积极的中介C能够解密和重新加密的A和B之间的通信。
[0077]然而，对于一些复杂的终端装置，交换无论是图片或双方计算的密钥签名表示并认识到他们实际上是计算了两个不同的密钥是可能的。这会导致MitM功能的发现，在合法的会话密钥发现中这是不期望的。
[0078]图5显示客户端500-A和502-B使用MitM方法的协议500。需要注意的，通过拦截控制单元(ICE) 506和拦截网络单元(INE) 508来尝试合法监听(LI )，拦截控制单元(ICE)506拦截两个端点装置之间的信令，拦截网络单元(INE)508拦截的两个端点装置之间的媒体。注意，ICE如何从KMS504获得必要的私有密钥(例如，？1?_4和卩1?_8)。然而，正如上面提到的，这样的LI功能可能会被特定的复杂端点装置检测到。
[0079](4)通过强制创建秘密数的密钥解决方法
[0080]另一种方法，强制至少一个端点(例如，A)创建的秘密数(X)，秘密数(X)对于参与会话密钥的合法发现的专门网络节点来说也是可知的。在这个方案中，端点A并没有选择秘密数x，而是等待网络发送如随机数(N)的特殊参数给它，然后哈希这个随机数与它与网络共享的另一个秘密数(S)。其结果是，端点A和专门网络节点都产生x=H(S，N)。随后，这个产生的X用作Diffie-Hellman交换中的指数。
[0081]可以很容易地看到，专门网络节点可以计算k=(G~y (modP))*x(mod P),并因此成为A和B之间的通信链路的秘密密钥的暗中参与者(privy)。
[0082]然而，期待收到随机数，端点装置充分意识到网络合法发现会话密钥的出现和意图，这是非常不可取的。特别是，通过在通信会话期间串通端点装置以及一些其他工作，该密钥发现解决方案是可检测的，即使只有一个串通的端点装置。
[0083](5)到托管(Escrow)服务器的密钥转移
[0084]还有另一种方法，基于从网络节点发送到端点装置的特殊请求。这一请求迫使端点装置向基于网络的密钥托管数据库上传计算出的用于对A-B通信链路进行加密的密钥k或其衍生物。上传通常是在端点和密钥托管数据库之间建立安全隧道的保护下进行。
[0085]然而，接收这样的请求的端点装置清楚地认识到密钥托管数据库的存在，因此，可能出于合法发现会话密钥的目的拦截安全通信，这是不期望的。
[0086]IV.改进的合法安全关联发现
[0087]根据本发明的示例性实施例，提供了密钥发现问题的解决方案，这依赖于提供商发现通信会话的至少一个参与者的“随机秘密数”。该方法(这将在下文中更详细描述)的工作原理具体如下。
[0088]伪随机数生成器(PRG)包括在客户端应用程序中(例如，嵌入式)。这可以由提供商完成，但是也可以由另一实体做到，例如，应用程序开发者或作者。在后一种情况的情况下，使得提供商知道包括在客户端应用程序中的PRG。[0089]网络运营商或例如企业的应用程序的所有者向应用提供与客户端的身份相关联的秘密随机种子(S)。此随机种子通常是一个随机数，或更一般的是一组数字，其中包括至少一个随机数。种子可以进一步根据需要经常更新，本发明的解决方案不受所使用的提供的种子或如何经常更新种子的方法影响。
[0090]这种关联，即种子和身份，存储在由网络运营商或应用程序的所有者(例如企业)管理的服务器中。此外，我们允许种子对于一个给定的身份被更新，如果需要的话，但对客户端的任何更新都必须在服务器上执行。
[0091]为了执行诸如Diffie-Hellman、IBAKE等的密钥交换协议，应用需要产生用于会话的随机数(秘密数)(例如，X)时，PRG被调用。PRG使用种子和确定性的、单调增加的量(值)，例如时间戳或外部管理计数器(C)，以产生所需的伪随机值X。但是应当理解，该值可以是任何单调递增的值，例如会话计数器、时间戳、或一个简单的计数器值，该值具有自己的复位或增量规则。标准是，在种子的生存期期间，对于同一装置，它从会话到会话不重复。
[0092]图6示出了根据本发明的实施例的伪随机生成器600。在该示例性实施例中，PRG基于SHAl算法，该算法定义在1995年4月的FIPS刊物FIPS180-1，“Secure HashStandard”，其公开的全部内容在此引入作为参考。但是应当理解，本发明的原理不限于这个特定的算法。
[0093]为了产生伪随机的X，128位随机预配置的种子(S)与专用于SHAl算法的传统初始向量(IV)进行异或运算(逻辑“异或”功能602)。
[0094]该时间戳或外部管理的单调递增计数器(C)，任选地与另一个预配置的常数(例如，512位的常数)进行异或运算(604 )，被作为“消息”施加到SHA-1算法的输入(在606中)。另外从执行SHAl产生的160位值s被与Rs+Q mod G功能(在608中)“白化”(“whitened”)以确保s的每一位具有相同的硬度，生成的160位值X (610)被输出至Diffie-Hellman型协议。在这里，在R和Q是公知的预先选定的大多项式，其系数在二进制字段中，G是多项式(T16°+T5+T2+l)。或者，可以使用任何有限域(不只是一个二进制字段)，并可以使用该有限域的任何不可约多项式(不只是上述建议的特定G)。更普遍的是，任何白化函数都可以使用(不只是线性同余的哈希函数Rs+Q mod G)提取硬位(hard bits)。
[0095]使用序列号或客户端的身份跟踪安全通信客户端应用的每个实例。例如，Alice@abcenterprise.com从“ABC企业”接收安全通信客户端软件的实例，其中包括序列号(或Alice的身份)。提供商跟踪相关联的预配置的随机种子S和例如系统时间的单调增加的计数器值C。这将允许提供商重新生成Alice与其他方的密钥交换会话期间产生的相同的随机数。
[0096]当发现有密钥和拦截谈话的合法要求时，提供商开始记录加密通信会话与之前的密钥交换会话。然后，脱机服务器计算发起方(或响应方)在密钥交换协议中使用的随机秘密数以计算交换的组单元。有利地，这允许，脱机服务器计算发起方(和响应方)进行了计算的相同的会话密钥。
[0097]但是应当理解的是，示于图6中的PRG仅仅是可以使用的一个实例。作为其他例子，也可以采用其他PRG，例如在3GPP TS33.220中指定的被称为密钥导出函数KDF的PRG，该文献中公开的全部内容在此引入作为参考。还可以使用其他PRG。
[0098]图7示出了根据本发明的实施例的用于会话密钥与秘密数重新生成的合法发现方法700。特别是，本实施例中示出的客户端装置702-A和客户端装置702-B之间的安全关联的拦截和发现包括密钥。
[0099]请注意，如图所示，企业服务器708规定在每个客户端装置(移动终端)中，并且与此并行地，在与所述客户端装置相关联的企业服务器订阅中，每个移动装置种子S —个秘密数。种子值的可以生存于客户端订阅期间，或者基于企业策略被修改。在客户端和企业服务器置备种子S所采用的方法可以使用多重已知技术范围，例如，从工厂编程来引导其他现有的安全验证到执行标准或运营商特定的配置程序。
[0100]另外，如图所示，拦截实体704(本文中表示为在“拦截网络单元”，假定其能访问信令和媒体)从其他网络节点请求所有必要的信息，但不是从端点装置(702-A，702-B)本身。因此，端点装置是不知道企图拦截的情况。此外，取决于拦截要求，这种信息交换可以大幅提前于通信会话的实际开始时间进行，或在会话结束后稍后的时间。因此，这个信息交换可能被称为“离线”，即，不在通信过程中。这大大降低了网络单元之间的所需的协调(与图5中示出的MitM解决方案相比)相关的复杂度。然而，这种交换或交换的一部分可交替在通信过程中进行。
[0101]因此，如图所示，拦截实体704从企业服务器708请求并获取与客户端装置702-A相关的重复的随机“秘密数”x (注意的是，术语秘密数为了强调加了引号，即，而X是一个对于其他方来说的秘密数，因此是技术上的秘密数，X对于企业服务器和拦截实体来说不是秘密，这两者都可以重新产生X)。也就是说，当该秘密随机种子(S)由企业服务器708提供到客户端时，因为客户端702-A采用与客户端702-A的身份相关的秘密随机种子(S)生成安全密钥的应用是预配置的(客户端702-A不知情)，企业服务器708向拦截单元704提供相同的随机“秘密数”x。回想一下，企业服务器可能会由应用提供商/所有者和/或网络运营商维持。还要注意的是，拦截服务器通过发送C (记得图6中的会话计数器值C，尽管C可以替代地是会话时间戳)和它希望希望监测的标识符(在这个例子中，ID_A)，)从企业服务器708请求“秘密数”X。该标识也可以是一订阅或者与第一计算装置相关联的用户身份。
[0102]此外，拦截实体704假定具有与KMS706的安全信任关系，KMS有义务在监视之下(在这种情况下，客户端702-A)提供与端点相关联的私有密钥。在企业环境中，这更是合规问题，而不是监管责任。一旦收到这些参数(端点私有密钥和随机的“秘密数”x)，拦截实体704具有所有必要的信息来重新生成A和B在对业务量加密中使用的秘密会话密钥，在端点不知道的情况下，施加会话密钥的合法发现。
[0103]重要的是要注意，KMS或者网络运营商/企业都不能够自己单独解密的端点之间的通信流，数据保密是受到端到端保护的。KMS706能够因为它可以访问到端点702-A和702-B的私有密钥而解密IBAKE协议消息的IBE加密有效载荷，这使得它能够获得在端点之间的IBAKE消息中交换的xP和yP参数。但KMS706没有能力重建所需的xyP会话密钥，因为它不知道X或y。同样，运营商/企业服务器708可以重新创建X或y，但在没有端点702-A和702-B的私有密钥的情况下，没有能力解密IBAKE消息的IBE加密有效载荷。因此也不能成功重建所需的会话密钥xyP。只有从KMS706和企业服务器708两者接收参数执行合法发现会话密钥的功能实体(即，拦截实体704)可以解密业务量。但是，如果两端点是相同的运营商/企业用户，那么企业服务器可以简单地发现用于会话的X和y的值以发现会话密钥而不需要与KMS合作。来自KMS的信息只有在验证实际上使用了由企业服务器计算的X和y的值的端点时是有用的。在这种情况下，要注意，如果这样的验证是没有必要的，则该会话密钥可以被发现，甚至在没有记录信令事务的情况下，这进一步简化了的安全关联事务的合法发现过程。
[0104]图8示出了根据本发明的IBAKE实施例的采用秘密数重新生成的会话密钥合法发现的呼叫流。请注意，为了便于理解和一致性，在呼叫流程中的附图标记用与图7相同的附图标记表示。还要注意的是本发明的安全关联的合法发现技术不限于使用任何特定的协议，因此，在本实施例中的IBAKE协议(及在下面的图中9描述的电话会议的实施例)是用于示例性的目的。
[0105]需要注意的是，如图8所不，步骤1，2, 3代表的是端点A和B之间典型IBAKE协议交换。这些步骤如上所述。如果A或B被选为合法拦截的对象，拦截服务器(拦截实体)704通过本发明的安全关联发现技术监视和记录这些信令事务。
[0106]S卩，在图8的步骤4和5中，拦截服务器704从KMS706请求A和B的私有密钥。当A和B成为拦截目标时，此项事务可以大幅提前于实际IBAKE事件来做。在这种情况下，当A和B开始通信时，A和B的公共密钥和私有密钥已经在拦截服务器处可得。
[0107]步骤6和7也可以在实际的A-B通信会话之前，期间和之后随时执行。例如，如果通信会话由拦截服务器以加密形式的记录，拦截服务器向企业服务器708提供与特定会话相关的C值(时间戳或计数器)，并接收与该会话相关的X。然后，它可以如所示的计算k并解密A和B之间的通信。
[0108]现在，进一步说明当端点A和B不仅是不同的运营商/企业的用户也可以使用不同的提供私有密钥的KMS的情况下如何实现拦截。也就是说，为了拦截包括目标客户端A的会话，在图8的步骤4和5中，拦截服务器704从与客户端A相关的KMS706请求的私有密钥。当A成为拦截的目标时，可大幅提前于实际IBAKE事件来做此工作。
[0109]步骤6和7在拦截服务器704和与客户端A相关的企业服务器708的之间执行，拦截服务器接收与该会话相关的X。
[0110]当客户端B是拦截目标的情况下，在图8的步骤4和5中，拦截服务器704从与客户端B相关的KMS706请求B的私有密钥。在图8的步骤6和图7中，拦截服务器704从与客户端B相关的企业服务器708获得y。
[0111]然后，拦截服务器可以解密在图8的步骤3中发送的信息，并取得客户端A发送的xP参数。知道了 y和xP的值，如图所示，然后拦截服务器计算k并解密A和B之间的通信。
[0112]V.组设置中改进的合法安全关联发现
[0113]我们现在转到如电话会议环境的组设置。在会议呼叫中，一组参与者交换密钥材料就并一组密钥达成一致。特别地，DifTie-Hellman密钥交换已经扩展到组设置(参见，例如，Burmester 和 Desmedt, “A secure and efficient conference key distributionsystem”，论文集’ 94EUR0CRYPT,卷950LNCS，第275-286页，1995年斯普林格，其公开的全部内容在此引入作为参考)，另外IBAKE已经被扩展到组设置中的地址验证密钥交换(参见，例如，2009年8月28日提交的、由序列号12/549，907标识的美国专利申请，其公开的全部内容在此引入作为参考)。注意，短语“组设置”在这个例子中是用户多于二的一组用户，并且协议允许所有用户在不安全的环境中交换信息和交流“组密钥”(如适用)，但不限于会议系统。[0114]图9示出根据本发明的实施例的会议呼叫环境中的采用秘密数重新生成的合法会话密钥发现方法900。具体地，图9示出使用IBAKE的组密钥交换。在此设置中，中央协调服务器904 (称为会议安全服务器)验证和授权每个用户(装置902-1至902-N)参与组密钥交换。然而，从IBAKE计算导致的组密钥不知道中央协调服务器904。但是，由于合规及其他监管规定，往往要求会议提供商发现组密钥。
[0115]如图所示，每个用户单独与会议服务器执行IBAKE。这使得服务器确保在呼叫中只有经过身份验证和授权的参与者被允许。在此之后，服务器与呼叫者的每一方共享Diffie-Hellman密钥组成成分，从而让每个参与者计算额外的密钥组成部分并且和其余的参与者(通过服务器)一起分享。利用基本的组理论，它可以很容易看出，所有参与者都可以计算出相同的组密钥，但会议服务器将无法确定密钥。该协议被描述为图9的906。
[0116]如上文第IV节描述的本发明的合法密钥发现技术，也在此设置简单的方式进行扩展。如上所述，网络运营商或企业或应用提供商可以使用端点客户端(902-1至902-N)上运行的应用程序中包括的相同的伪随机数生成器的副本来生成随机的秘密数，并因此发现计算组密钥。这是从这样的事实得出的:使用相同的伪随机数生成器并发现调用生成器的所使用的参数，允许拦截服务器(在这种情况下，会议服务器904或其他拦截实体)重新创建在协议中使用的一个或多个随机数来计算组密钥。详细的计算在基本组理论中是一个简单的练习。
[0117]V1.示例性计算系统
[0118]图10示出了概括的网络环境的硬件体系结构1000和计算装置形式的通信装置，这些计算装置适于根据本发明实施两个实体之间的秘密密钥管理协议和合法的安全关联发现。
[0119]虽然图图10示出详细的子组件只有两个图示的实体，但是应当理解的是，具有相同配置的其他实体也是可以的。因此，就上文描述的安全密钥管理协议和合法安全会话发现来说，详细示出的这两个实体可以是发起方客户端装置702-A (第一方或A)和响应方客户端装置702-B (第二方或B)。然而，KMS (706)、会议服务器(904)、拦截服务器(704)、、功能单元，附加的客户端装置(或成员)和额外的服务器(708)可以实现为与图10所示的计算装置具有相同体系结构。因此，通过举例的方式，拦截服务器1020、企业服务器1022和KMS1024在图10中示出并且被理解为与所示的装置1002和1004具有相同的计算架构。然而，可以理解的是，为了简单起见，可能参与本发明的协议的所有计算装置(通信装置)中未在图10中示出。
[0120]如图所示，A的计算装置1002和B的指定的计算装置1004经由网络1006耦合。横跨该装置能够进行通信，例如，在上述的实施例中，网络1006可以包括可公开访问的广域通信网络，诸如由网络运营商(例如，Verizon公司，AT & T公司，斯普林特公司)等运行的蜂窝通信网络。然而，本发明并不限于特定类型的网络。通常情况下，这些装置可以是客户机。可受聘在本文所述的协议由各方共同参与的客户端装置的例子可以包括但不限于蜂窝电话、智能电话、桌面电话、个人数字助理、笔记本电脑，个人电脑等。如上所述，客户端也可以是在计算装置上(例如，智能电话)的应用程序。然而，一个或多个装置可以是服务器(例如，拦截服务器，企业服务器，KMS服务器等)。因此，应该理解，本发明的方法和协议不限于计算系统是客户机和服务器的情况，相反的是适用于包括两个网络单元的任何计算装置。[0121]对于本【技术领域】的普通技术人员显而易见的是，服务器和客户机可以被实现为计算机程序代码的控制下的编程计算机。计算机程序代码将被存储在计算机可读存储介质(例如，存储器)中，并且代码由计算机的处理器将执行。鉴于本本发明的公开，本领域技术人员可以容易地产生适当的计算机程序代码，以实现本文所描述的协议。
[0122]尽管如此，图10概括地地示出每个计算机系统通过网络进行通信的一个示例性的体系结构。如图所示，1002装置包括I/O装置1008-A，处理器1010，存储器1012-A。装置1004包括I/O装置1008-B1010-B处理器，存储器1012-B。应当理解的是，本文所用的术语“处理器”包括一个或多个处理装置，包括一个中央处理单元(CPU)或其它处理电路，包括但不限于一个或多个信号处理器，一个或多个集成电路，等。此外，本文所用的术语“存储器”意在包括与一个处理器或CPU，如RAM，ROM,固定存储的移动装置(例如，硬盘驱动器)，或移动存储装置(例如磁盘或CD-ROM的内存)。此外，存储器是计算机可读存储介质的一个例子。此外，术语“I/O装置”在本文中是指包括一个或多个输入装置(如键盘，鼠标)用于将数据输入到处理单元，以及一个或多个输出装置(例如，CRT显示)，用于提供与所述处理单元相关联的结果。
[0123]因此，本文所描述的用于执行本发明方法的软件指令或代码可以被存储在一个或多个相关联的存储器装置，例如，ROM、固定或可移动存储器，并准备好被使用时，加载到RAM时，由CPU执行的。
[0124]虽然这里已经参考附图描述了本发明的说明性实施例，应该理解，本发明并不限定于这些具体的实施例，在本领域中，在不脱离本发明的范围或精神的情况下，可以由本领域技术人员作出各种其它的改变和修改。
【权利要求】
1.一种用于形成第一计算装置和第二计算装置之间的可发现安全关联的方法，包括: 第一计算装置被提供由所述第一计算装置使用以生成秘密数的种子，所述秘密数由所述第一计算装置使用以计算与第二计算装置进行安全通信时使用的密钥，其中所述秘密数能基于所述种子的知识被重新计算并且所述密钥能基于所述秘密数的知识被重新计算，以使得第三计算装置能使用重新计算的密钥在所述第一计算装置和所述第二计算装置不知情的情况下拦截所述第一计算装置和所述第二计算装置之间的通信。
2.根据权利要求1的方法，其中所述第一计算装置获取包括伪随机数生成器的应用程序。
3.根据权利要求2的方法，其中所述第一计算装置从第四计算装置获得应用程序。
4.根据权利要求2所述的方法，其中所述应用程序被提供所述种子，并且所述种子与关联到第一计算装置的标识符相关。
5.根据权利要求1所述的方法，其中所述应用程序调用所述伪随机生成器以基于所述种子生成所述秘密数。
6.根据权利要求1所述的方法，其中所述种子包括一组数字，所述一组数字包括至少一个随机数。
7.一种用于发现第一计算装置和第二计算装置之间形成的安全关联的方法，包括: 第三计算装置从第四计算装置获得秘密数，其中，所述秘密数与所述第一计算装置生成的秘密数相同，其中，所述第一计算装置基于由所述第四计算装置向其提供的种子生成秘密数，并且其中所述第一计算装置使用所述种子生成所述秘密数，并使用所述秘密数计算与第二计算装置进行安全通信时使用的密钥； 第三计算装置基于所述秘密数重新计算所述密钥，以便在所述第一计算装置和所述第二计算装置不知情的情况下拦截所述第一计算装置和所述第二计算装置之间的通信。
8.根据权利要求7所述的方法，其中所述第三计算装置向第四计算装置提供与关联到第一计算装置的身份相关的值，以使得第四计算装置返回所述第三计算装置需要的所述秘密数以重新计算所述密钥，以便拦截所述第一计算装置和所述第二计算装置之间的通信。
9.一种用于形成第一计算装置和第二计算装置之间的可发现安全关联的设备，包括: 存储器；以及 耦合到所述存储器的处理器，所述处理器被配置为使得第一计算装置被提供由所述第一计算装置使用以生成秘密数的种子，所述秘密数由所述第一计算装置使用以计算与第二计算装置进行安全通信时使用的密钥，其中所述秘密数能基于所述种子的知识被重新计算并且所述密钥能基于所述秘密数的知识被重新计算，以使得第三计算装置能使用重新计算的密钥在所述第一计算装置和所述第二计算装置不知情的情况下拦截所述第一计算装置和所述第二计算装置之间的通信。
10.一种用于发现第一计算装置和第二计算装置之间形成的安全关联的方法，包括: 存储器；以及 耦合到所述存储器的处理器，所述处理器被配置为使得第三计算装置从第四计算装置获得秘密数，其中，所述秘密数与所述第一计算装置生成的秘密数相同，其中，所述第一计算装置基于由所述第四计算装置向其提供的种子生成秘密数，并且其中所述第一计算装置使用所述种子生成所述秘密数，并使用所述秘密数计算与第二计算装置进行安全通信时的使用的密钥， 这样第三计算装置基于所述秘密数重新计算所述密钥，以便在所述第一计算装置和所述第二计算装置不知情的情况下拦截所述第一计算装置和所述第二计算装置之间的通信。
【文档编号】H04L9/08GK103493427SQ201280019692
【公开日】2014年1月1日 申请日期:2012年4月3日 优先权日:2011年4月22日
【发明者】G·S·桑达拉姆, S·B·米兹科夫斯基 申请人:阿尔卡特朗讯公司