首页> 中国专利> 根据公开密钥发现用于密钥管理的安全关联

根据公开密钥发现用于密钥管理的安全关联

摘要

本发明公开了用于在通信环境中形成可发现的安全关联和用于合法地发现在通信环境中形成的安全关联的技术。例如,一种用于在第一计算设备和第二计算设备之间形成可发现的安全关联的方法包括以下步骤。所述第一计算设备从密钥关联实体获得:(i)分配给所述第一计算设备的第一私有密钥,第一私有密钥与关联于所述第一计算设备的第一公开密钥在计算上相关联;和(ii)分配给所述第一计算设备的第一根密钥。第一计算设备选择第一随机值并且生成第一现时值,其中所述第一现时值是使用所述第一根密钥对所述第一随机值进行加密的结果。第一计算设备基于第一随机值生成第一密钥组件。第一计算设备使用基于身份的加密过程、用与所述第二计算设备相关联的第二公开密钥加密所述第一现时值和所述第一密钥组件,并且向所述第二计算设备发送加密的第一现时值和加密的第一密钥组件,以便与所述第二计算设备建立安全关联。安全关联可由第三计算设备发现,其中所述第一计算设备和所述第二计算设备不知道所述安全关联。

著录项

  • 公开/公告号CN103534975A

    专利类型发明专利

  • 公开/公告日2014-01-22

    原文格式PDF

  • 申请/专利权人 阿尔卡特朗讯公司;

    申请/专利号CN201280022167.7

  • 发明设计人 V·卡库莱夫;S·B·米兹科夫斯基;

    申请日2012-04-27

  • 分类号H04L9/08;

  • 代理机构北京市中咨律师事务所;

  • 代理人张潇

  • 地址 法国巴黎

  • 入库时间 2024-02-19 23:32:30

法律信息

  • 法律状态公告日

    法律状态信息

    法律状态

  • 2016-09-07

    授权

    授权

  • 2014-02-26

    实质审查的生效 IPC(主分类):H04L9/08 申请日:20120427

    实质审查的生效

  • 2014-01-22

    公开

    公开

说明书

本申请要求以2011年5月11日提交的、序号为61/484,868并且发明 名称为“根据公开密钥的用于密钥管理方案的合法监听方法”的美国临时 专利申请的优先权,通过引用的方式将其公开的全部内容包含于此。

技术领域

概括地,本发明涉及通信安全,并且更具体地,涉及用于在通信环境 中发现安全关联(security associations)的技术以在信息的合法监听中使 用。

背景技术

因特网协议(IP)通信和电话系统已经获得广泛的采用。在两个客户 之间的端到端IP通信的第一示例中的一个示例包括即时消息传送(Instant  Messaging),但是这紧接着跟随基于IP的语音(Voice-over-IP),并且 现在许多提供商(例如,网络运营商和应用提供商)提供端到端基于IP 的视频(Video-over-IP)。然而,这些趋势主要被限制于有线固定网络, 假定无线移动网络接入已经由窄带电路交换接入网络统治。然而,最近部 署的宽带4G(第四代,fourth generation)无线网络为所有形式的基于IP 的多媒体端到端通信做好了准备,而不依赖于其接入类型。

随着向端到端IP会话的转变,市场已经见证了对这些开放IP网络上 的安全和隐私的意识和兴趣的复苏。首先,端到端加密和认证是获得广泛 关注的范例。目前,虽然当前包括商业和企业内联网接入的互联网事务处 理已经超过十几年做到端到端安全,但是使基于IP的会话应用安全已经被 大部分留给应用提供商,例如,SKYPETM(位于卢森堡的Skype技术S.A. 的商标)。

随着全IP网络的到来,对于网络运营商或其他提供语音、视频、和消 息传送服务的运营商来说,提供端到端的安全且遵从支持合法的或法定的 安全关联(security associations)的监听和发现的要求将变得越来越必要。 用于法律实施目的,或简单地用于一些非法律实施目的,这种法定的安全 关联的监听和发现可能是必须的,其中能够容易地解密在主体(parties) 和/或设备之间传送的加密信息是必需的或希望的。

发明内容

示例实施例提供用于在通信环境中形成可发现的安全关联的技术,以 及用于在通信环境中形成合法地发现安全关联的技术。

例如,在一个示例实施例中,一种用于在第一计算设备和第二技术设 备之间形成可发现的安全关联的方法,包括以下步骤。所述第一计算设备 从密钥管理实体获得:(i)分配给所述第一计算设备的第一私有密钥 (private key),所述第一私有密钥与第一公开密钥(public key)计算地 关联,所述第一公开密钥与所述第一计算设备相关联;以及(ii)分配给 所述第一计算设备的第一根密钥(root key)。所述第一计算设备选择第 一随机值并且生成第一现时值(nonce),其中所述第一现时值是使用所述第 一根密钥对所述第一随机值进行加密的结果。所述第一计算设备基于所述 第一随机值生成第一密钥组件(key component)。所述第一计算设备使用 基于身份的加密过程利用与所述第二计算设备相关联的第二公开密钥将所 述第一现时值和所述第一密钥组件加密,并且将加密的第一现时值和加密 的第一密钥组件发送到所述第二计算设备,以便与所述第二计算设备建立 安全关联,其中所述安全关联能够由第三计算设备发现,所述第一计算设 备和所述第二计算设备不知道所述第三计算设备。

在另一示例实施例中,一种用于发现在第一计算设备和第二计算设备 之间形成的安全关联的方法,包括以下步骤。第三计算设备获得在所述第 一计算设备和所述第二计算设备之间传送的一个或多个消息。利用与所述 第二计算设备相关联的私有密钥的知识的所述第三计算设备,对来自所述 第一计算设备的一个或多个获得的消息中的至少一个进行解密并且获得: (i)由所述第一计算设备生成的第一密钥组件;以及(ii)由所述第二计 算设备生成的现时值,所述现时值是对由所述第二计算设备选择的随机值 进行加密的结果,使用唯一地分配给所述第二计算设备的根密钥进行所述 加密。利用所述第二计算设备的根密钥的知识的所述第三计算设备,解密 所述现时值以便获得由所述第二计算设备所选择的随机值。利用由所述第 二计算设备选择的所述随机值和由所述第一计算设备生成的所述第一密钥 组件的知识的所述第三计算设备,发现在所述第一计算设备和所述第二计 算设备之间建立的所述第一计算设备和所述第二计算设备不知道的安全关 联。

此外,示例实施例使用特别适用于,但不限制于,依靠密钥管理的公 开密钥方法的系统的技术为端到端加密会话提供合法地发现安全关联的方 法,包括但不限制于密钥和其它加密数据。例如,可依照实现不对称的相 互认证的密钥交换和/或基于迪菲-赫尔曼(Diffie-Hellman)的任何密钥 交换的系统和协议来使用实施例。特别地,虽然满足各种遵从性要求,但 是所提出的覆盖(overlay)过程是不可检测的。应当了解的是,虽然实施 例特别适合于因特网协议多媒体子系统(IMS)环境,但是这样的实施例 不旨在被这样限制。也就是说,实施例通常适用于任何合适的希望提供合 法的安全关联发现特征的通信系统。仅通过示例的方式,另一种通信系统 (其中这样的技术可被应用)是基于IMS信令框架或任何其它信令框架的 电话会议系统。

这些以及其它的目标、特征和优势从以下结合附图阅读的示例性实施 例的详细描述中将显而易见。

附图说明

图1示出基于客户端的密钥传递方法。

图2示出网络协助的密钥传递方法。

图3示出基于身份的认证密钥交换方法。

图4示出根据实施例的用于合法发现包括现时值交换的会话密钥的方 法。

图5示出根据实施例的用于合法发现包括现时值交换的会话密钥的呼 叫流程。

图6示出根据实施例的用于在电话会议环境中合法发现包括现时值交 换的会话密钥的方法。

图7示出适合实施根据实施例的方法和协议中的一个或多个的数据网 络和通信(计算)设备的通用硬件结构。

具体实施方式

本文所使用的短语“多媒体通信系统”通常定义为能够通过媒体平面 传输一种或多种类型的媒体的任何通信系统,媒体包括但不限制于,基于 文本的数据、基于图形的数据、基于语音的数据和基于视频的数据。

本文所使用的短语“媒体平面”通常定义为所述多媒体通信系统的功 能部分,依靠该功能部分在呼叫会话中可在两个或多个主体之间交换所述 一种或多种类型的媒体。这与“控制平面”形成对比,“控制平面”是所 述多媒体通信系统的功能部分,为了建立呼叫会话依靠该功能部分来执行 呼叫协商/调度。本发明的技术可使用的媒体平面应用的示例包括但不限制 于,基于IP的语音(VoIP)、即时消息传送(IM)、视频/音频IM、视 频共享、和基于IP的视频。应当理解的是,所述媒体平面包括应用层业务。 然而,本文所描述的合法安全关联发现技术可被应用于通信系统的任何平 面或任何层。

本文所使用的术语“密钥”概括地定义为为了例如,但不限制于,实 体认证、隐私、消息完整性等目的加密协议的输入。

本文所使用的短语“安全关联”概括地指通信环境中的安全定义,其 中两个或多个主体和/或设备可通过通信环境进行通信。在一个示例中,所 述安全定义可包括但不限制于,会话密钥。

本文所使用的“客户端”概括地可指通信设备或某种其它的计算系统 或设备,其允许一个或多个用户、主体或实体在通信环境中与一个或多个 其它的通信设备或其它的计算系统(例如另一个客户端)通信。本文所使 用的“客户端”也可概括地指计算设备上的应用或其它的计算机程序。因 此,虽然下面可将所述术语客户端称为设备,但是应当理解所述术语客户 端不限制于硬件而是可以是软件,或及其组合。

本文所使用的“通信会话”概括地指为了在两个通信设备之间通信的 目的在至少所述两个通信设备或其它的计算系统(例如客户端)之间的连 接。因此,本文所使用的“端到端”通信会话概括地指从一个设备(例如 客户端)到另一个设备(例如客户端)的整个连接路径。此外,参与所述 通信会话的两个或多个客户端可称为“端点设备”或简称“端点”。然而, 本文所描述的合法的安全关联发现技术可被应用到任何计算或通信设备, 并且不仅仅应用于客户端。

本文所使用的“应用”(或“应用程序”)概括地指一个或多个计算 机程序,当所述计算机程序被执行时,所述计算机程序执行一个或多个给 定的功能。

本文所使用的术语“合法的”概括地定义为满足一个或多个遵从性要 求或与政府或私有权威实体相关联的准则。这样的权威实体可作为法律实 施功能或非法律实施功能。也就是说,所述术语合法的不是为了限制于法 律实施而是在非法律实施的意义上也可包括遵从。

为方便起见,详细描述分为如下:部分I描述可以应用示例实施例的 示例性用例和提供商;部分II描述现有的端到端密钥管理方法。部分III 描述现有的密钥解决(key resolution)方法;部分IV描述在因特网协议 (IP)多媒体子系统(IMS)环境的上下文中根据示例实施例的合法的安 全关联发现解决方案;部分V描述根据示例实施例的用于实现一种或多种 合法的安全关联发现方法的示例性计算系统。

I.示例性用例和提供商

此处所描述的示例性用例(示例实施例可应用于所述用例)包括端到 端加密的客户端到客户端的通信会话。仅通过示例的方式,并且不是以任 何方式限制,这样的用例包括:

1.基于文本的IM或即时消息传送应用。

2.基于因特网协议端到端的多媒体消息传送应用(包括音频和/或视 频)。

3.通过多种分组交换接入网络的基于IP的语音。

4.通过多种分组交换接入网络的基于IP的视频。

5.包括一组参与者的文本和多媒体应用的会议。

这些示例性用例也同样适用于各种提供商。通过示例的方式,可将提 供商分成三类:

1.服务提供商可以是企业(其中信息主管或CIO控制所述应用的迁 出、管理和运行)。需要注意的是企业可以是公司或政府实体。

2.服务提供商可以是应用提供商(例如,Skype、Googletalk等)并 且在网络和类型之间将这样的服务提供为“在上层”。

3.服务提供商可以是网络提供商(例如,Verizon无线、AT&T、 Sprint、T-Mobile、Vodafone等)。

依照示例实施例所描述的问题和解决方案的示例性范围同样适用于所 有提供商并且特别是不清楚端到端通信类型或应用的提供商。

II.端到端密钥管理

假定端到端IP会话,并且希望提供安全端到端,已经设计了多个端到 端密钥管理方案。通过示例的方式,可将大部分这样的方案分成三类:(1) 基于客户端的密钥传递协议;(2)网络协助的密钥传递协议;以及(3) 不对称相互认证的密钥交换协议。

(1)基于客户的密钥传递协议。如在图1的协议100中所示,被称为 “发起者”(例如,发起特定通信会话的客户端)的客户端设备102-I使 用现有的逐跳(hop-by-hop)的安全消息传送方案,其可用于使信令安全 以便通过一个或多个网络元件104-1、104-2将“安全密钥”传递到被称为 “响应者”的客户端设备102-R(例如响应于所述特定通信会话的发起者 的客户端)。然后,在所述通信会话中的端点,即发起者和响应者,使用 所述密钥(或其派生)来确保会话安全。在图1中所示的示例基于会话描 述协议(SDP),SDP是用于为安全实时传输协议协商密钥的协议,参见 例如2006年7月的互联网工程任务组(IETF)请求注解(RFC)4568会 话描述协议(SDP)的“用于媒体流的安全描述”,其公开的全部内容通 过引用被包含于此。在这种情况下,客户端102-I通过网络(端到端)向 客户端102-R发送包括安全密钥的SDP提议(offer),并且客户端102-R 用也包括安全密钥的SDP应答(answer)来响应,由此建立了用于确保与 所述特定会话相关联的通信的安全的密钥对。容易看到的是,当设置所述 会话时,包括在传递所述安全密钥中的所有主体具有访问所述密钥的全部 权限,并且因此知道两个客户端之间会话的秘密。

(2)网络协助的密钥传递协议。如在图2的协议200中所示,在提供 商网络中(或数据中心),客户端设备202-I(发起者)为给定的会话从服 务器204(密钥管理服务器或KMS)请求密钥,紧接着从该服务器204向 发起者递送该密钥和该密钥的“指针”(以票据或令牌的形式)。然后, 发起者使用可用于使信令安全的现有的逐跳安全消息传送方案与客户端设 备202-R共享“指针”,随后所述响应者通过向所述服务器204提供该“指 针”来从该服务器204获得密钥。这样的网络协助协议的两个示例包括: 2005年7月的IETF RFC4120,“Kerberos网络认证服务”中所描述的 Kerberos系统,和2011年3月的IETF RFC6043“在多媒体互联网密钥 交换中密钥分发的基于票据模式”中所描述的MIKEY-票据系统,其公开 的全部内容通过引用的方式被包括于此。应当了解的是,所述KMS具有 安全密钥的全部知识,并且因此知道两个客户端之间会话的秘密。

(3)使用不对称公开密钥协议的认证密钥交换。在这种类型的协议中, 发起者和响应者每个都拥有密钥(私有或公开)对。典型的示例包括使用 它们的私有密钥来认证而公开密钥来彼此寻址,以及用于密钥交换的公开 密钥。图3的协议300示出IBAKE(基于身份的认证密钥交换)协议以及 不对称公开密钥方法的使用。所述IBAKE协议在2009年2月17日提交 的序号为12/372,22的美国专利申请中被描述,其公开的全部内容通过引 用的方式被包含于此。

如在图3的协议300中所示,IBAKE协议定义在两个端点:发起者A (客户端302-A)和响应者B(客户端302-B)之间的相互认证和密钥交换。 发起者和所述响应者每个都有一对密钥,即,他们各自的公开和私有密钥。 如同用公开密钥加密的情况,公开密钥被用于加密并且所述私有密钥被用 于解密。标准的公开密钥方法和基于身份的公开密钥方法之间的基本差异 是:在后面的方法中,公开密钥对应于所述“身份”并且相应的私有密钥 由信任的服务器(被称为密钥管理服务器或KMS)生成。

示例性协议的主要概念是发起者和相应者彼此认证并且使用由所述密 钥管理服务器(未示出)提供的私有密钥生成会话密钥并且使用交换的密 钥组件生成会话密钥,但是该服务器不能确定该会话密钥。

参见图3,发起者A选择随机秘密“x”并且在向所述响应者B发送 “xP”前计算“xP”值(其中P是有限域上的椭圆曲线上的点)。类似地, 响应者选择随机秘密“y”并且在向所述发起者A发送“yP”前计算“yP” 值。使用“x”和“yP”,发起者计算“xyP”。类似地,使用“y”和“xP”, 所述响应者计算“xyP”。这样允许两个主体在用于所述通信会话的密钥 上达成一致。然而,密钥管理服务器(KMS)有访问“xP”和“yP”的权 限但是不能计算“xyP”。

应当意识到的是,在所有上述列举的(三个)密钥传递/交换协议中, 不依赖于所述通信类型或提供商,有监管和/或遵从性要求,所述提供商通 过监管和/遵从性要求可合法地要求发现和共享所述端到端安全密钥(称为 “合法的发现”)。

对协议类型1和2来说,这种要求可相对容易地被满足。在协议类型 1中(图1),感兴趣的安全密钥在具有逐跳保护的网络节点之间被传输, 并且因此被包括在所述传输中的所述网络节点(例如,图1的网络元件 104-1、104-2)所知。在协议类型2中(图2),会话密钥由服务器(例如, 图2的KMS204)生成并且因此对提供商来说是可获得的。

但是对协议类型3(图3)来说,当提供商仅是所述密钥管理事务处理 的使能者(enabler)但不是在该事务处理中的参与者时,这种合法的发现 问题是特别富有挑战的。简言之,问题是发现端到端安全密钥,特别是当 不对称公开密钥协议用于端到端密钥管理时。此外,在通信会话期间,这 样的发现是需要不显眼的并且无法察觉的。

III.不对称公开密钥协议中的密钥解决方案

这部分描述在不对称公开密钥协议中用于端到端密钥管理的密钥解决 方案的现有方法。

(1)通用协议描述

这里我们特别关注于使用迪菲-赫尔曼类型的密钥交换协议(参见, 例如1999年6月的IETF RFC2631“迪菲-赫尔曼密钥协商方法”,其 公开的全部内容通过引用的方式被包含于此)。如由迪菲(Diffie)和赫尔 曼(Hellman)在他们里程碑式论文(W.Diffie,M.Hellman,“密码学 中的新方向(New Directions in Cryptography)”,信息理论的IEEE事 务处理(IEEE Transactions on Information Theory),第IT-22卷,1976 年11月,第644–654页,其公开的全部内容通过引用的方式被包含于此) 中经典地描述通过在有限域的乘法群上对素数p求模来描述所述协议。然 而,公知的是,迪菲-赫尔曼协议可被扩展值任何组,但是协议的安全依 赖于组的属性。

在这个协议中,两个端点(A和B)中的每个公开地选择已知的值以 用于G(生成元)和P(大素数),使得G是非零整数的乘法群对大素数 P求模的生成元。

为执行所述协议,A选择随机秘密x并且计算a=G^x(mod P)。类似地, B选择随机秘密y并且计算b=G^y(mod P)。应当理解的是,秘密x和y是 小于P的随机正整数。

然后,A向B发送值a,并且B向A发送值b。

当接收到值b时,A计算k=b*x(mod P),类似地,当接收到值a时, B计算k=a*y(mod P)。容易看到的是,k=(a)*y(mod P)=(b)*x(mod P), 并且k是相互计算的公共会话密钥。

(2)迪菲-赫尔曼在IBAKE中的特殊使用

IBAKE协议(在图3中所示)使用有限域上的椭圆曲线上的点的组, 并且因此依赖于有限域上的椭圆曲线中的点的组上相应的迪菲-赫尔曼问 题。每个端点(例如,A)有已知的公开身份,该身份可由任何其它的端 点(例如,B)使用以便创建用于A的公开密钥(PUB_A)。类似地,知 道了B的公开身份,任何其它的端点能够创建PUB_B。

偶尔地并且周期性地,每个端点(例如,A)联系特定的基于网络的 功能、密钥管理服务器(KMS),并且接收与相应的公开密钥(PUB_A) 计算地相关联的特别计算的私有密钥(例如,PR_A)。类似地,其它端 点执行同样的动作。因此,每个端点持有公开-私有密钥对,尽管所述公开 密钥是基于端点的身份。

为执行所述协议,每个端点选择随机的秘密数。假设x是由A选择的 随机数,并且假设y是由B选择的随机数。

在第一步骤中,A计算xP,其中P在椭圆曲线E上公开已知的点(即, 使用加法定律将P自加x次),使用B的公开密钥PUB_B加密xP并向B 发送。在这个步骤中,加密是指在Dan Boneh,Matthew K.Franklin的“来 自Weil配对的基于身份的加密(Identity-Based Encryption from the Weil  Pairing)”,高级密码学(Advances in Cryptology)-CRYPTO2001会议 (2001),以及在IETF RFC5408和5409中所描述的基于身份的加密, 其公开的全部内容通过引用的方式被包含于此。

当接收到已加密的消息时,B解密该消息并且获得xP。

随后,B计算yP,并且使用A的公开密钥PUB_A加密{xP,yP}对, 并且然后将其发送给A。

当接收到这个消息时,A解密该消息并且获得yP。随后,A使用B的 公开密钥加密yP并且将它发送回B。

此后,A和B都计算k=xyP作为会话密钥。更具体地,A通过将接收 并且解密的yP加到自身x次来计算k=xyP。类似地,B通过将接收的并且 解密的xP加到自身y次来计算k=xyP。

(3)用于会话密钥的合法发现的中间人密钥解决方案

典型并且众所周知的用于迪菲-赫尔曼密钥交换的密钥发现方法是基 于所谓的“中间人”(MitM)方法。在这种方法中,活跃的中间人C将 其自身放置在端点A和B之间的通信链路中。中间人C向A呈现自己是 B,并且向B呈现自己是A。

中间人C创建它自己的秘密,x’和y’。当C从A接收到a时,C用 b’=G^y’(modP)响应,并且类似地向B发送a’=G^x’(modP)。

当该交换完成时,A和C生成k1=(G^x(modP))*y’(mod P)= (G^y’(modP))*x)(mod P),而C和B生成k2=(G^x’(modP))*y(mod P)= (G^y(modP))*x’(mod P)。因此,通过与A和B维护两个独立的安全会话, 活跃的中间人C能够解密和重新加密A和B之间的通信。

然而,对一些复杂的端点设备来交换代表相互计算的密钥的图像或者 签名,并且意识到它们实际上计算两个不同的密钥是可能的。这将导致所 述MitM功能的发现,其中不希望在合法的发现会话密钥中发现MitM功 能。

(4)通过强制创建秘密的密钥解决方案

另一种方法强制端点中的至少一个(例如,A)来创建秘密(x),其 中(x)也被包括在会话密钥的合法发现中的复杂网络节点所知。在这种方 案中,端点A不选择秘密x,而是等待网络来发送特定参数,例如现时值 (N),并且然后将该现时值连同另一个与该网络共享的秘密(S)一起哈 希(hash)。因此,端点A和特定的网络节点都生成x=H(S,N)。随后,这 个生成的x在迪菲-赫尔曼交换中被用作指数。

可以容易看到的是,特定的网络节点能够计算k=(G^y(modP))*x(mod P),并且因此知道A和B之间的通信链路的秘密密钥。

然而,通过期望接收鲜值,端点设备完全感知为合法地发现所述会话 密钥的所述网络的存在和目的,这是极其不期望的。特别地,这种密钥发 现解决方案在通信会话期间是可由合谋的端点设备检测的,并且此外只要 有合谋的端点设备就能工作。

(5)到托管服务器的密钥传递

另一种方法是基于从网络节点发送到端点设备的特别的请求。这个请 求强制所述端点设备将用于加密A-B通信链路的计算的密钥k或密钥k的 派生上载到基于网络的密钥托管数据库。这种上载通常在具有建立在端点 和密钥托管(escrow)数据库之间的安全隧道的保护下完成。

然而,接收这样的请求的端点设备清晰地知道密钥托管数据库的存在, 并且因此为了合法发现会话密钥目的的可能监听安全通信是不期望的。

(6)通过“随机秘密”的重新生成的密钥解决方案

在2011年4月29日提交的、发明名称为“安全关联的发现”的美国 专利申请第13/097,184号中所描述的方法中,该专利申请公开的全部内容 通过引用的方式被包含于此,密钥发现问题依靠在通信会话中发现至少一 个参与者的“随机秘密”的提供商。特别地,所述方法工作如下。提供商 在客户端应用中嵌入伪随机数生成器(PRG)。运营商或应用拥有者,例 如企业,利用与客户端身份相关联的秘密数随机种子(S)来预先配置所 述应用。这个随机种子通常是随机数或,更具体地是包括至少一个随机数 的一组数。这种关联,即种子和身份,被存储在由运营商或应用拥有者(例 如企业)管理的服务器中。当应用需要生成用于会话(例如,x)的随机数 以便执行密钥交换协议,例如迪菲-赫尔曼、IBAKE、等等时,调用PRG。 PRG使用种子和确定性的和单调增加的量,例如时间戳或外部管理的计数 器(C),来生成所需的伪随机值x。一旦合法的监听被授权,在网络中的 监听实体从其他网络节点请求所有的必需信息,而不是从所述端点自身。 因此,端点没有意识到尝试的监听。虽然这种方法是不可检测的,但是在 网络中该方法包括额外的实体(即,企业服务器)以及在所述客户中包括 特别的软件来生成/重生成所述“随机秘密”。

IV.改进的合法安全关联发现

依照示例性实施例,提供密钥发现问题的解决方案,该方案在通信会 话期间依靠在所述两个客户端设备(端点)之间的常规消息交换期间所交 换的现时值。特别地,所述方法(其将在以下更详细地被描述)工作如下。

如在图4的基于IBAKE的协议400中所示,当端点(例如,402-A) 联系KMS(在图4中未明确示出),并且接收特别计算的私有密钥(例 如,PR_A)时,该私有密钥与相应的公开密钥(PUB_A)计算相关联, KMS也包括每个用户的根密钥(RK_A)。这个根密钥只被所述KMS和 请求所述私有密钥的所述端点用户所知。如上述关于图3的基于IBAKE 协议所描述的,一旦端点A(这里402-A)需要执行该协议,端点A选择 随机秘密x。随后,端点A使用RK_A和这个随机秘密x生成A_Nonce。 换句话说,依照示例性实施例,A_Nonce代表随机秘密数x的加密值。用 于生成A_Nonce的示例性方法如下:

A_Nonce=AESRK_A(x)

其中AES是由美国国家标准技术研究院(NIST)于2001年11月26日发 布于FIPS PUB197所指定的高级加密标准算法,其公开的全部内容通过 引用的方式被包含于此。

端点A(402-A)随后将这个A_Nonce包括在向端点B(在图4中消 息1)发送的第一消息中。类似地,B(402-B)选择y并且生成B_Nonce (B_Nonce=AESRK_B(y))并且将接收的A_Nonce和这个生成的B_Nonce 包括在向A发送(在图4中消息2)的消息中。

最后,端点A(402-A)将所述接收的B_Nonce包括在第三消息中(在 图4中消息3)。经由消息4来执行验证。

应当了解的是,对于每个端点,从相应的端点接收的现时值的值与所 述随机数是不可区别的,并且因此它被当作既不需要处理也不需要识别的 现时值。

一旦合法的监听被授权,网络中的监听实体(在图4中未明确示出) 从KMS请求所有必需的信息(即,私有密钥和根密钥),其中通信会话 中涉及的端点客户端不知道所述必需的信息。然后,监听实体使用所述接 收的根密钥来获得随机秘密,并且然后,使用获得的随机秘密和在迪菲- 赫尔曼交换中交换的剩余密钥组件,监听实体生成会话密钥。

通常,基于迪菲-赫尔曼的协议的保密性依赖于客户端自己拥有的随 机秘密和由相应的端点从其自己拥有的随机秘密所生成的组件的值的客户 端知识。在图4所示的示例中,端点A(402-A)创建并且为随机数x保 持秘密,且端点B(402-B)创建并且为随机数y保持秘密。端点中的每个 处理他们各自的随机秘密,具体地将该数乘以代表在椭圆曲线上的点的P 的值。该结果值xP和yP通过端到端信令来交换。xP和yP两者的知识不 能帮助重新创建表示为xyP的期望的会话密钥。但是,知道它自己拥有的 秘密(A的x以及B的y)的每个端点,能够计算期望的会话密钥。对于 端点A,会话密钥为k=x*yP,以及对于所述端点B该密钥为k=y*xP。

例如,假设在图4中端点B(402-B)作为监听的目标。因此,法律实 施监视代理节点(LEMF)从KMS获得RK_B和PR_B。一旦B参与通 信,通信网络节点(例如,P/S-CSCF)监听并且向LEMF(监听服务器) 报告IMS消息事件。备选地,LEMF能够在不使用P/S-CSCF的情况下直 接监听在端点之间发送的所述IMS消息事件。需要注意的是,SIP指会话 发起协议(IETF RFC3261,其公开的全部内容通过引用的方式被包含于 此)并且P/S-CSCF指代理或者服务呼叫会话控制功能。LEMF从监听的 IMS信令提取与加密(即,xP和B_Nonce)相关的信息,并且使用这个 提取的信息和RK_B和PR_B,LEMF解密消息并且生成会话密钥k=xyP。

具体地,在这个示例中,LEMF将处理交换的消息1(图4)。知道 端点B的私有密钥(PR_B)的情况下,LEMF将解密IBE加密的有效载 荷,该IBE加密的有效载荷最初由端点A用B的公开密钥(PUB_B)来 加密。LEMF将从这个有效载荷中获得xP值。然后,LEMF将处理交换 的消息3(图4)。知道所述PR_B的情况下,LEMF将解密IBE加密的 有效载荷,该IBE加密的有效载荷最初由端点A用B的公开密钥(PUB_B) 进行加密。LEMF将从这个有效载荷中获得B_Nonce值。然后,LEMF 将使用已知的RK_B来解密B_Nonce值,并且获得值y。最后,知道xP 和y的情况下,LEMF将生成会话密钥为k=x*yP。

需要注意的是,LEMF从其它的网络节点请求所有必需的信息,而不 是从端点本身。因此,端点没有意识到尝试的监听。此外,这种信息交换 (其中监听实体从KMS获得信息)在通信会话的实际开始前可被执行任 何次数。这样显著地降低与网络元件之间所需的协调相关的复杂性。

现在参照图5,示出根据图4的基于IBAKE的实施例的用于合法发现 包括现时值交换的会话密钥的示例性呼叫流程。需要注意的是,为便于理 解和一致性,使用相同的附图标记对所述呼叫流中如在图4中所示端点元 件(402-A和402-B)进行编号,并且监听实体被示为监听服务器502并 且KMS被示为KMS服务器504。也需要注意的是,本发明描述的合法安 全关联发现技术不限制于使用任何的特定协议,并且因此在这个实施例中 基于IBAKE协议被用作示例的目的。

如在图5中所示,如以上在图3的上下文中所描述的,步骤1、2和3 代表端点A(402-A)和端点B(402-B)之间交换的典型IBAKE协议。 步骤4是验证消息。如果A或者B的目的是合法监听,那么监听服务器 502监视并且记录这些信令事务处理。

在图5的步骤5和6中,监听服务器502(其是以上在图4的说明中 所描述的LEMF)从所述KMS504请求用于监听目标(例如,B)的私有 密钥(或多个私有密钥)和根密钥。这个事务处理可在实际的IBAKE事 件之前被完成。在这种情况下,当A和B开始通信时,在监听服务器502 处所述目标的(多个)私有密钥和根密钥已经可获得。

备选地,监听服务器502在端点之间将消息的全部拷贝提供给KMS, 并且希望具有用于目标端点的所有所需的秘密参数的知识的KMS,使用 相同的技术得到会话密钥并且将会话密钥向所述LEMF返回。

因此,当与在上述引用的序号为13/097,184的美国专利申请所描述的 方法相比时,在图4和5的上下文中所描述的本发明的基于现时值的解决 方案有利地不包括企业服务器,在客户端中也不包括的特定软件以生成/ 重新生成所述“随机秘密”。

因此,简而言之本发明所详细描述的内容,以上在图3中所描述的 IBAKE协议中,当第一客户端(端点)从第二客户端(端点)接收yP时, 第一客户不需要知道y。第一客户端只需要将接收到的yP乘以第一客户知 道并且保密的x。对第二客户端同样也是如此,即,当第二客户端接收xp 时,第二客户只需将xP乘以第二客户知道并且保密的y。在两边的这种乘 法的结果是xyP,xyP是会话密钥(也称为安全关联)。

也就是说,在IBAKE协议中,在IBE加密下xP和yP在两个方向上 进行交换。第一客户端使用第二客户端的公开密钥加密xP。只有第二客户 端能够对xP进行解密,这是因为只有第二客户端具有相应于其公开密钥 的私有密钥。类似地,第二客户端通过使用第一客户端的公开密钥的IBE 加密来向第一客户端发送密钥组件yP。只有第一客户端能解密yP,这是 因为第一客户端有相应于其公开的公开密钥的私有密钥。当两个客户端向 彼此返回所接收的密钥组件时,他们隐含地认证对方。

有利地,本发明所描述的示例性实施例提供在IBAKE协议(如在图4 和5中所示)中现时值的使用。也就是说,当第一客户端将它的密钥组件 xP向第二客户端发送时,第一客户端也发送随机秘密x的加密值。这就是 上述所指的A_Nonce。类似地,当第二客户端将它的密钥组件yP向第一 客户端发送时,第二客户端也将该密钥组件与它自己拥有的随机秘密y的 加密值伴随在一起。换句话说,在本发明的协议中,基于这个随机秘密, 随机秘密的加密值伴随在密钥组件中,并且这种结合总是通过使用相应的 对端的公开密钥进行IBE加密。

因此,为了恢复会话密钥,监听器经历两种级别保护:(1)为了解密 包括密钥组件和相关联的现时值的“密钥胶囊(keying capsule)”,以及 为了接收来自相应节点的其它密钥组件,获得目标的私有密钥;以及(2) 解密与目标的随机秘密相关联的现时值,即恢复随机秘密自身。在具有随 机秘密或目标和其它相应客户端的密钥组件的情况下,监听器能够复制会 话密钥。

我们现在转向群设置(group setting),例如电话会议环境。在电话 会议中,一群参与者交换密钥资料并且商定群密钥。特别地,迪菲-赫尔 曼密钥交换已经被扩展到群设置(参见,例如,Burmester和Desmedt的 “安全和有效的会议密钥分配系统(A secure and efficient conference key  distribution system)”,94年欧洲加密(Eurocrypt)会议录第LNCS的 950卷,第275-286页,Springer1995,其公开的全部内容通过引用的方 式被包含于此),并且此外IBAKE已经被扩展到在群设置中处理认证密 钥交换(参见,例如,2009年8月28日提交的序号为12/549,907的美国 专利申请,其公开的全部内容通过引用的方式被包含于此)。需要注意的 是,在这个示例中,短语“群设置”指多于两个的用户的群,并且协议允 许所有用户在不安全的环境中交换信息并且交换如适用于,但不限制于, 会议系统的“群密钥”。

图6示出根据实施例的用于在电话会议环境中合法的发现包括现时值 的会话密钥交换的方法600。特别地,图6示出使用IBAKE的群密钥交换。 在这个设置中,中央协调服务器604(被称为会议安全服务器或会议服务 器)认证并且授权每个用户(设备602-1到602-N)来参加群密钥交换。 然而,中央协调服务器604不知道从IBAKE计算得到的群密钥。但是, 由于遵从性和其它管控要求,会议提供商通常需要发现群密钥。

如图所示的,每个用户单独地与会议服务器执行IBAKE。这允许服务 器来确保在呼叫中只有认证和授权的参与者被允许。随后,服务器在呼叫 中与每个参与者共享迪菲-赫尔曼密钥组件,因此允许每个参与者计算另 外的密钥组件并且与其余的参与者(通过服务器)共享。使用初等群论, 可以容易看出,所有参与者能够计算相同的群密钥但是会议服务器将不能 够确定密钥。协议在图6中示为606。

如上所述,基于现时值的合法的密钥发现技术也可以按简单的方式被 扩展为这种设置。依照这样的实施方式,应当了解的是,与参与者相关联 的现时值如此处所阐述地被生成并且伴随由参与者生成和传送的密钥组 件。

因此,在电话会议设置的开始时,每个参与者与会议服务器604交换 IBAKE信令。LEMF监听目标和会议服务器之间的这种信令并且解密由 所述目标发送的随机秘密。在第二阶段,当与会议服务器交换密钥组件时, LEMF能够完整地复制由目标自己完成的所有计算。因此,LEMF再现会 议会话密钥的准确拷贝。类似地,如果LEMF简单地将所有信令向KMS 转发,那么KMS执行该计算,并且将会话密钥向LEMF返回。

V.示例性计算系统

图7示出根据示例实施例的以适合用于在两个实体之间实施基于现时 值的安全密钥关联协议和合法的安全关联发现的计算设备形式的网络环境 和通信设备的通用硬件结构700。

虽然图7仅为两个示例性实体示出详细的子组件,但是应当理解的是, 其它实体可具有同样的配置。因此,按照上述安全密钥管理协议和合法的 安全关联发现,详细示出的两个实体可以是发起者客户端设备402-A(第 一主体或A)和响应者客户端设备402-B(第二主体或B)。然而,监听 服务器(502)、KMS(504)、功能元件、其它的客户端设备(主体)和 其它服务器可用如图7的计算设备所示的同样结构来实施。因此,通过示 例的方式,在图7中示出监听服务器720和KMS722,并且被理解为具有 如在设备702和704中所示的同样的计算结构。然而,应当理解的是,为 了简单的目的,所有可参与此处所描述的协议的计算设备(通信设备)未 在图7中示出。同样地,在会议呼叫实施方式中,会议参与者(设备602-1 到602-N)和会议服务器(604)可使用如在图7的计算设备中所示的同样 结构来实现。

如图所示,被标示为702的A的计算设备和被标示为704的B的计算 设备经由网络706进行耦合。网络可以是任何网络,其中设备能够通过该 网络进行通信,例如,如在上述所描述的实施例中,网络706可包括公开 访问的广域通信网络,例如由网络运营商(例如,Verizon、AT&T、Sprint) 所运营的移动通信网络。然而,实施例不限制于特定类型的网络。通常, 设备可以是客户端机器。参与本发明所描述的协议的主体可使用的客户端 设备的示例可包括但不限制于,蜂窝电话、智能手机、桌面电话、个人数 字助理、便携计算机、个人计算机等。还需记得的是,如上所阐述的,客 户端也可以是计算设备(例如,智能手机)上的应用。然而,设备中的一 个或多个可以是服务器(例如,监听服务器,KMS服务器等)。因此, 应当理解的是,本发明所描述的协议和方法不限制于计算系统分别是客户 端和服务器的情况,而是相反地可用于包含两个网络元件的任何计算设备。

对本领域的普通技术人员将是显而易见的,服务器和客户端可以被实 施为在计算机程序代码控制下运行的可编程计算机。计算机程序代码将被 存储在计算机可读的存储媒质(例如,存储器)中并且代码可由计算机的 处理器来执行。借助本发明公开内容,本领域的技术人员为了实施本发明 所描述的协议,能够容易地产生合适的计算机程序代码。

但是,图7为通过网络通信的各个计算机系统概括地示出示例架构。 如图所示,设备702包括I/O设备708-A、处理器710-A和存储器712-A。 设备704包括I/O设备708-B、处理器710-B和存储器702-B。应当理解的 是,本发明所使用的术语“处理器”旨在包括一个或多个处理设备,包括 中央处理单元(CPU)或其它处理电路,包括但不限于一个或多个信号处 理器、一个或多个集成电路等。此外,本发明所使用的术语“存储器”旨 在包括与处理器或CPU相关联的存储器,例如RAM、ROM、固定存储 器设备(例如,硬盘)、或可移动存储器设备(例如,磁盘或CDROM)。 同样地,存储器是计算机可读存储媒质的一种示例。此外,本发明所使用 的术语“I/O设备”旨在包括一个或多个用于输入数据到处理单元的输入 设备(例如,键盘、鼠标),以及一个或多个用于提供与处理单元相关联 的结果的输出设备(例如,CRT显示器)。

因此,用于执行本文所描述的方法的软件指令或代码可被储存在一个 或多个相关联的存储设备中,例如,ROM、固定或可移动储存器,并且, 当准备好被使用时,被装载到RAM并由所述CPU来执行。

虽然示例性的实施例已在此处参照附图被描述,但是应当理解本发明 不限制于那些精确的实施例,并且多种其它的改变和修改可在不背离本发 明的范围或精神的前途下由本领域内的技术人员做出。

去获取专利,查看全文>

相似文献

  • 专利
  • 中文文献
  • 外文文献
获取专利

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号