理论教育 基于服务器的密钥建立-安全协议

基于服务器的密钥建立-安全协议

时间:2023-10-28 理论教育 版权反馈
【摘要】:设计基于服务器的密钥传输协议的一个重要因素就是谁生成会话密钥。表4.3基于服务器协议用到的其他符号Needham-Schroeder共享密钥协议由Needham和Schroeder于1978年提出,如图4.14所示。该两种凭证均使用私有密钥加密,但加密的密钥不同。这里,图4.19用户向服务器申请服务的报文4.TGS发放服务器票据和会话密钥TGS得到请求后,用私有密钥KTGS和会话密钥KC,TGS解开请求得到TicketTGS和AuthenticatorC的内容,根据两者的信息鉴定用户身份是否有效。

基于服务器的密钥建立-安全协议

设计基于服务器的密钥传输协议的一个重要因素就是谁生成会话密钥。许多设计者隐含地假设用户不能生成质量好的会话密钥,而把这个任务交给服务器,但是这个假设并不总是必要的,现有的协议中很多是由用户而不是服务器选择会话密钥。表4.3给出了本节要用到的符号。

表4.3 基于服务器协议用到的其他符号

Needham-Schroeder共享密钥协议由Needham和Schroeder于1978年提出,如图4.14所示。第2条消息用A的共享密钥KAS加密,其中包含A的随机数和B的标识,分别为A提供会话密钥的新鲜性和密钥认证。

图4.14 Needham-Schroeder共享密钥协议

对B来说,他解密A传出的加密消息,得到会话密钥的值再与A进行随机数握手来保证消息不被重放。然而,由于攻击者可以知道旧会话密钥值,因此握手易遭到破坏。这个弱点最初被Denning和Sacco指出。在他们的攻击中,攻击者使用泄露的会话密钥假冒A来欺骗B。

为了解决这个攻击,Denning和Sacco提出了图4.15作为解决方案,它使用时间戳来验证密钥的新鲜性。

图4.15 Denning-Sacco协议

Bauer等人讨论了当A的长期密钥被攻破后Needham-Schr oeder协议的脆弱性:即使检测出密钥被攻破并更换了长期密钥的情况下,一旦攻击者知道A的长期密钥就可以假冒成A(和Denning-Sacco攻击一样)。他们提出了一个不使用时间戳的解决方案,如图4.16所示。协议对于A和B来说大致上是对称的,他们都以明文形式发送一个随机数给S,S之后在分开的消息中返回A和B的随机数。

图4.16 Bauer-Berson-Feiertag协议

Ker ber os认证服务是由麻省理工学院的Pr oject At hena针对分布式环境的开放式系统开发的认证机制。Ker ber os提供了一种在开放式网络环境下(无保护)进行身份认证的方法,它使网络上的用户可以相互证明自己的身份。它是计算机网络认证的标准之一,已被开放软件基金会(OSF)的分布式计算环境(DCE)以及许多网络操作系统供应商所采用。Ker beros用基于Needham-Schroeder协议的密钥建立协议作为它的一个模块,这个协议采用了Denning和Sacco的建议,使用时间戳代替了挑战-响应。当前的Ker beros协议是第5个版本。

Kerberos把身份认证的任务集中在身份认证服务器上。Kerberos的认证服务任务被分配到两个相对独立的服务器:认证服务器(Authenticator Server,AS)和票据许可服务器(Ticket Granting Server,TGS),它们同时连接并维护一个中央数据库存放用户口令、标识等重要信息。整个Kerberos系统由四部分组成:AS、TGS、Client、Server。

Kerberos使用两类凭证:票据(Ticket)和鉴别码(Authenticator)。该两种凭证均使用私有密钥加密,但加密的密钥不同。

Ticket用来安全地在认证服务器和用户请求的服务之间传递用户的身份,同时也传递附加信息用来保证使用Ticket的用户必须是Ticket中指定的用户。Ticket一旦生成,在生存时间指定的时间内可以被Client多次使用来申请同一个Server的服务。

Authenticator则提供信息与Ticket中的信息进行比较,一起保证发出Ticket的用户就是Ticket中指定的用户。Aut henticator只能在一次服务请求中使用,每当Client向Ser ver申请服务时,必须重新生成Authenticator。

这里我们介绍Kerberos认证版本4的内容,在叙述中我们使用表4.4中的符号。

表4.4 Kerberos使用的符号

用户C请求服务S的整个Kerberos认证协议过程如图4.17所示。

图4.17 Kerberos认证过程

1.C请求票据许可票据

用户得到票据许可票据的工作在登录工作站时进行。登录时用户被要求输入用户名,输入后系统会向认证服务器AS以明文方式发送一条包含用户和TGS服务两者名字的请求。

IDC是工作站的标识,其中的时间戳是用来防上回放攻击的。

2.AS发放票据许可票据和会话密钥

认证服务器检查用户是否有效,如果有效,则随机产生一个用户用来和TGS通信的会话密钥KC,TGS,然后创建一个票据许可票据TicketTGS,票据许可票据中包含用户名、TGS服务名、用户地址、当前时间、有效时间,还有刚才创建的会话密钥。票据许可票据使用KTGS加密。认证服务器向用户发送票据许可票据和会话密钥KC,TGS,发送的消息用只有用户和认证服务器知道的KC来加密,KC的值基于用户的密码。AS发送的报文如图4.18所示。

这里,(www.daowen.com)

Lifetime与Ticket相关联,如果太短,则需要重复申请,太长则会增加重放攻击的机会。

3.C请求服务器票据

用户工作站收到认证服务器回应后,就会要求用户输入密码,将密码转化为DES密钥KC,然后将认证服务器发回的信息解开,将票据和会话密钥保存用于以后的通信,为了安全性,用户密码和密钥KC则被删掉。

当用户的登录时间超过了票据的有效时间时,用户的请求就会失败,这时系统会要求用户

图4.18 AS发送的报文

重新申请票据TicketTGS。用户可以查看自己所拥有的令牌的当前状态。

一个票据只能申请一个特定的服务,所以用户必须为每一个服务S申请新的票据,用户可以从TGS处得到票据TicketS

用户首先向TGS发出申请服务器票据的请求。请求信息中包含S的名字、上一步中得到的请求TGS服务的加密票据TicketTGS,还有用会话密钥加密过的Authenticator信息(如图4.19所示)。

这里,

图4.19 用户向服务器申请服务的报文

4.TGS发放服务器票据和会话密钥

TGS得到请求后,用私有密钥KTGS和会话密钥KC,TGS解开请求得到TicketTGS和AuthenticatorC的内容,根据两者的信息鉴定用户身份是否有效。如果有效,TGS生成用于C和S之间通信的会话密钥KC,S,并生成用于C申请得到S服务的票据TicketS,其中包含C和S的名字、C的网络地址、当前时间、有效时间和刚才产生的会话密钥。票据TicketS的有效时间是票据TicketTGS剩余的有效时间和所申请的服务缺省有效时间中最短的时间。

最后TGS将加密后的票据TicketS和会话密钥KC,S用用户和TGS之间的会话密钥KC,TGS加密后发送给用户。用户C得到回答后,用KC,TGS解密,得到所请求的票据和会话密钥。

这里,

5.C请求服务

用户申请服务S的工作与3相似,只不过申请的服务由TGS变为S。

用户首先向S发送包含票据TicketS和AuthenticatorC的请求,S收到请求后将其分别解密,比较得到的用户名、网络地址、时间等信息,判断请求是否有效。用户和服务程序之间的时钟必须同步在几分钟的时间段内,当请求的时间与系统当前时间相差太远时,认为请求是无效的,用来防止重放攻击。为了防止重放攻击,S通常保存一份最近收到的有效请求的列表,当收到一份请求与已经收到的某份请求的票据和时间完全相同时,认为此请求无效。

这里,

6.S提供服务器认证信息

当C也想验证S的身份时,S将收到的时间戳加1,并用会话密钥KC,S加密后发送给用户,用户收到回答后,用会话密钥解密来确定S的身份。

通过上面六步之后,用户C和服务S互相验证了彼此的身份,并且拥有只有C和S两者知道的会话密钥KC,S,以后的通信都可以通过会话密钥得到保护。

免责声明:以上内容源自网络,版权归原作者所有,如有侵犯您的原创版权请告知,我们将尽快删除相关内容。

我要反馈