首页> 中国专利> 用于身份管理、验证服务器、数据安全和防止中间人攻击的动态分发密钥系统和方法

用于身份管理、验证服务器、数据安全和防止中间人攻击的动态分发密钥系统和方法

摘要

本发明提供了一种分发密钥加密系统和方法,其中密钥存储服务器通过使用唯一分发私钥对会话密钥进行加密来将该会话密钥提供给源和目的地计算机,该唯一分发私钥通过唯一私钥标识符与相应源和目的地计算机相关联。然后,目的地计算机利用其的分发私钥解密被加密的会话密钥,然后利用解密的会话密钥来解密该通信。

著录项

  • 公开/公告号CN101479984A

    专利类型发明专利

  • 公开/公告日2009-07-08

    原文格式PDF

  • 申请/专利权人 斯蒂芬·L.·博伦;安德烈·J.·布里森;

    申请/专利号CN200780023813.0

  • 申请日2007-04-25

  • 分类号H04L9/14(20060101);H04L9/28(20060101);H04L9/32(20060101);

  • 代理机构中国国际贸易促进委员会专利商标事务所;

  • 代理人魏小薇

  • 地址 加拿大不列颠哥伦比亚省

  • 入库时间 2023-12-17 22:18:57

法律信息

  • 法律状态公告日

    法律状态信息

    法律状态

  • 2019-04-12

    未缴年费专利权终止 IPC(主分类):H04L9/14 授权公告日:20110608 终止日期:20180425 申请日:20070425

    专利权的终止

  • 2011-06-08

    授权

    授权

  • 2009-09-02

    实质审查的生效

    实质审查的生效

  • 2009-07-08

    公开

    公开

说明书

技术领域

本发明涉及电子通信安全领域,尤其涉及网络扩展、验证和身份管理、检测、撤销和加密方法。

背景技术

最广泛使用的为验证和加密在线提供安全性的方法是使用公钥设计的非对称加密系统,其中验证依赖于证书服务器发放的证书。公钥基础设施(PKI)系统由于经常被不适当地实施,因此具有已知的诸如易受到中间人(MitM)攻击之类的安全弱点。

PKI系统的开销很高,这不仅因为体系结构中包含的所有步骤,而且还因为它们对密码技术的选择。PKI所使用的加密强度近来已引起质疑。公钥是复合素数(compound prime),并且它们总是可被攻击。在素数和因子分解理论中已有显著进展。存在对复合素数进行因子分解的新技术。快速计算机通过如“筛选(sieve)”方法的简化技术对复合素数进行因子分解,因此过去需要数年才能完成的工作如今可在几小时中完成。由于随着密钥变得更强(更长)而引入的额外计算开销,公钥系统使用越来越强的密钥变得越来越困难。

公钥系统的安全性成为问题有多方面的原因。证书授权中心(CA)可能并非可信赖的。计算机上的私钥可能不被保护。撤销密钥(拒绝网络访问)是困难的。撤销通常需要第三方介入。普通用户很难理解非对称系统。此外,密码密钥信息对于黑客是公开可用的。目前没有为黑客入侵和欺骗提供连续状态验证、连续状态入侵检测、以及自动拒绝网络访问的方法。

分发的加密密钥是已被使用一些人工手段预先分发给所涉及的一方的密钥,所述人工手段诸如是信件或人与人之间传递。这是确保密钥私密性的最安全的方法;然而当希望与不具有预先共享的密钥信息的各方建立新的动态会话时,这成为问题。

任何被创建以提供最高网络安全级别的拓扑结构或技术必须处理安全密钥管理、密钥创建、密钥交换、验证、检测、撤销和授权的问题。

现有技术的前述示例和与之相关的局限性是示例性的而非排他的。在阅读说明书并研究附图之后,现有技术的其他局限性对于本领域技术人员会变得清晰。

发明内容

结合系统、工具和方法描述和说明下文的实施例及其各个方面,所述系统、工具和方法为示例性和说明性的,而不限制本发明的范围。在各个实施例中,上述问题中的一个或多个被减少或消除,而其他实施例针对其他改进。

文中描述的动态分发密钥体系结构处理了前述的PKI系统的要素和缺点。在拓扑级,公开了若干种网络拓扑结构,其使用分发密钥作为随机数发生器,继而生成附加的分发密钥,并且安全地以电子方式将它们分发到额外的装置/人,以便用于可容易地扩展的网络和用于在因特网上扩展安全网络。此外,这些分发密钥可以生成供任何加密算法使用的会话密钥。虽然优选实施例使用美国专利第7190791号中公开的密钥(以后称为“白噪声密钥”)用于附加密钥生成(并且用于包括加密的全部安全功能),但是这还可以使用任何确定性随机(伪随机)数据源和任何加密算法实现。安全网络拓扑结构的采用也在某些情境中依赖于其影响现有技术的能力。因而,公开了一种混合方法,该方法使用因特网的安全套接层公钥技术来增加另一个抽象层来防止中间人攻击。

正如汽车需要和谐工作的许多不同技术组件一样,安全网络也需要若干用于有效和安全的使用和部署的组件。公开了提供状态的和连续的验证、检测和自动撤销的技术。这些组件基于使用确定性随机(伪随机)数据源来生成和比较尚未被创建且尚未被传输的密钥流(密钥输出)的各部分的能力。在数据密钥流中预先比较密钥段。如果密钥在加密状态下被递送,则发生密钥的安全传输,并且未授权的一方不能访问造成密钥流段被破解或成功猜出所需的全部信息。这还需要能够容易地管理偏移,从而每个端点知晓从密钥中的哪个位置开始密钥流段(令牌)生成。

利用动态分发密钥拓扑结构的这些特性的有效技术被提供以防止中间人攻击,提供连续验证和检测,并且通过自动撤销来保障安全。本发明使用分发密钥,但是该密钥并非像传统上那样被作为用于点对点链路的密钥,相反,该密钥被用于分发用于建立安全通信链路的初始意图的加密的“会话”密钥。分发密钥本质上不仅可用于通信流量的加密,而且还可用于对另一方的验证。这是优于PKI公钥基础设施系统之处。

网守(GateKeeper)与密钥库(Key Vault)一起工作,以创建用于TCP/UDP隧穿的动态分发密钥环境。网守基于简单的标准网络过滤器(netfilter)准则创建并加密隧道,而密钥库有利于在网守彼此对话时网守所要求的点对点密钥的取回。

简而言之,该系统当前有利于网络上的在网络之间的几乎透明的、动态的、加密点对点通信。密钥库与网守系统一起工作,以在任何基于IP的网络如因特网上创建使得通信可保持安全和保密的层。

本发明提供一种动态分发密钥系统。传统的分发密钥系统要求通过信件或亲自将密钥递送给希望与之建立安全链接的每个人。本发明克服了此阻碍。一个人可在任何时候开始与使用本发明的其他人通信,而不必等候分发密钥被递送。

因此,本发明提供一种对第一源计算机和第二目的地计算机之间的通信加密的方法,其中所述源和目的地计算机各自分别具有第一和第二私用分发密钥,所述第一和第二私用分发密钥中的每一个与第一和第二唯一私钥标识符关联,其中密钥存储服务器具有第一和第二私用分发密钥,所述第一和第二私用分发密钥中的每一个与第一和第二唯一私钥标识符相关联,所述方法包括:i)所述源计算机向所述密钥存储服务器发送对会话密钥的请求;ii)所述密钥存储服务器识别所述源计算机,并且找到其关联的私用分发密钥;iii)所述密钥存储服务器为所关心的会话生成唯一会话密钥,所述会话由唯一会话标识符标识;iv)所述密钥存储服务器用源计算机私用分发密钥对会话密钥进行加密,并将其与会话标识符一起发送到源计算机;v)所述源计算机使用所述源计算机私用分发密钥对所述会话密钥进行解密,并且使用所述会话密钥对通信进行加密,所述通信与所述会话标识符一起被发送到目的地计算机;vi)所述目的地计算机接收所述加密的通信和会话标识符,并且向密钥存储服务器发送对与会话标识符相关联的会话密钥的请求;vii)所述密钥存储服务器从所述会话标识符确定其是否具有相应的会话密钥,以及其是否具有目的地计算机的私用分发密钥;viii)如果所述密钥存储服务器从所述会话标识符确定其具有相应的会话密钥,并且具有目的地计算机的私用分发密钥,则所述密钥存储服务器用所述目的地计算机的私用分发密钥对所述会话密钥进行加密,并且将其发送到目的地计算机;ix)所述目的地计算机然后使用其私用分发密钥对所述会话密钥进行解密,并且使用所述解密后的会话密钥对所述通信进行解密。

除了上述的示例性方面和实施例之外,通过参考附图并研究以下的详细描述,其他方面和实施例也将变得清晰。

附图说明

在附图中示出了示例性实施例。在此公开的实施例和图应被认为是示意性的而非限制性的。

图1示出现有技术PKI系统;

图2示出能够使用传统计算网络而利用本发明的安全通信链路的可能的配置;

图3是示出本发明的系统的示意图;

图4是示出过程的一个组成部分的流程图;

图5是示出该过程的第二个组成部分的流程图;

图6是该过程的一个组成部分的类图;

图7是该过程的第二个组成部分的类图;

图8是根据该过程被包装的分组的示意性图示;

图9是根据该过程的头部的示意性图示;

图10是示出混合AES-白噪声过程的流程图;

图11是根据该过程的验证和身份管理配置的示意性图示;

图12是通过扰动密钥调度来创建密钥的方法的示意性图示。

具体实施方式

在下文的描述中,阐述了具体细节以便使本领域技术人员更透彻地理解本发明。然而,公知的要素可能并未详细示出或描述以避免不必要地隐蔽本公开。因此,说明书和附图应被看作是示例性的而非限制性的。

图1示出了加密Bob和Alice之间的通信的现有公钥非对称加密方法,该方法是当前最广泛使用的用于为验证和加密在线提供安全性的方法。

图2示出能够使用传统计算网络而利用本发明的安全通信链路的可能的配置。在布置10中,在网络14和16之间在因特网12上发送的所有数据被加密。在布置18中,在任何具有网守的工作站节点20之间发送的所有数据被加密。

在下文中,本发明的两个组件被称为网守和密钥库。网守是使用密钥库的点对点数据链路层隧穿系统。密钥库在网守请求密钥时将密钥提供给网守。本发明使用的优选的加密算法是美国专利第7190791号和PCT专利申请公报第WO 2005/076521 A1号中公开的白噪声超级密钥加密算法(Whitenoise Superkey Encryption Algorithm),以上两篇专利文献并入此作为参考,并且该白噪声超级密钥加密算法被使用其商标“白噪声(Whitenoise)tm”来引用。

网守和密钥库服务器可以用于从IP行进到IP——无论从计算机到计算机,还是作为替换方案,从网络到网络,或者从计算机到网络,以及有线到有线,无线到有线,以及无线到无线——的网络体系结构的任何层次。由于该系统依赖于系统之间的数据链路层,所以该系统能够在任何地方插入到网络中。一些其他加密系统依赖于应用层(SSH是其一个例子)。当使用应用级时,安全隧道是应用特定的,并且需要与希望利用它的每个应用诸如VOIP、电子邮件、或网上冲浪之类重新整合。相反,使用数据链路层使得可无延迟地与每个基于IP的应用立即整合。应用并不知晓存在隧道。

密钥库和网守应用可以单独地工作,或者组合地工作。网守隧穿系统可被独自使用,从而仅利于对于ISP、政府、使馆、或法人可能有用的传统静态点对点隧道的概念。基于允许点对点动态连接的分发密钥分发会话密钥的密钥库体系结构可被应用于除隧道以外的其他区域。这些其他区域包括确保呼叫的蜂窝电话;确保和验证电子邮件的电子邮件系统;用于军事卫星图像的流传输的卫星;如Bit Torrent的对等网络(许多ISP过滤对等网络流量,并且在这些连接上给予用户较慢的吞吐量;然而加密后的流量不能被分析)。

图3示意性地示出了该系统。每个网守工作站21、23具有与其密钥库25成对的唯一密钥。所述两个网守工作站21、23使用其被分配的密钥从密钥库请求会话密钥,所述被分配的密钥在安装时被物理地分配。接着,它们可以利用该会话密钥彼此通信。单个网守不能解密任意数据。当加密后的数据需要被解密时,只有目的地计算机可以将其解密,这是因为由于会话密钥被通过与密钥库成对的唯一密钥加密,因此只有传输中包含的两台计算机可以从密钥库获得会话密钥。

网守客户端利用其私用分发密钥创建和加密对与另一网守的会话密钥的请求,只有保持该会话密钥的密钥库具有该私用分发密钥的副本。只有此会话中包含的这两个网守可以请求会话密钥,这是因为其私钥通过密钥库验证它们的请求。

驱动安全链接的事件序列开始于发起侧的网守,继续前进到密钥库,并且最终结束于接收侧。这可以在图4和5中看出。如详细描绘网守和密钥库二者中的事件流程的图4和5所示,在建立安全的点对点通信时,这两个系统共同工作以形成分发密钥系统。网守利用现有的高速缓存的密钥通过隧道与另一网守通信,并且根据需要从密钥库取回任何需要的会话密钥。密钥库仅接收和应答密钥请求。

参照图3、4、5,源网守21具有私用分发密钥1,所述私用分发密钥1与其的唯一标识符相关联,并且被与该标识符关联地存储在密钥库25中。为了开始与网守23的加密通信,网守21向密钥库25发送对会话密钥的请求。密钥库25识别进行发送的网守21,并且找到其相关的分发密钥1。接着,密钥库25为由唯一会话标识符所标识的所关心的会话生成唯一会话密钥。然后,密钥库25用密钥1对会话密钥进行加密并将其与会话标识符一起发送到网守21。然后,源网守21使用密钥1解密会话密钥,并且使用会话密钥加密送往网守23的通信。网守23接收分组,并且判断是否需要对其解密。如果需要解密,则网守23向密钥库25发送对会话密钥的请求。密钥库25从会话标识符判断其是否具有对应的会话密钥,以及其是否具有网守23的分发密钥2。如果具有,则密钥库25利用密钥2对会话密钥进行加密,并且将其发送到网守23。然后,网守23使用其的分发密钥2对会话密钥进行解密,并且利用解密后的会话密钥对来自网守21的通信进行解密。

图6示出网守类图。网守应用可以包含一个或多个管道,每个管道包含进出分组传送器,所述进出分组传送器负责基于它们的分组处理器中的规则管理器的规则来过滤和加密这些分组,通过密钥管理器根据需要取回密钥。图7示出密钥库类图。密钥库应用具有一个主循环,其听取到来的密钥请求,并且用密钥响应来满足这些请求。

当写分组时,除非如以下那样以高级模式初始化libnet,否则函数一般不可用:

libnethandle=libnet_init(LIBNET_LINK_ADV,

conveyerinfo.destinationdevice,libneterror);

在上文代码中可看出,LIBNET_LINK_ADV的定义值被用于在数据链路层上以高级模式初始化libnet句柄。

并且当读分组时,被读回的分组的类型通过编译的“网络过滤器”样式的表达确定。

pcap_lookupnet(conveyerinfo.sourcedevice,&net,&mask,

pcaperror);

pcap_compile(pcaphandle,&compiledfilter,

conveyerinfo.filterexpression,0,net);

pcap_setfilter(pcaphandle,&compiledfilter);

在以上代码中可看出,打开了一个想要从其读取、编译、并且分配要使用的滤波器的装置的句柄。在这里将系统与IP表防火墙规则整合在一起。例如可以忽略端口21和20上的任何流量,以阻止普通的ftp服务。

在PacketProcessor类中,实际的白噪声头部被附加到“包装”的分组的末尾。“包装”意味着原始分组已被重新封装,准备被加密。此封装是为了使用隧道,这是因为封装的分组可通过加密而被破坏,而不会使分组在路由选择方面无用。

//create a UDP headers

*((unsigned short*)(packet.iphdr+packet.iphdrlength))=

htons(TUNNEL_PORT);            //src prt

*((unsigned short*)(packet.iphdr+packet.iphdrlength+

2))=htons(TUNNEL_PORT);          //dst prt

*((unsigned short*)(packet.iphdr+packet.iphdrlength+

4))=htons(UDP_HEADER_SIZE+datalength1);//lngth

udpChecksum(packet.p);

*((unsigned short*)(packet2.iphdr+packet2.iphdrlength))

=htons(TUNNEL_PORT);               //src prt

*((unsigned short*)(packet2.iphdr+packet2.iphdrlength+

2))=htons(TUNNEL_PORT);           //dst prt

*((unsigned short*)(packet2.iphdr+packet2.iphdrlength+

4))=htons(UDP_HEADER_SIZE+datalength2);//lngth

                  udpChecksum(packet2.p);

上述代码示出定制的UDP头部在何处被创建以用于新的封装分组。存在对用于短数据类型的主机字节序到网络字节序的改变函数“htons”的调用,用于将整个信息分组逐比特地化为头部。

图8示出封装的分组的实际构成。一旦分组被封装成具有白噪声头部的新分组,则嵌入的分组可被用适当的会话密钥加密。

选择UDP分组来封装加密的流量有两方面的原因。UDP是仅有的在协议中包括数据大小从而允许附加额外的头部的普通协议。由于这是隧道协议,因此如果需要数据的任何重传输,则客户端可以对其进行请求,并且不需要隧道跟踪丢失的数据。

图9所示的白噪声头部包含将使用加密的信息,以及关于隧道何时由于超过了MTU(最大传输单元)而需要对数据分组进行分段的关于分段的某些信息。第一序列是发起系统的序列,第二序列是目的地系统序列,而偏移是曾用于对此特别的分组进行加密的白噪声密码流中的偏移。被分段的比特指示这是否是分段的隧道分组,1比特分段号指示这是第一还是第二分段,30比特被保留用于验证填充,并且32比特用于分段id,所述分段id用于将这些分段与其他分段区分开。分段具有重叠的分段id的几率为232分之一,并且这会损坏重装。在封装的分组中,包含256比特的此头部加上额外的以太网、IP和协议头部构成总隧道系统的开销。此开销是每个分组的开销,因此如果送出许多小的分组,则百分比开销比较大,然而如果使用来自文件传输的大的分组,则开销非常低。

在网守应用的以下输出中,示出了隧道分组分段。在被添加白噪声头部之后过大而不能被传输的分组被分割成两个分段。每个分段保持原始IP头部以便确保该分组被正确递送,并且在白噪声头部中具有分段信息。

GateKeeper::init();

pipe::init();1

Conveyer:initread()ether src not 00:00:00:21:a0:1a and

ether src not 00:04:E2:D7:32:9C

Conveyer::initwrite()

KeyManager initializing

Conveyer:initread()ether src 00:00:00:21:a0:1a

Conveyer::initwrite()

KeyManager initializing

incomingconveyer.init();1

outgoingconveyer.init();1

GateKeeper::run();

pipe::run();

Outgoing:Fragmentation=TRUE copying ip and ethernet

headers

setting new sizes

splitting up packet into fragments

adding OxA to wnhdr

adding Ox8 to wnhdr

encrypting data sections of the two fragments

fragment checksums

done creat ing fragments

        display fragmentl:

00  04  e2  d7  32  9d  00  00

00  21  a0  1a  08  00  45  00

03  17  ae  40  40  00  40  11

06  39  c0  a8  01  08  c0  a8

01  04  26  19  26  19  02  e3

00  00  00  4d  00  61  00  74

00  74  00  65  00  72  00  73

00  2e  00  6d  00  70  00  33

00  74  00  00  00  00  00  00

00  00  6a  8e  79  91  cb  c5

01  00  6a  8e  79  91  cb  c5

01  00  da  c3  5e  2f  d5  c5

01  00  da  c3  5e  2f  d5  c5

01  00  00  00  00  00  00  00

00  00  00  10  00  00  00  00

00  10  00  00  00  16  00  00

00  00  00  00  00  10  00  47

00 34 00 37 00 4e 00 4f

00 56 00 7e 00 56 00 00

00 00 00 00 00 00 00 67

00 63 00 6f 00 6e 00 66

00 64 00 2d 00 72 00 6f

00 6f 00 74 00 7c 00 00

00 00 00 00 00 80 e2 a0

94 75 a3 c5 01 80 e2 a0

94 75 a3 c5 01 80 e2 a0

94 75 a3 c5 01 80 e2 a0

94 75 a3 c5 01 00 00 00

00 00 00 00 00 00 00 10

00 00 00 00 00 10 00 00

00 1c 00 00 00 00 00 00

00 10 00 4b 00 42 00 35

00 43 00 34 00 31 00 7e

00 4a 00 00 00 00 00 00

00 00 00 6b 00 65 00 79

00 72 00 69 00 6e 00 67

00 2d 00 77 00 32 00 37

00 6c 00 6d 00 73 00 00

00 88 00 00 00 00 00 00

00 80 cf 21 b1 37 d4 c5

01 80 79 6f e1 dc d4 c5

01 80 cf 21 b1 37 d4 c5

01 80 cf 21 b1 37 d4 c5

01 d0 34 64 00 00 00 00

00 00 00 10 00 00 00 00

00 20 02 00 00 2a 00 00

00 00 00 00 00 18 00 41

00 32 00 32 00 43 00 4e

00 46 00 7e 00 59 00 2e

00 45 00 58 00 45 00 61

00 6f 00 65 00 33 00 70

00 61 00 74 00 63 00 68

00 2d 00 31 00 30 00 74

00 6f 00 31 00 30 00 31

00 2e 00 65 00 78 00 65

00 60 00 00 00 00 00 00

00 80 a1 28 42 31 d5 c5

01 80 e3 5b ef 4a d5 c5

01 80 a1 28 42 31 d5 c5

01 80 a1 28 42 31 d5 c5

01 00 00 00 00 00 00 00

00 00 00 10 00 00 00 00

00 10 00 00 00 02 00 00

00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 2e

00 7c 00 00 00 00 00 00

00 80 70 5c 5f 2f d5 c5

01 80 70 5c 5f 2f d5 c5

01 80 70 5c 5f 2f d5 c5

01 80 70 5c 5f 2f d5 c5

01 00 00 00 00 00 00 00

00 00 00 10 00 00 00 00

00 10 00 00 00 1c 00 00

00 00 00 00 00 10 00 4b

00 31 00 5a 00 36 00 51

00 39 00 7e 00 31 00 00

00 00 00 00 00 00 00 6b

00 65 00 79 00 72 00 69

00 6e 00 67 00 2d 00 77

00 57 00 59 00 45 00 73

00 69 00 00 00 70 00 00

00 00 00 00 00 00 3d 5a

24 2f d5 c5 01 00 3d 5a

24 2f d5 c5 01 80 d3 f2

24 2f d5 c5 01 80 d3 f2

24 2f d5 c5 01 00 00 00

00 00 00 00 00 00 00 10

00 00 00 00 00 12 00 00

00 12 00 00 00 00 00 00

00 10 00 5f 00 39 00 46

00 54 00 53 00 43 00 7e

00 4f 00 00 00 00 00 00

00 00 00 2e 00 58 00 31

00 31 00 2d 00 75 00 6e

00 69 00 78 00 01 00 00

00 00 00 00 00 02 00 00

00 00 00 00 00 0a 00 00

00 00 00 00 00 00 00 00

80 47 81 b5 09      end of display fragment1

sending a second fragment

display fragment2:

00 04 e2 d7 32 9d 00 00

00 21 a0 1a 08 00 45 00

05 a8 0a a1 40 00 40 11

a7 47 c0 a8 01 08 c0 a8

01 04 26 19 26 19 02 e3

00 00 00 4d 00 61 00 74

00 74 00 65 00 72 00 73

00 2e 00 6d 00 70 00 33

00 74 00 00 00 00 00 00

00 00 6a 8e 79 91 cb c5

01 00 6a 8e 79 91 cb c5

01 00 da c3 5e 2f d5 c5

01 00 da c3 5e 2f d5 c5

01 00 00 00 00 00 00 00

00 00 00 10 00 00 00 00

00 10 00 00 00 16 00 00

00 00 00 00 00 10 00 47

00 34 00 37 00 4e 00 4f

00 56 00 7e 00 56 00 00

00 00 00 00 00 00 00 67

00 63 00 6f 00 6e 00 66

00 64 00 2d 00 72 00 6f

00 6f 00 74 00 7c 00 00

00 00 00 00 00 80 e2 a0

94 75 a3 c5 01 80 e2 a0

94 75 a3 c5 01 80 e2 a0

94 75 a3 c5 01 80 e2 a0

94 75 a3 c5 01 00 00 00

00 00 00 00 00 00 00 10

00 00 00 00 00 10 00 00

00 1c 00 00 00 00 00 00

00 10 00 4b 00 42 00 35

00 43 00 34 00 31 00 7e

00 4a 00 00 00 00 00 00

00 00 00 6b 00 65 00 79

00 72 00 69 00 6e 00 67

00 2d 00 77 00 32 00 37

00 6c 00 6d 00 73 00 00

00 88 00 00 00 00 00 00

00 80 cf 21 b1 37 d4 c5

01 80 79 6f e1 dc d4 c5

01 80 cf 21 b1 37 d4 c5

01 80 cf 21 b1 37 d4 c5

01 d0 34 64 00 00 00 00

00 00 00 10 00 00 00 00

00 20 02 00 00 2a 00 00

00 00 00 00 00 18 00 41

00 32 00 32 00 43 00 4e

00 46 00 7e 00 59 00 2e

00 45 00 58 00 45 00 61

00 6f 00 65 00 33 00 70

00 61 00 74 00 63 00 68

00 2d 00 31 00 30 00 74

00 6f 00 31 00 30 00 31

00 2e 00 65 00 78 00 65

00 60 00 00 00 00 00 00

00 80 a1 28 42 31 d5 c5

01 80 e3 5b ef 4a d5 c5

01 80 a1 28 42 31 d5 c5

01 80 a1 28 42 31 d5 c5

01 00 00 00 00 00 00 00

00 00 00 10 00 00 00 00

00 10 00 00 00 02 00 00

00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 2e

00 7c 00 00 00 00 00 00

00 80 70 5c 5f 2f d5 c5

01 80 70 5c 5f 2f d5 c5

01 80 70 5c 5f 2f d5 c5

01 80 70 5c 5f 2f d5 c5

01 00 00 00 00 00 00 00

00 00 00 10 00 00 00 00

00 10 00 00 00 1c 00 00

00 00 00 00 00 10 00 4b

00 31 00 5a 00 36 00 51

00 39 00 7e 00 31 00 00

00 00 00 00 00 00 00 6b

00 65 00 79 00 72 00 69

00 6e 00 67 00 2d 00 77

00 57 00 59 00 45 00 73

00 69 00 00 00 70 00 00

00 00 00 00 00 00 3d 5a

24 2f d5 c5 01 00 3d 5a

24 2f d5 c5 01 80 d3 f2

24 2f d5 c5 01 80 d3 f2

24 2f d5 c5 01 00 00 00

00 00 00 00 00 00 00 10

00 00 00 00 00 12 00 00

00 12 00 00 00 00 00 00

00 10 00 5f 00 39 00 46

00 54 00 53 00 43 00 7e

00 4f 00 00 00 00 00 00

00 00 00 2e 00 58 00 31

00 31 00 2d 00 75 00 6e

00 69 00 78 00 01 00 00

00 00 00 00 00 02 00 00

00 00 00 00 00 0a 00 00

00 00 00 00 00 00 00 00

a0 47 81 b5 09    end of display fragment2

以上  的 分段并未完成,这是因为即使分组被适当地重装,仍存在分段未能被适当地处理导致产生被损坏的分组的情况。但是,此损坏在系统操作中并非关键性的,这是因为客户端仅必须将他们的MTU设定为1300以便容纳永不需要被分段的分组。

在以下的网守应用的输出中,示出密钥取回过程。

GateKeeper::init();

Pipe::init();1

Conveyer:initread()ether src not 00:00:00:21:a0:1a and

ether src not 00:04:E2:D7:32:9C

Conveyer::initwrite()

KeyManager initializing

Conveyer:initread()ether src 00:00:00:21:a0:1a

Conveyer::initwrite()

KeyManager initializing

  incomingconveyer.init();1

  outgoingconveyer.init();1

GateKeeper::run();

pipe::run();

Incoming:Detecting header

HeaderFound!

Detecting fragmentation

wnhdr[24]:112233

failed to open file for reading 0x409fd238retrieve key

from fault

creating request:1:2

checking response to 12

sizeof unsigned long long:8

key was found on fault responsesize:50

key found had UID:69

key found had offset:10

key found had scpcrc:10

key found had length:18

copying key

done copying key

key on vault

save key to drive path:

/tmp/Keys/0000000000000001/0000000000000002.key

可以看出,网守接收分组,意识到其在本地存储器或硬盘高速缓存中不具有密钥,因此其从密钥库请求该密钥,并将其保存到本地高速缓存中。

在下面的输出画面中,示出了规则系统。显示了到来的分组的协议(显示为其数值代码),并且还示出了关于ACCEPT(接受)/DROP(放弃)/ENCRYPT(加密)的规则:

GateKeeper::init();

Pipe::init();1

Conveyer:initread()ether src not 00:00:00:21:a0:1a and

ether src not 00:04:E2:D7:32:9C

Conveyer::initwrite()

KeyManager initializing

Conveyer:initread()ether src 00:00:00:21:a0:1a

Conveyer::initwrite()

KeyManager initializing

  incomingconveyer.init();1

  outgoingconveyer.init();1

GateKeeper::run();

Pipe::run();

 $ <LPP>pMIHPDS</LPP>

================

Incoming:6 ACCEPT←这是被标记为ACCEPT(接受)的到来的6/TCP分组

$<LPp>pMIHPDS</LPp>

+++++++++++++++++14:0:20

00 0e a6 14 1e 8e 00 00

00 21 a0 1a 08 00 45 00

00 34 df a8 40 00 40 06

d7 5e c0 a8 01 08 c0 a8

01 64 80 2a 00 8b ab 6f

9e b7 55 2a bb 33 80 10

05 b4 6a be 00 00 01 01

08 0a 00 04 7d f7 00 15

29 43

================

OutgoingData ACCEPT←这是被标记为ACCEPT(接受)的离开的分组

$<LPP>pMIHPDS</LPP>

+++++++++++++++++0:0:20

ff ff ff ff ff ff 00 00←在此这个分组是广播分组,因此可能被过滤

00 21 a0 1a 08 06 00 01

08 00 06 04 00 01 00 00

00 21 a0 1a c0 a8 01 08

00 00 00 00 00 00 c0 a8

01 04 00 00 00 00 00 00

00 00 00 00 00 00 00 00

00 00 00 00

===============以下的分组已被标记为ACCEPT_ENCRYPT

OutgoingData ACCEPT_ENCRYPT<LPp>PMIHPDS</Lpp>

Fragmentation=FALSE CopyIP&EHeader:ChangeProtocol

ChangeSizeInIPHeader CreateUDPHeader CreateTunnelHeader

getseria1()19216818

c0a80108

getSerial:c0a80108

getseria1()19216814

c0a80104

getSerial:c0a80104

Getting key:2:1←在此,该密钥必须被从密钥库取回

failedto open file for reading 0x41400a08retrieve key

from fault

creating request:2:1

$<LPP>PMIHPDS</LPP>

+++++++++++++++++0:0:20

00 04 e2 d7 32 9c 00 0e

a6 14 1e 8e 08 06 00 01

08 00 06 04 00 02 00 0e

a6 14 1e 8e c0 a8 01 64

00 04 e2 d7 32 9c c0a8

01 65 00 00 00 00 00 00

00 00 00 00 00 00 00 00

00 00 00 00

================

Incoming:11 ACCEPT

checking response to 12

sizeof unsigned long long:8

key was found on fault responsesize:58

key found had UID:23

key found had offset:10

key found had scpcrc:7318349394477056

key found had length:825229312

copying key

前述的调试输出语句默认地被无效,但是仍然存在于代码中以供开发者查看。出于性能原因,这些输出语句在最终系统中被抑制。

在紧跟实际分组的数据段之后放置白噪声隧道头部,并且对整个数据段进行加密、使数据头部保持不变以便传播是无法工作的,这是因为TCP协议在其协议头部中没有指示数据净荷长度的字段。这意味着无法检测分组末尾是否存在另一头部,或者在另一端的应用是否可忽略所附的头部。相反,本系统将整个分组(不论协议如何)封装成新的定制的UDP分组,这是因为UDP协议的确具有规定净荷带有多少数据的字段,因而允许可检测的附加的头部。仅使用读取、处理和写入被全部一次进行的“传送器”线程就将ping的时间降低为不易察觉的(在LAN上通常为0ms到1ms)。线程模型将CPU使用率降低到5~7%。而且,为了避免所有网络流量经过隧道,Berkeley网络过滤器被应用于对分组的读取,其过滤掉外部网卡上的客户端系统的MAC地址。

关于密钥库,为了避免不同处理器的数据类型大小的差异引起的问题(例如64位AMD CPU与32位Intel CPU。在C语言中在64位机器上声明无符号长整型创建64比特数;在32位机器上相同数据类型声明被编译为32比特值。当这两个机器试图通信时会引起一些问题。)声明无符号长长整型;这样不论平台如何均强制为64比特数据类型。

安装过程

通过完全安装选项,为使用Fedora Core 4的Linux机器安装了原型系统。很多默认的Linux配置出于安全原因不允许常规的用户直接访问数据链路层。这些应用需要被运行作为根的(root)或虚拟的(pseudo)。

原型系统的要求如下:

最少5台计算机

-1台计算机用作密钥库(带有Linux)

-2台计算机用作网守(在测试中使用64位AMD体系结构)

-配置有Linux(在测试设置中使用Fedora Core 4)

-安装了Libnet库(libnet.tar.gz)

-安装了Libpcap库(libpcap-0.9.3.tar.gz)

-安装了QT库(作为qt-x11-opensource-desktop-4.0.0.tar.gz被包括在提交中)

-2个网卡

-2台计算机透明地使用该隧道

-这些系统可以被配置任何操作系统,并且使用任何应用。

-配置为在局域网上工作

-在测试设置中,网络MTU被设定为1300字节

-使用DRTCP021.exe在Windows机器上设置MTU,或者在linux中进行man ifconfig以设定MTU。

Linux机器在使用ifconfig设定MTU之后不需要重启。

在网守机器上安装了所有必要的库和编译器之后,所包括的“编译”文件被设定为可执行的(chmod+x./compile),并且执行编译脚本。这将编译所包括的源代码,并且向人员通知系统所需要的任何丢失的包。

在密钥库机器上安装了所有必要的编译器并且设置“/tem/Keys”文件夹之后,人员将“编译”文件设定为可执行的(chmod+x./compile),并且执行编译脚本,以对密钥库正在运行于其上的平台进行编译。此脚本还将告知人员任何其他需要安装的。

配置过程

网守系统的所有配置都需要在网守源文件夹中的“Include.h”文件中完成。

以下部分需要被修改以反映正在被密钥库服务器使用的IP地址和端口。

//密钥库服务器的ip

#define KEY_VAULT_IP“192.168.1.100”//将服务器IP置于此!

#define KEY_VAULT_PORT 1357//将配置KV的端口置于此!(并且确保你的防火墙允许UDP分组在这个端口上外出和进入)

以下部分需要被修改以反映将使用网守的这两个系统的而并不是网守自身的实际MAC地址和IP。然而,实际网守的MAC的确需要被包括在Berkely分组过滤语法中,其作为INCOMINGFILTER定义中的第二MAC地址。

//GK2

//#define INCOMINGFILTER"ether src not 00:04:e2:d7:32:9-

d"

//#define OUTGOINGFILTER"ether src 00:04:e2:d7:32:9d"

//#define MAC 0x0004e2d7329d

//#define INTERNAL_SYSTEM_IP"192.168.1.4"

//#define EXTERNAL_SYSTEM_IP"192.168.1.8"

//#define oUR_KEY_SERIAL 2

//#defina OTHER_KEY_SERIAL 1

//GK1

#define INCOMINGFILTER"ether src not 00:00:00:21:a0:1a

and ether src not 00:04:E2:D7:32:9C"

#define OUTGOINGFILTER"ether src 00:00:00:21:a0:1a"

#define MAC 0x00000021a01a

#define INTERNAL_SYSTEM_IP"192.168.1.8"

#define INTERNAL_SYSTEM_IP_A{192,168,1,8}

#define EXTERNAL_SYSTEM_IP"192.168.1.4"

#define EXTERNAL_SYSTEM_IP_A{192,168,1,4}

#define oUR_KEY_SERIAL       1

#define OTHER_KEY_SERIAL 2

#define EXTERNALDEVICE"eth0"

#define INTERNALDEVICE"eth1"

在上述的头文件中,注释“GK1”指的是客户端之一,并且“GK2”指的是另一个客户端。人员或者注释掉整个“GK1”部分,或者注释掉整个“GK2”部分。

在每个网守上,依据人员将哪根网线插入哪个网卡,人员设定合适的EXTERNALDEVICE(外部装置)和INTERNALDEVICE(内部装置)。EXTERNALDEVICE是具有引向交换机/路由器的网线的网卡。INTERNALDEVICE是具有引向希望使用该隧道的计算机的网线的网卡。

包括修改该隧道的端口号(默认为9753,必须在两个网守的防火墙上都打开)的其他选项也在该头文件中,但是并不必须更改操作的任何其他什么。

实施中涉及的问题

在实施与密钥库系统相结合的安全隧穿系统时存在一些问题。该系统不仅创建安全的点对点通信层,而且还提供用于向系统动态添加新网守而不必在可以开始通信之前人工地将密钥复制给每个其他客户端的方式。同时其满足验证要求。SSH(作为替换方案的一种安全隧道系统)的问题例如在于,其对于中间人攻击是脆弱的。分发密钥本质上破坏MITM攻击的可能性;因为决不发生未加密的密钥交换,黑客决没有截取或欺骗获取密钥的机会。

白噪声流密码由于多方面的原因而在本发明中尤其有用。其的密码加密效果强。其是具有鲁棒性的与比特无关的加密。白噪声流密码提供多数其他加密方法所不具有的独特性质,即一旦数据被加密,各比特就完全彼此无关。这在处理通信时是非常有用的,因为当传输大量信息时单个比特将常常被损坏,有时无法重传输该信息,因此当所使用的加密方法由于一个比特被损坏而失败时,数据丢失或者由于必需重传输数据而导致巨大的性能冲击。白噪声通过比特无关而克服了此问题。如果在以白噪声加密时一个比特被损坏,所得的解密后的数据仍正好是就好像其先前未被加密似的那样。

白噪声预先分发且预先验证的私钥被用作AES会话密钥发生器,从而通过将其有效地移动到客户端,消除了用于会话密钥生成的基于PKI的可信第三方,并且消除了这部分的服务器开销。因为其高度随机本质和格外长的流,白噪声对于此用途是理想的。其他随机数发生器(RNG)也可被使用,但是不那么高效。密钥生成还可以在服务器处发生,但是不必要地增加服务器开销。

对于密钥生成,分发密钥(并非会话密钥)优选地均通过在密钥生成中使用序列号、MAC#、NAM、或者其他唯一标识符作为种子来生产用户/装置特定的密钥而被生产。这验证了一个装置。只有该单个装置具有正确的通用标识符,以能够利用应用密钥(与应用相关的密钥,其从不被发送,并且在该应用内被保护和被机器编译)对装置/人员特定的分发密钥进行解密。这有助于避免盗版和欺骗。因而为了分发密钥,服务器将首先将序列号读取实用程序作为固件补丁发送给新的设备。所述新的设备将MAC#、NAM或UID发送给服务器。接着,服务器由该序列号生成唯一密钥和唯一起始偏移,利用该UID、偏移和密钥信息更新自身,利用应用密钥对私钥进行加密,并且将具有加密的私钥和安全应用的包发送给新的装置。

以下是系统的各种附加特征。分组验证填充可以被添加到定制的白噪声头部中。这可用来防止出现这样的可能性,即服务器的小的可预测拒绝响应可能被黑客阻塞并且截取,以便颠倒地改变白噪声流的小的部分。此验证填充包含白噪声流的与白噪声实验室的CRC校验码(其消除100%可预测的分组的可能性)相互作用的另一片段。

可以提供IP分段完成(IP Fragmentation Completion)。当前,网守隧道分组分段使得分段的分组有近似1%的损坏。如果要保持100%的透明性,则这应该在系统中被校正。此分段对于将分组保持在1500字节的以太网的最大传输大小下是必要的。如上文在配置部分指出的,MTU应该被设定为1300字节,以便确保隧道的分段决不发生。

隧道内部的MAC地址和IP地址可以用分解开的分组中的隧道分组的MAC和IP代替。这对于确保与因特网上的子网的兼容性是必要的,因此系统将不仅在LAN上工作,或者工作在暴露的因特网连接上,而没有进行网络地址转换。MAC到IP地址的绑定可被添加以作为故障保护以双重检验真实性并监视攻击企图。

实施密钥库协议以处理密钥分段将允许系统处理大于216的最大密钥大小。也可以包括网守注册和更新管理。这还可被用于将IP地址动态添加到安全系统列表中,使得不需要人工创建规则。可为系统管理员添加监视攻击企图或偏移同步问题的日志记录设施,以识别恶意活动。

可以添加偏移重叠检验以查看偏移是否被使用两次。可以比较由偏移代表的实际数据或者偏移本身。填充决不应被使用多于一次,否则其遭受统计分析攻击。

在不久的将来可受益于PKI体系结构的一些系统除了隧道之外,还可包括电子邮件服务器/客户端,以及在野外建立安全呼叫的蜂窝电话。由于系统依赖于Berkeley分组过滤类型的表达以确定所读取的分组的类型,此系统可以容易地与防火墙特征整合。

禁止未加密的流量是网守系统中的一个选项;然而这对于大多数环境是不实际的,因为人们需要将电子邮件发送到公司之外以及上网冲浪。在一些情形中,如在医院和军队、以及法人研究机构中,对安全性的需要可能大得以至于网守将放弃所有未加密的流量。

图10示出这样的方法,其中白噪声预先分发并且预先验证的私钥被用作AES会话密钥发生器,从而通过将其有效地移动到客户端,消除了用于会话密钥生成的基于PKI的可信第三方,并且消除了这部分的服务器开销。因为其高度随机本质和格外长的流,因此白噪声对于此用途是有用的。还可采用其他随机数发生器。密钥生成还可以在服务器处发生,但是不必要地增加服务器开销。

首先,系统管理员将USB闪存棒(或其他介质)上的唯一私用身份管理AES-WN(白噪声)密钥对分发给雇员。作为替换方案,在制造时,装置可以具有与在制造过程中烧制在装置中的唯一装置标识符相关联的唯一私钥。

用户通过两个因素验证:分发密钥的持有以及具有鲁棒性的.NET口令。这两个因素是他们所具有的和他们所知晓的。用户(发送方)通过将其的分发私用AES-WN密钥对置入USB驱动器中而开始。[在这种情况下分发密钥在闪存、智能卡上等。]然后,他输入其口令,并且被验证。此过程消除了对于第三方验证的需要。

为了发送安全文件,白噪声(“WN”)分发密钥用作随机数发生器,并且产生16字节(128比特)或32字节(256比特)的会话密钥以及初始化向量。会话密钥可以是任意大小。此会话密钥生成在客户端完成/由客户端完成,并且这样消除了会话密钥的任何外部可信第三方。会话密钥生成也可以在服务器处完成,但是由于生成和安全发送回客户端而增大开销。然后,此会话密钥利用标准化的AES加密算法技术加密文件。这种方式的加密过程使得系统与AES相容。

如上所指出的,分发密钥可通过使用如客户端的MAC、序列号、或NAM的通用标识符作为种子而对于特定客户端特定地生成,以使这些分发密钥是用户/装置特定的,并且防止盗版和欺骗。为了提高密钥安全性,当应用被启动时,应用密钥使用装置上的唯一序列号解密私钥。如果序列号是正确的,则应用将能够解密并使用私钥。被盗版或复制的密钥将被复制到不具有该唯一序列号的另一介质,因此应用密钥将不能解密盗版的私钥。于是,利用该密钥加密的文件不能被盗版者打开或使用。如果密钥被报告为失窃,则其可立即被无效。

在已加密该文件之后,会话密钥自身被AES-WN分发闪存私钥上包含的发送方的预先分发的AES密钥加密(与初始化向量等一起)。接着,AES加密的-AES会话密钥被利用WN分发验证密钥再次加密,并且被嵌入到加密文件的头部中。封装AES加密的-AES会话密钥的WN用作身份管理验证符,并且通过添加此较强的验证来增强会话密钥的保护。预先分发、预先验证的AES密钥还可进行第二层验证加密。

此文件经由包含所有AES-WN分发密钥对的副本的SFI服务器/密钥库被发送到接收方。在服务器处,发送方WN私钥的服务器的副本解密被加密的头部会话密钥,除去WN验证加密的封装层。服务器将会话密钥从在发送方的AES密钥中被加密转换加密(trans-encrypt)为在接收方的AES密钥中被加密。然后,此被转换加密的会话密钥被用接收方的分发WN密钥加密,再次封装加密的会话密钥,并且成为验证层。其被嵌入在头部中。该文件被发送到接收方。

接收方通过具有匹配的分发WN密钥并且通过知晓将其激活的口令而被验证。然后,接收方能够解密该封装验证层。这留下了AES加密的-AES会话密钥。其通过接收方的分发AES私钥被解密。然后,验证且解密后的会话密钥被用于解密文档或文件。

如图10所示的动态分发密钥身份管理和数据保护系统的验证服务器和密钥库具有用于系统上的每个人员/装置的所有物理分发的密钥和密钥对的副本。密钥对可以是WN-WN、WN-AES、或AES-AES,或者任何其他加密密钥对。服务器可以具有会话密钥生成能力,用于为物理分发或为动态分发密钥环境中的加密分发创建新的密钥对;或者,预先制造的密钥对可以被人工插入,以可由验证和密钥库服务器使用以便实现额外的安全性,并且降低服务器的处理劳动。在动态分发密钥环境中,新的密钥被加密并被递送到在已被分发的密钥中加密的新节点。这消除了使用如Diffie-Hellman的不对称握手技术进行的会话密钥分发。此外,此模型消除了对用于创建和发放会话密钥的可信第三方(外部源)的需要。在需要时,会话密钥生成优选地由客户端完成,从而使得其不作为增加服务器开销的来源。会话密钥生成还可以由服务器完成,或者在服务器外部由系统管理员完成。

AES会话密钥生成理想地通过优选使用白噪声预先分发、预先验证的密钥作为具有鲁棒性的、快速的、低开销的随机数发生器以生成AES密钥,来在客户端完成。可以使用其他随机数发生器和数学库。动态分发密钥体系结构基于其所具有的(装置、闪存等上的预分发私钥)以及其所知晓的(遵从用于具有鲁棒性的和安全的口令的微软“.Net2”标准的具有鲁棒性的口令)验证被预先证明资格的用户。这消除了当前对电子地建立身份所需的第三方证书授权中心的依赖性。

在动态分发密钥体系结构中,服务器可使用其的将通过服务器的安全流量从以发送方的密钥被加密转换加密到以接收方的密钥被加密的能力。由于白噪声的速度,能够转录整个传输(文件、会话密钥和向量)而对性能没有负面影响。为了进一步最小化在单独使用(尤其是)AES密钥、或者AES-WN密钥对、或者WN-WN密钥对时的服务器的计算开销,优选的替换方案是仅转换加密被双重加密的会话密钥自身。

会话密钥的转换加密过程如下。创建AES会话密钥(优选在客户端)。此会话密钥用于利用标准AES算法加密文件。此被创建的会话密钥利用客户端的预先分发的AES私钥被加密。然后,利用预先分发的AES或WN验证密钥(分发密钥对中的另一个密钥)将AES加密的会话密钥双重加密,从而有效地封装和双重加密会话密钥,并且增加保护的有效安全性和比特强度的量级。在服务器处,转换加密过程通过能够利用发送方的分发验证密钥的副本来解码验证层,然后用发送方的分发AES私钥的副本对AES会话密钥进行解密,然后利用接收方的预先分发的AES密钥的副本对该对话密钥重新加密,最后利用接收方的预先分发的验证密钥的副本对上述全部进行加密,以验证发送方。然后,被双重加密的会话密钥被嵌入到文件头部中,并且该文件被转发给接收方。

虽然这是一个四步骤的转换加密过程,但是服务器处理最小,因为只有AES(或WN)会话密钥被转换加密。例如,128比特AES会话密钥的长度是16个字符或字节。整个转换加密过程仅是操作总共(16字节×4步骤)64字节。这对于强的AES密钥甚至是可忽略的。这通过以最小的服务器处理实现会话密钥的强保护(决不以电子方式在未被加密的情况下传输)确保具有鲁棒性的安全性。

此过程改进了在下面这样的情境下的身份管理和数据保护,即其中政府或企业由于即使现有AES标准已被证明是无效的并且安全性有问题仍必需使用现有AES标准而受到烦扰。这使得可立即与现有标准相容,同时有利于向更强的加密和验证算法以及技术逐渐过渡。

双私钥系统

还可以使用双令牌系统或双私钥系统。每个端点使用适当的方法(RNG、具有鲁棒性的口令短语、使用子密钥调度等)创建其自己的私钥。不存在密钥传输,仅有初始的起始密钥历史(令牌)。客户端和端点都创建其自己的密钥。由于仅有先前的历史(令牌)、偏移以及密钥结构,因此减少了存储量。为了开始该过程,需要使用安全的通道如SSL。这阻止了中间人攻击。第一计算机A将其第一令牌(从仅有它们知晓的随机偏移开始)与共享秘密进行异或(XOR),并且发送到B。B将其第一令牌(从仅有它们知晓的随机偏移开始)与共享秘密进行异或(XOR),并且发送到A。每个端点已验证了另一个端点。每个端点具有另一个端点的起始密钥历史。每个端点产生了其自己的其他各方都不知晓的初始偏移(附加的秘密)。每个端点产生了其自己的私钥(它们的秘密),它们从未将该私钥共享或发送过该私钥。A使用其自己的发送方令牌历史THs[从其自己的私钥和秘密偏移生成]创建令牌,并且将其与接收方令牌历史THr[在最近一次的会话接收的实际数据块]进行异或(XOR)。每个端点具有在先前会话中发送的、其他端点的最近一次的令牌历史(实际历史数据块);每个端点具有其自己的偏移和从未被发送的秘密私钥。

发送方s                               接收方r

Ps=发送方的私钥                      Pr=接收方的私钥

THs=发送方令牌历史                   THr=接收方令牌历史

发送方令牌历史THs总是由其秘密偏移和私钥生成。接收方令牌历史THr总是在先前会话中从发送方接收的实际数据块(令牌)。

发送方:THr XOR THs=此会话令牌

接收方:利用其生成的THr解码

接收方已验证了发送方。

接收方利用THs,然后为下一次保留该THs。

如果需要,反之(双重)。

因而,在偏移和实际令牌历史(数据块)之间是动态的。在私钥从不来回传输的情况下进行验证。每个端点不需要存储其自己的令牌历史(实际上优选地不存储),因为它们可以通过使密钥退回一个会话容量(会话TH分量的长度),为它们的私钥和当前偏移而再次生成最近一次的令牌历史。如果有人获取令牌历史(实际数据块),他们就可以确定发送方私钥或偏移。如果有人获取偏移,他们就可以确定令牌历史(数据块,因为他们不具有私钥)。

不间断身份验证部分

本发明通过以下操作来管理用户身份:1)通过参照在与同一用户的上一次会话期间到达的密钥中的最终点,初始确保访问系统的个体是其所声称的个体。系统在白噪声流密码中存储该用户的先前会话停止的点,并且在该用户的下一次会话开始时比较流密码的起始点;2)贯穿整个会话核实用户身份;3)确保不存在复制密钥;以及4)如果检测到入侵者,则拒绝两个用户的访问以保卫该网络。报告密钥丢失或失窃导致立即拒绝访问。

该过程提供有意义且大不相同的验证和检测特征。在此,关键是随着内容被消费,WN密钥也被消费。因此,两个端点之间的相互作用的一个方面是对WN密钥的索引。这个值不太可能被第三方知晓。即使WN密钥被窃或者是与WNL算法的知识一起被危及安全的对应的密钥结构,如果没有对应于合法通信方之间的授权使用历史的索引值,则不间断地使用WN密钥以实现对所保护的数据的未授权访问将是不可能的。此持续的验证和检测特征被称为动态身份核实和验证[DIVA]。这位DIVA(英文意恰巧为“歌唱家”)只为正确的听众演唱。不仅WN密钥的不合法用户将被拒绝,而且合法用户也将立刻且自动地受益于知晓攻击和企图的未授权使用:WN密钥不需要明显地被撤销;它将简单地变为对于其合法拥有者是不可用的。这也可以利用产生长的确定性随机(或伪随机)数据流的其他非白噪声算法实现,或者通过调用这些输出的迭代或串行化而实现。

在被称为动态身份核实和验证的不间断实时持续验证的过程中,在非密码意义上使用密钥流的未使用的部分。密钥的随机数据块(或随机数发生器)及其偏移在会话期间被周期性地发送给服务器,并且与在服务器处生成的同一字符串进行比较,以便证实它们是相同的且同步的。此随机块(未用于加密)可被保持在存储器中并且被立即比较,或者写回到如USB或具有写回能力的卡之类的介质以用于在将来进行比较。此片段从未被使用并且是随机的,因此黑客根本无法猜测或预料该流的此部分。仅用于在服务器和客户端之间的比较的密钥流的未使用的段可以是连续的(在加密后使用的密钥的下一段)、向前跳转的随机位置、或者根据应用于密钥流的该未使用的部分的函数而被抽出的数据样本。白噪声是确定性的,这意味着其虽然是被识别的最随机的数据源,但是如果两个端点具有相同的密钥结构和偏移,则这两个端点可以再次产生相同的随机流。

对于基于物理的可移动密钥如USB闪存驱动器、存储卡以及棒、智能卡等的验证,目前没有可用于通过客户端计算机从服务器对外部USB装置和组件进行枚举和不间断存在检测,以确定其存在的标准或有效协议。可靠的存在确定对于防止欺骗和其他安全性破坏技术是关键的。对于初始和不间断客户端验证,能够检验如MAC号和序列号(以及任何其他唯一标识符)的标识符是重要的。这是多因素验证中的一个因素(所具有的和所知晓的)。

优选的不间断USB装置/设备验证技术的一个示例是偏移重叠检验。在此情境下,其是正在被相互比较的偏移。示例:

客户端侧:

1)偏移被设定为100

2)将大小为200的数据A进行加密,并且将偏移增加200

3)发送该数据

4)偏移现在被设定为300

5)将大小为300的数据B进行加密,并且将偏移增加300

6)偏移现在被设定为600

服务器侧:

1)由于网络拥塞,数据B在数据A之前到达

2)服务器识别出偏移在前面,但是由于此流从未被使用,所以这是可以接受的

3)数据A到达,由于使用的偏移低于至今为止所用的最高偏移,所以服务器识别出可能存在问题

4)服务器检验重叠:100+200=300,300+300=600,没有重叠!

在一个的确发生重叠的示例中,大小为100的数据A在偏移100处被加密,然后大小为100的数据B在偏移150处被加密。100到200在偏移从150到200与150到250重叠(50个字节重叠)将用信号指示有人正在企图篡改系统。

可有效使用的修改的或作为替换的USB存在技术包括将密钥流的各个比特一直发送到服务器,以在服务器处验证和证实偏移与客户端的相同密钥对的比特和偏移同步并且相同。也可以使用MAC号、序列号和其他唯一标识符。可以编程为只要发生动作就进行该操作。偏移可以被增大,以便反映和绕过用于不间断会话验证的比特,使得密钥流的这些比特决不被重复和使用。

类似的过程可以用于信用卡。差别在于,实际上传递随机数据段,并且服务器和客户端(智能卡)两者实际上被用一千字节的数据段更新。在成功比较相同的数据块之后,该过程通过从密钥流的下一未使用的片段复制回新鲜数据段,为下一交易或连续验证进行设置。此差别就像硬币的两面-一面仅检验被保存的偏移,另一面实际上检验由那些偏移例如偏移1222285加上下一个1k代表的数据。然后,加1以便为用于核实的下一个随机数据段设置下一个偏移。只要需要时,便可调用此操作。

数据库具有用户的人口统计信息,诸如账号、偏移值、以及指向白噪声的密钥参考。例如,用户用他的智能卡进行购买。智能卡具有唯一账号,其也被存储在数据库中。在这个帐号上有若干信用卡,例如Visa、万事达和美国运通。对于智能卡上的每个信用卡,有与其相对应的1k随机数据段。

交易被如下执行。在步骤1中,刷智能卡。在步骤2中,用户被要求输入其口令。在步骤3中,如果口令有效,则智能卡号引出数据库中的用户的全部信息。该信息包括人口统计信息、偏移值、以及密钥参考。同时,1k数据段被从智能卡上传到服务器上的某个地方。在从数据库中被引出之后,偏移值和密钥参考被加载到白噪声,以便生成1024字节的随机数据。(步骤5)一旦1k的随机数据被生成,它们就被存储在服务器上。(步骤6)然后,在步骤6中由白噪声生成的1k数据以及在步骤3中从智能卡上传的1k数据被进行比较。(步骤7)如果它们匹配,则交易开始。否则,交易被拒绝。(步骤8)在完成交易之后,偏移值增加1024字节。数据库被用新的偏移值更新。并且,信用卡上的收支需要被更新。(步骤10)同时,新的偏移值和密钥文件被送回白噪声,以生成新的随机数据段。从由新的偏移指向的位置开始,拾取新的1024字节随机数据。(步骤11)然后,新的1k数据块被送回USB芯片,并且改写旧的1k数据块。(步骤12)现在准备好进行下一次交易。

动态分发密钥系统优选使用具有鲁棒性的口令(所知晓的)。用户忘记或丢失其口令并不罕见,对于此身份管理范例的不间断使用来说取回口令是必需的,以便用户可以继续被验证并且能够取回加密的信息或文件。存在两种主要的用于恢复口令同时保持用户匿名的技术。1)在系统初始化和使用时,用户没有使用个人信息,而是使用作为用户的秘密的若干一般问题和回答来注册其密钥。然后,如果需要,则服务器可以在将来重新验证并且安全地重新分发此口令。2)用户利用唯一分发密钥、应用密钥和一般口令访问安全应用和服务。用户改变其口令。接着,他们的新口令被利用应用密钥/私钥进行加密,并且安全地存储在用户的装置/计算机或者可移除装置中。在忘记口令的情况下,加密后的口令可以被发送到服务器,并且用户被重新验证,服务器可以重新发放用于该用户的、与他们的物理分发私钥相关联的另一默认口令。其将以加密状态被发送给用户。

密钥创建的扰动方法

在创建保护数据和管理身份的安全系统时,密钥创建、存储和分发总是重要的需要考虑的事项。白噪声密钥是多功能的。其一个方面是,它们是非常高效的确定性流随机数发生器。仅利用内部密钥结构的知识以及偏移,两个端点就可重新创建相同的流段(令牌)。在分发密钥系统中,每个端点具有预先分发的密钥。不传输密钥信息而仅传输偏移,每个端点可重新创建从未被创建或传输的相同的密钥段(令牌)。如此,这些验证密钥段不能被闯入者猜测或破解。取得验证令牌并不是能够破解实际密钥的足够的剽窃,在该密钥中这些令牌仅仅是微不足道的与比特无关的段。

由于在服务器和客户端装置两者的密钥存储空间、计算开销、以及覆盖区的大小都被最小化,因此白噪声密钥是实现此的优选方法。对于网络上的每个人员或装置,少量的内部密钥信息和偏移生成庞大的高度随机的密钥流,并且最小化对长的密钥的存储要求。密钥分发以如下几种方式之一发生:

--密钥被物理地给予客户端/服务器

--利用装置通用识别号如MAC#、序列号、NAM(蜂窝电话)将分发密钥制造(烧制或铭刻)在装置上,以使密钥与具体装置相关联以便实现密钥私密性

--对于可容易扩展的安全网络或身份管理方案,分发密钥与具体装置相关联,并且在应用密钥中被加密地电子返回到装置或人员,

--所有端点所具有的一般应用密钥调度通过会话密钥的安全交换被“扰动”以创建唯一的用户/装置特定的密钥,其中所述会话密钥被用于算法密钥调度,以创建端点使用的唯一的确定性密钥。此提取技术意味着由端点使用的密钥决不被发送。算法密钥调度是搀有随机比特的一连串的子密钥结构。

密钥生成的扰动方法的一个示例如下:

密钥生成技术

密钥K是通过安全方法传输的会话密钥。子密钥SK1...SKn是已被预先分发给端点的算法密钥调度。每个端点和服务器具有相同的算法密钥调度,其包括搀有随机化的比特的各种长度的n个子密钥。密钥调度可以随应用的不同而被修改。不同密钥调度的几乎无穷尽的阵列可以被用于在不同应用之间添加更高级别的可变性。服务器通过安全过程(SSL、Diffie-Helman等)向端点A发送会话密钥K。偏移与密钥创建无关。对于加密使用,偏移由应用管理以防止密钥段被重新使用。对于DIVA的身份管理、检测和使用,通过过程或公式从分发密钥K值确定偏移。例如,将128比特(16字节)密钥K分为8个2字节的片段并且对这些片段进行异或,以创建被压缩/减小的偏移值。

i)从偏移P开始,将会话密钥K和子密钥1(SK1)的相应比特进行异或,直到该子密钥被完全处理

ii)在SK1被扰动之后,向右偏移,并且从P-1开始,以相同方式处理SK2,直到完成

iii)在SK2被扰动之后,向右偏移,并且从P-2开始,以相同方式处理SK3,直到完成

iv)重复上述处理,直到所有的SKn密钥都以这种方式被扰动

已通过扰动子密钥结构调度从被传输的会话密钥K创建唯一白噪声密钥。通过将(在垂直方向上)从不同的偏移开始的SK1到SKn的相应比特进行异或,创建将被使用的密钥流。参照图12了解密钥生成过程。此过程获得的性能结果是能够创建庞大、高度随机的密钥流而同时最小化装置或端点上所要求的覆盖区/存储空间。其还将需要被传输的密钥信息K的量最小化为如今所使用的较小大小的密钥长度。

以这种方式,子密钥已被扰动以创建不能被猜测也不能被破解的密钥,同时使白噪声密钥与其他密码或密钥选项的覆盖区大小相同或相似。每个实施可以具有唯一的密钥调度。然后,密钥调度已被扰动为唯一的白噪声实施,并且准备好使用。这已经实现了若干种效果。中间人可以具有分发密钥调度,但是决无法知晓继而生成唯一端点密钥的偏移或者会话密钥。此技术还简化了制造和存储问题(例如在SCADA环境中),并且仍能够生成唯一密钥。

通用标识符扰动密钥创建方法

(具有以及不具有口令)

将存在这样的情境,其中终端用户将在使用基于软件狗(dongle)的密钥(外部外围装置如USB闪存或类似的RSA验证软件狗)与不要求用户/端点具有额外物理装置之间找到平衡。在这种情境下,装置/端点上的密钥调度可以被扰动以创建唯一密钥,通过使用装置/端点特定的标识符如MAC或NAM号输出唯一密钥流。该号码被读取,并且在需要时通过使该号码通过单向函数而对其进行修改,并且此结果被用于以上面说明的方式扰动装置/端点密钥调度,以创建具有附加抽象层的装置特定的密钥。此外,在存在人们相互作用的装置或端点处,此技术也可部署使用口令(私钥仅被用户知道)和通用标识符号,以便然后扰动密钥调度。应注意,端点和服务器必须使用安全密钥交换方法,以将这些密钥分发给其他端点并且相互分发这些密钥以便进行通信。应注意,尽管如果没有使用具有鲁棒性的口令,口令的使用可能是最弱的安全链接,但是通过使用DIVA及其连续验证和检测能力,任何安全性担忧都被减轻。

防止中间人攻击(混合以及其他方式)

上述技术通过使用传统PKI或其他安全分发机构,以安全地传输中间人无法知晓或无法知情的偏移或密钥信息,来防止中间人攻击。动态身份核实和验证也可防止中间人攻击,而不需要交换这种密钥和/或偏移,或者不需要使用PKI/SSL/Diffie-Helman来传输密钥或偏移信息。这是因为不论中间人捕获怎样的信息,他也不具有用户或装置的正确的物理密钥。如果MiM具有物理的偷窃的密钥,则被危及安全的端点不具有登录该系统的密钥(因此这并非中间人攻击)。如果密钥物理丢失,则失窃/丢失被报告,并且系统管理员禁止该账号。如果唯一密钥信息被复制到不同的装置,则由于需要正确的通用标识符来解密和使用该密钥,因此该密钥将不起作用。仍然假设MiM闯入者可以登录该系统,由于具有不同偏移的(不同步的)两个相同的密钥将被检测到并且被禁止,所以DIVA将识别出并处理这种情况的出现。

中间人攻击假定端点A和B同时在该系统上,并且闯入者C捕获被传输的信息并且使其改变方向,从而C对于端点A伪装其是B,并且对于端点B伪装其是A。在其中只有端点、或客户端和代理服务器具有DIVA密钥的单方面DIVA部署中,闯入者C可以绕过A和B(在系统外部)以入侵网站或服务器,并且直接窃取登录信息、密钥、以及其他安全性度量。接着,他们可以作为不同的人/装置登录进入站点。这是一种不同类型的安全漏洞,其需要通过诸如防火墙、入侵检测、加密用户信息的存储等其他手段处理,或者对于服务器/站点自身,需要利用DIVA并在服务器/站点和端点/客户端之间创建双向验证关系来处理。这种攻击途径不是中间人攻击,但是尽管如此,仍可被DIVA识别并处理。

在上述情景中,DIVA用户能够拒绝(否定)站点上的购买或活动,这是因为在其DIVA密钥上或在监视这种活动的代理服务器上没有针对这种情况的登录的活动。破坏仍可识别,并且建立该客户端的拒绝或否定能力。

动态身份核实和授权[DIVA]:

动态身份核实和授权以及其起到的不同功能的基本特征是生成和比较从未被创建或传输的令牌(密钥段)的能力。这些和其他类似的DIVA技术对于身份核实、历史日志记录和拒绝或不可否定、基于因特网的安全支付拓扑结构以及安全站点访问、SCADA拓扑结构等(但不限于这些)是理想的。

DIVA包含以下的能力:

A.状态双向和单向验证

双向验证意味着每个端点可以请求和发送验证数据段或偏移。这意味着每个端点具有密钥生成能力。单向验证意味着只有一个端点(服务器/站点)具有密钥生成能力。然后,服务器将后续的尚未被使用的密钥流数据段写回端点(并且安全地或以其他方式递送此数据块)。在下一次会话中,服务器/站点比较端点处的实际数据与它们可使用端点的密钥结构和当前偏移而生成的数据。

目前,一旦登录时就发生网络用户的验证。当闯入者入侵到“安全”网络中时,闯入者可以自由地到处漫步而不被注意。利用DIVA,密钥流在整个会话中被轮询,以连续地识别和核实正确的用户位于网络上。可以结合会话密钥的传输、时间戳的使用等,以增加初始网络访问(登录)的安全性,然后DIVA由此继续验证。

B.状态检测

在端点和服务器之间,密钥流的偏移必须保持同步。如果闯入者设法窃取密钥或者获得网络访问,则服务器、合法端点、以及闯入者之间的偏移变为不同步。只存在两种后果:1)合法拥有者首先使用其密钥/卡,并且随机密钥数据段(或偏移)在合法卡上被更新。于是,窃贼使用窃取的密钥/卡,但是由于1k数据段(或偏移)在失窃的密钥/信用卡与服务器之间并不匹配,因此这不会继续进行下去。帐户立即被禁止。2)窃贼首先成功使用窃取的密钥/卡。当下一次卡持有者使用其卡时,交易被拒绝,这是因为失窃的卡已被新的偏移或数据段更新,服务器数据库上的偏移而不是合法卡上的数据段或偏移已被更新。盗窃已被识别出。帐户立即被禁止。由于前次交易,因此知晓盗窃发生在何处。

C.自动撤销

固有的入侵检测仅仅继续进行,以监视偏移和密钥段(令牌)总是保持同步。这是偏移号或随机数据段的简单比较。没有任何人的干预,检测出立即失去同步的偏移,然后帐户被冻结,并且该密钥被拒绝网络访问。不要求转到外部各方、撤销列表等。系统管理员可以补救或处理任何情形,而不用担忧持续的或不间断的不法行为。

D.授权/DRM

通过以与验证相同的方式使用密钥流的不同部分来实现许可和使用权限的分配和监视。

虽然上文已讨论了多个示例性的方面和实施例,但是本领域技术人员可以认识到其的一些修改、置换、增加和其子组合。因此,本发明将包括落入本发明真实精神和范围内的所有这样的修改、置换、增加和其子组合。通过改变密钥创建和存储、验证、检测和撤回的不同组成部分在客户端、服务器、人员、装置或代理服务器之间的出现位置,可实现多种显而易见的拓扑结构配置。单个组成部分可以被用于附加的安全抽象层的其他网络拓扑结构中。

去获取专利,查看全文>

相似文献

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

客服邮箱:kefu@zhangqiaokeyan.com

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

  • 服务号