zoukankan      html  css  js  c++  java
  • Kerberos

    kerberos身份认证过程:
        第一步:账号和KDC互相认证;
        账号A向KDC证明自己的身份:
            1.账号A首先会把自己的密码hash,得到一把秘钥Kclt;
            2.Kclt会把当前的时间戳加密,生成一个字符串;使用{时间戳}Kclt来表示;
            3.将生成的字符串{时间戳}Kclt、账号A的信息,以及一段随机数作为请求发送给KDC。
                请求:AS_REQ="{时间戳}Kclt、账号A的相关信息,随机字符串"
            4.KDC收到请求之后,会识别出这是账号A发来的信息,于是就使用与账号A相对应的经过相同方式hash过密码而得到的Kclt来解密账号A发来的请求,如果能解开则可以确认是账号A本人了;确认过眼神,是一样秘钥的人;(从这一步可以看出来账号A和KDC端拥有一样的密码);
        KDC向账号A证明自己的身份:
            理论上KDC使用同样的方法来hash密码然后将加密时间戳所得的字符串、自己的信息以及随机数发送给账号A也就可以证明自己的身份了,但是这个机制会让KDC非常的忙碌;所以实际上KDC使用的是下面的方式:
                1.首先KDC会生成两把一样的秘钥Kclt-kdc,用来作为日后账号A和KDC之间相互认证之用;这样就省去了每次KDC需要根据客户端发来的请求而确认账号身份的步骤;但是这对秘钥也是跟客户一一对应的,也就是说KDC会为每个客户都生成一对相同的Kclt-Kdc秘钥对;按理说应该把秘钥对中的一个分给其对应的客户端,但是保管秘钥对于KDC也是一种负担,所以它将保管自己秘钥的工作也交给了账号,所以每次客户端的账号需要KDC认证时,就将KDC的秘钥再传送给KDC端,不难想到,当然不是直接将自己的秘钥传递给账号啦,虽然账号自己有跟KDC一模一样的秘钥;KDC会把自己的独有的密码经过hash后生成一个名为Kkdc的秘钥;然后再用它加密委托给账号A管理的秘钥(Kclt-kdc)以及账号A的信息而得到的字符串称为TGT,然后KDC端回复客户端AS_REP,客户端账号收到回答之后,使用Kclt解密下文红色区域,通过里面的时间戳和随机字符串来确定KDC的真实性,然后保存Kclt-kdc和TGT,用以日后请求KDC时使用;TGT={账号A的相关信息,Kclt-kdc}Kkdc;
                    回答:AS_REP="TGT、{Kclt-kdc,时间戳,随机字符串}Kclt"
                        蓝色区域的作用:每次客户端账号请求KDC时,都会发送TGT给KDC端,然后KDC使用Kkdc解密TGT得到与账号认证时使用的Kclt-kdc这个秘钥;
                        红色区域的作用:KDC端将用于与账号之间认证时使用的Kclt-kdc这个秘钥加密发送给客户端的账号;
                        这样KDC端就能通过仅保存经过hash自己密码所得的Kkdc这个秘钥就能与不同账号建立可信连接了;
                        
                        
        第二步:账号A请KDC帮忙认证资源B:
            1.首先账号A会给KDC发送一个名为TGS_REQ的请求;TGS_REQ="TGT,{账号A的相关信息,时间戳}Kclt-Kkdc,资源B的相关信息"
            2.KDC 收到TGS_REQ后,先用Kkdc解密TGT得到Kclt-kdc,再用Kclt-kdc和账号A互相认证身份;一旦确认过眼神,是要等待的人,然后KDC就会帮助A和B牵线系红绳了;
            3.KDC会再生成两把同样的秘钥供A和B之间使用(怕嫁错新郎,牵错新娘),这个秘钥称为Kclt-src,一把交给A一把委托A交给B;其中一把经过Kclt-kdc加密后发送给账号A,为了A不会受假的资源B所骗,KDC把B的密码hash成Ksrv,然后用它加密那把委托A交给B的Kclt-srv再一起发送给账号A,我们把这个被加密后的数据叫做Ticket,因为只有真正的B才能够解密Ticket,所以可以用来确认B的身份;Ticket={账号A的信息,Kclt-sev}Ksrv
                TGS_REP="{Kclt-srv}Kclt-Kdc,Ticket"
            4.账号A收到TGS_RWP之后先用Kclt-Kdc解开紫色区域,得到Kclt-srv,然后保留Ticket用来获取资源B时发给B;接下来如果需要多次访问资源B都可以使用同一个Ticket,不需要每次都向KDC申请,从而减轻了KDC的负担;
        第三步:账号A和资源B互相认证:
            1.账号A给资源B发送{账号A的信息,时间戳}Kclt-srv以及Ticket,我们称这个请求为AP_REQ;AP_REQ="{账号A的信息,时间戳}Kclt-srv,Ticket"
            2.如果资源B是真的它就可以解开Ticket,从而得到Kclt-srv,然后就可以解开"{账号A的信息,时间戳}Kclt-srv",从而确认账号A的身份,因为只有A和B拥有Kclt-srv这个秘钥;然后回复AP_REP来向A证明自己是真的;AP_REP={时间戳}Kclt-srv
            3.账号A使用Kclt-srv解密B发来的AP_REP,得到时间戳来判断资源B的真假;
            
                        
     注:根据wireshark网络分析就这么简单一书做的学习笔记,如有错误,欢迎指正;侵删;

     这本书虽然很薄但是写的非常有意思,很适合入门阅读,推荐给能看见这篇笔记的人;      

  • 相关阅读:
    深入揭秘HTTPS安全问题&连接建立全过程
    申请https证书需要注意的4大问题
    如何排查APP服务端和客户端是否支持ATS
    Apache和Nginx配置支持苹果ATS方法
    服务器配置ssl证书支持苹果ATS方法
    HTTPS背后的加密算法
    图解HTTPS协议加密解密全过程
    Java单例模式——并非看起来那么简单
    flask+mako+peewee(上)
    [转]ubuntu中查找软件的安装位置
  • 原文地址:https://www.cnblogs.com/guowei-Linux/p/11072883.html
Copyright © 2011-2022 走看看