浅析Kerberos协议

前一阵子一直在刷题，导致很多之前看过的东西都有所遗忘，哎，当真是按下葫芦起了瓢，罪过，罪过，今天就来回顾一下之前看了好多遍的东西。这里提醒下，这篇文章需要一点点加密解密的知识~~~
Kerberos，据传说他是有三个头的狗狗，看守冥界大门，凶猛异常（我觉得还是下图比较合我口味~~~），但是我怎么莫名想起哈利波特了。。。

在这里，Kerberos是一种双向的身份认证协议（恩，就是在我大天朝办某些事情时，需要证明我是我。。。）。它采取的是引入权威的第三方来负责身份认证，称为KDC（但是我还是喜欢big bro这个称谓），它知道域里所有账号和资源的密码，下面我们就结合一个实例来说明Kerberos工作机制。
现在域中仅存在三台机器，A, B， 和 KDC，如下图，现在A想要访问B上的资源，自此，Kerberos开始表演了，拢共分三步。

第一步：A和KDC互相认证

1. A根据自己的密码，生成一把秘钥Kclient， 使用这把秘钥将发送的时间戳加密，即Kclient（timestamp），原因就是为了防止别人截获这个东西，通过后面再加上A的账户信息和一个随机字符串(作用稍后会讲)，就发送给KDC了，

A-KDC_Req=Kclient(timestamp)+info(A)+str

2. KDC收到请求后，找到A账户相关信息，使用对应的解密算法，将发送时间戳解密出来，A就完成了身份认证，就证实了A是A。这里说明一下为何会选用时间戳，因为如果这个请求被网络中其他人截获，破解后，这个人会伪装成A，进行骗取认证，即重放攻击。由于这种攻击会耗费一定时间，所以当KDC解出加密时间戳，发现和当前时间相差太大，会认为是重放攻击，就不再向下进行了，突然发现了在域中同步时间的好处
3. 现在轮到KDC向A证实，自己是自己了，理论上来讲，只需要将请求中的随机字符串用A的秘钥加密，发还给A就行了，A收到回复，若能解出，则KDC为真；若解不出，KDC为假。但是，当域中很多机器同一时间向KDC请求验证时，KDC的负载就比较大了，不太好，于是， 下面的过程就派上用场了。KDC证实A的身份之后，生成一把专门用于KDC和A之间进行通信用的秘钥Kclient-kdc，再用自己的秘钥Kkdc将其加密Kkdc(Kclient-kdc)，构成了A专有的和KDC进行通信的“钥匙”——TGT，之后再将Kclient-kdc，时间戳，随机字符串使用Kclient加密，

KDC-A_Rep=TGT+Kclient(Kclient-kdc+timestamp+str)

4. A收到答复之后，使用Kclient解开后面加密信息，得到Kclient-kdc，并证实KDC身份。
整个过程如下图所示：

第二步：A请求KDC认证B

接下来就是A要求KDC认证B，步骤如下：

1. A将TGT+Kclient-kdc(info(A)+timestamp)+info(B)发送给KDC，KDC接到后，先将TGT解出Kclient-kdc，再解出后面A的信息，来验证A。

A-KDC-B_Req=TGT+Kclient-kdc(info(A)+timestamp)+info(B)。

2. 之后，KDC生成一把秘钥，Kclient-server供A与B通信时单独使用，将这把秘钥连同A的相关信息，使用B的秘钥进行加密，形成一个只有B能解开的，与A进行通信的Ticket——Kserver(info(A)+Kclient-server)， KDC将这个Ticket外加Kclient-kdc(Kclient-server)发送给A

KDC-A-B_Rep=Kclient-kdc(Kclient-server)+Ticket

第二步过程如下图：

第三步：A和B相互认证

A经历了千辛万苦，终于找到了一条可以和B进行秘密通话的路，喜形于色，赶紧与B进行相互确认~

1. A将Ticket 外加 Kclient-server(info(A)+timestamp)发送给B

A-B_Req=Kclient-server(info(A)+timestamp)+ Ticket

2. B接到请求，用B的私钥解开Ticket，得到Kclient-server以及info(A)， 用Kclient-server解密后面的info(A)和timestamp来验证A的身份；若验证为真，则将时间戳经过Kclient-server加密，发送给A，等待A确认B

B-A_Rep=Kclient-server(timestamp)

3. A接到来自B的回应，验证B的身份，自此整个认证过程完成，第三步如下图：

好了，验证完成之后，A和B就可以说一些“悄悄话了”