关闭

Kerberos原理解析

标签: 加密技术Kerberos大数据Hadoop
265人阅读 评论(0) 收藏 举报
分类:

Kerberos介绍

Kerberos这一名词来源于希腊神话“三个头的狗——地狱之门守护者”。

系统设计上采用客户端/服务器结构与DES加密技术,并且能够进行相互认证,即客户端和服务器端均可对对方进行身份认证。可以用于防止窃听、防止replay攻击、保护数据完整性等场合,是一种应用对称密钥体制进行密钥管理的系统。

支持SSO(Single Sign On),用户只需输入一次身份验证信息就可以凭借此验证获得的票据(ticket-granting ticket)访问多个服务。

由于在每个Client和Service之间建立了共享密钥,使得该协议具有相当的安全性。

认证原理解析

准备阶段

先看下图:

这里出现的角色有三个分别是:

  • KDC (Key Distribution Center)
  • Client
  • Service

其中KDC有两个服务:

  • AS (Authentication Server): 认证服务,用于签发“Ticket-Granting Tickets” (TGT)
  • TGS(Ticket Granting Server): 许可证服务,用于签发service tickets(各种服务的tickets)

密钥两个:

  • KDC与Client之间的共享密钥(密钥A,其实就是用户密码)
  • KDC与Service之间的共享密钥(密钥B)

认证过程

第一步:

用户发送自己的用户信息给KDC,KDC访问AS服务,获得TGT,并用密钥A加密TGT以及一个Session Key给用户。用户得到加密数据后,使用密钥A解密得到TGT和Session Key(这里简称为SK)。

其中,TGT用于第二步请求各种服务的tickets;SK主要用于Service对Client的身份鉴别,在步骤二中会体现。

第二步:

如图:

认证第二步
1. Client将之前获得TGT和要请求的服务信息(服务名等)发送给KDC,认证用户合法后,KDC中的TGS将SK(第一步中产生)和用户名,用户地址(IP),服务名,有效期, 时间戳一起包装成一个Ticket,并用密钥B加密,发送给Client;
2. 此时Client没有密钥B所以他无法查看Ticket中的内容,于是Client将Ticket直接转发给Service。
3. 同时Client将自己的用户名,用户地址(IP)打包成Authenticator,用之前获得的SK加密也发送给Service。
4. Service 收到Ticket后利用它与KDC之间的密钥B将Ticket中的信息解密出来,从而获得SK和用户名,用户地址(IP),服务名,有效期。然后再用SK将Authenticator解密从而获得用户名,用户地址(IP)将其与之前Ticket中解密出来的用户名,用户地址(IP)做比较,从而验证Client的身份。
5. 如果Service有返回结果,将其返回给Client。

参考

http://idior.cnblogs.com/archive/2006/03/20/354027.html

1
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:32988次
    • 积分:638
    • 等级:
    • 排名:千里之外
    • 原创:25篇
    • 转载:0篇
    • 译文:5篇
    • 评论:1条
    文章分类
    最新评论