一篇文章看懂Kerberos协议

Kerberos协议

kerberos是一种计算机网络认证协议，他能够为网络中通信的双方提供严格的身份验证服务，确保通信双方身份的真实性和安全性。不同于其他网络服务，kerberos协议中不是所有的客户端向想要访问的网络服务发起请求，他就能够建立连接然后进行加密通信。而是在发起服务请求后必须先进行一系列的身份认证，包括客户端和服务端两方的双向认证，只有当通信双方都认证通过对方身份之后，才可以互相建立起连接，进行网络通信。即kerberos协议的侧重在于认证通信双方的身份，客户端需要确认即将访问的网络服务就是自己所想要访问的服务而不是一个伪造的服务器，而服务端需要确认这个客户端是一个身份真实，安全可靠的客户端，而不是一个想要进行恶意网络攻击的用户。本文将详细概述kerberos认证原理，讲述通信双方是如何一步步确认对方身份完成认证的。

DC(Domain Controller)：域控制器，简称DC，一台计算机，实现用户、计算机的统一管理。

KDC(Key Distribution Center)：秘钥分发中心，简称KDC，默认安装在域控里，包括AS和TGS。

AS(Authentication Service)：身份验证服务，简称AS，用于KDC对Client认证。

TGS(Ticket Grantng Service)：票据授予服务，简称TGS，用于KDC向Client和Server分发Session Key（临时秘钥）。

TGT(Ticket Granting Ticket)：认证票据，用于验证Client的身份

AD(Active Directory)：活动目录，简称AD，用于存储用户、用户组、域相关的信息。

Client：用户

Server：可以是某台计算机，也可以是某个域内服务

krbtgt用户：创建域控时自动生成的用户

在古希腊神话故事中，kerberos是一只具有三颗头颅的地狱恶犬，他守护在地狱之外，能够识别所有经此路过的亡灵，防止活着的入侵者闯入地狱。而真正的kerberos协议中也存在三个角色，分别是

    客户端（client）：发送请求的一方
    服务端（Server）：接收请求的一方
    密钥分发中心（Key Distribution Center，KDC），而密钥分发中心一般又分为两部分，分别是：
        AS（Authentication Server）：认证服务器，专门用来认证客户端的身份并发放客户用于访问TGS的TGT（票据授予票据）
        TGS（Ticket Granting Ticket）：票据授予服务器，用来发放整个认证过程以及客户端访问服务端时所需的服务授予票据（Ticket）

Kerberos认证解决”如何证明我就是我的问题“

上面说到了kerberos协议当中总共有三个不同的角色，客户端和服务端就不用多说了，一个是请求的发起者一个是请求的接收者，那么KDC是做什么的呢？答案是这样的~
在kerberos协议中，通信的双方在通信之前必须相互证明自己的身份是可靠并且具有访问权限的（后面会说为什么是要具有访问权限的），那么双方都要如何证明自己呢？口说无凭，客户端的请求中携带自己的身份
信息直接给服务端，服务端是没有理由直接信任这段信息就是真实的信息的，同理，服务端返回自己的身份信息给客户端，客户端也同样是无法辨别该服务器是否是自己想要访问的服务器。

举个例子，A现在想要去访问B完成一个任务。但是AB两人之间是从来没有见过面的，他们只知道对方的名字叫A，B。此时如果A直接去找B告诉B我就是A，那么B是有理由不相信A的，因为即使A是一个冒充的他也分辨不
清，B同理也得不到A的认可，他们陷入了一个无
法证明我就是我的困境。于是他们就想到了一个办法，AB找到了一个他俩共同信任的人C，且这个C既认识A又认识B，所以只要C告诉B，这个A确实就是真正的A那么B就会
信任这个A，同理B经过C的认可后，A也会相信B的身份。
此后，A在访问B之前会先去找C，C会交给A一个凭证，代表此时的A已经得到了C的认证，这时A拿着凭证再去找C，便可以得到C的确认了。

在上面的例子中，A，B分别是客户端和服务端，C担任的角色便是KDC，全称Key Distribution Center，中文名叫做密钥分发中心。KDC中包含一个叫做TGS（票据授予中心）的组件，我们便可以理解为他就是一个发放
身份认证票据的服务中心，在KDC认证了（其实是KDC中的AS认证的）客户端的身份后，他会给客户端发放用于访问网络服务的服务授予票据（Ticket）。由于整个kerberos通信过程都采用对称加密的方式，密钥的获取也是从KDC中得
到，所以KDC叫做密钥分发中心。

所以整个kerberos认证流程可以 简化描述 如下：

客户端在访问每个想要访问的网络服务时，他需要携带一个专门用于访问该服务并且能够证明自己身份的票据，当服务端收到了该票据他才能认定客户端身份正确，向客户端提供服务。所以整个认证流程可简化为两大步：

1. 客户端向KDC请求获取想要访问的目标服务的服务授予票据（Ticket）；

2. 客户端拿着从KDC获取的服务授予票据（Ticket）访问相应的网络服务；

上面说到了简化版的Kerberos认证流程，基本上分为两步。

第一步，客户端向KDC请求获得他想要访问的服务的服务授予票据（可以想象成去动物园，想去买一张能够进入动物园的门票）。

第二步，拿着这张服务授予票据（Ticket）去访问服务端的服务。

大致的过程确实可以看作这两步，但其中还存在一些问题：
问题1. KDC怎么知道你（客户端）就是真正的客户端？凭什么给你发放服务授予票据（Ticket）呢？
问题2. 服务端怎么知道你带来的服务授予票据（Ticket）就是一张真正的票据呢？

Kerberos认证流程

这就需要开始细节的描述一下整个Kerberos认证的过程了~

第一步：客户端向DC的AS请求

此时客户端本机的Kerberos服务会向KDC的AS认证服务发送AS-REQ认证请求，请求内容包括了客户端的个人信息即principal如用户名，以及说明要请求什么服务、目标服务的主机名等信息，也告诉AS自己将与TGS通信。除此之外为了防止别人伪造这个客户端的身份，还要求发送一个认证因子authenticator，这个认证因子需要使用客户端的hash来加密一个时间戳。

为什么需要用自己的hash加密时间戳？

因为如果不用客户端的hash进行加密，那么攻击者可以伪造任意客户端的身份进行Kerberos认证，但是加上客户端hash进行加密，DC再进行解密，这使得攻击者的攻击加大难度，只有获取了用户的hash才能伪造客户端的身份。另外DC是域控，肯定是有客户端的hash的。

时间戳的作用是什么？

是为了一定程度上防止攻击者进行重放攻击。请求接收方会对这个时间戳做一个验证，在请求发送到请求接收的一定时间内，假设为5分钟，在这5分钟内接收方收到了请求，那么就相信其为安全的请求，反之如果超过了5分钟则怀疑受到了重放攻击。

第二步：DC的AS向客户端的请求做出响应

此时AS收到了客户端的请求之后，由于AS是在DC上面的，DC是有客户端的hash的，此时会查询AD目录找到该客户端的hash，然后对时间戳进行解密，如果解密失败说明用于加密的hash是错误的，同时验证是否为受到了重放攻击。
在AS验证通过之后，AS会生成一个login session key，并且使用用户的hash加密这个login session key，然后AS还会生成一个TGT，同使用过hash加密后的login session key以及一些其他相关信息打包发送给客户端。

什么是TGT？

是Kerberos认证中的一种加密票据，是由Kerberos认证服务器（AS）生成并加密的，该TGT包含了用户的身份信息、有效期限、密钥（login session key）和其他相关信息，不过这些信息是使用的krbtgt的hash进行加密的，不在是用户的hash了。

什么是krbtgt？

krbtgt是Kerberos中的一个特殊账户，用于存储和管理Ticket Granting  Ticket（TGT）。

在Kerberos认证系统中，krbtgt账户是一个系统级别的账户，用于生成TGT和使用自己的hash（krbtgt  hash）加密TGT，并提供给用户进行身份验证和获取服务票据。

那么如果攻击者获取到了这个hash（krbtgt  hash），那么就可以任意的伪造TGT了，也就是黄金票据

黄金票据，攻击者获取到了这个hash（krbtgt hash），可以任意的伪造TGT了，可以跳过AS验证了。

为什么TGT要用krbtgt的hash加密？

因为在攻击者未获取krbtgt的hash时，使用krbtgt的哈希加密可以防止TGT在传输过程中被篡改或伪造。如果使用明文，还可能被中间人窃取数据包，获取一些敏感信息。

第三步：客户端向DC的TGS请求

此时客户端收到了DC的的响应包之后会将收到的TGT存储在本地，并使用自己的hash将对应使用自己的hash加密的信息进行解密，获取到AS生成的login session key，然后客户端使用login session key去加密时间戳然后与收到的TGT、需要的服务名字、自己的相关信息一同打包发送到DC的TGS。

为什么客户端收到TGT之后还要发送回去？

客户端发送TGT是发送给TGS的，在AS发送给客户端TGT之后，客户端需要将其发给TGS之后，TGS才会给客户端授予服务票据。

为什么客户端收到TGT之后要存储起来？

因为TGT是具有时效性的，不是永久的，也不是一次性的。只要在TGT过期之前，可以直接请求TGS申请服务票据，而不用在每次访问服务的时候都向AS请求TGT，减少了与AS的通信，提高了系统的性能和效率。

第四步：DC的TGS向客户端的请求做出响应

当TGS接收到请求之后，会检查自身是否存在客户端请求的服务，如果存在就会拿ktbtgt hash解密TGT（由于TGS是在DC上的，所有具有krbtgt的hash），解密到的信息中包含了login session key，别忘了客户端发过来的时间戳就是利用login session key加密的，此时就可以用其解密获取到时间戳了，然后验证时间戳。
然后KDC会生成一个新的名叫service session key，用于客户端和服务端直接的安全通信，并且为客户端生成ST服务票据，该票据是由客户端信息+service session key打包后用后用服务端的hash加密的（KDC在DC上，故DC拥有服务端的hash）。除此之外会将service session key用之前是login session key加密同ST一同打包发送给客户端。

为什么service session key要用login session key加密？

因为是service session key是要发给客户端的，客户端拥有login session key，可以解密后获取到service session key，也保证了service session key的安全性。

为什么要生成一个service session key？

这个是为了用于接下来的客户端与服务端的安全通信，作用类似于login session key。

为什么要用服务端的hash加密service session key？

因为为了保证service session key不被窃取不可明文传输且后期客户端和服务端要使用service session key进行安全通信，而服务端没有login session key，DC就使用服务端的hash进行加密，同时还可以防止非目标服务器窃取这个service session  key，因为只有知道服务端的hash才能获取service session key，进一步保证了service session  key的安全。
如果攻击者窃取了服务端的hash那么就可以任意伪造ST也就是白银票据了，就可以不经过KDC了。

白银票据，攻击者窃取了服务端的hash，可以不经过KDC。

第五步：客户端向服务端请求

此时客户端接收到了TGS的响应，然后利用login session key解密获取到service session key，然后用于与服务端通信，同时将ST存储起来，然后客户端用service session key加密客户端信息和时间戳同ST（服务端hash加密的相关信息+service session key）打包一起发送给服务端验证。

第六步：服务端向DC的KDC的请求

客户端收到服务端发送过来的信息之后，用自己的hash即服务端hash解密ST，而ST中包括有service session key，那么再用service session key去解密使用service session key加密的信息包括有客户端相关信息和时间戳，再去验证这个时间戳，判断是否安全，判断是否为真实身份。
除此之外服务端还要向DC请求，使用PAC（Privilege Attribute Certificate）将客户端的属性信息发送给KDC进行验证客户端是否安全是否具有获取该服务的资格。

什么是PAC？

PAC是一个包含了客户端属性信息的数据结构，它包括了客户端的授权信息、组成员资格和其他相关属性。服务端在收到客户端的票据后，会从票据中提取出PAC，并将其发送给KDC进行验证。

验证过程是什么？

1.服务端从客户端的票据中提取出PAC。
2.服务端将PAC发送给KDC，请求对客户端的属性信息进行验证。
3.KDC收到PAC后，会验证其中的属性信息是否与KDC中存储的客户端属性信息一致。
4.如果属性信息一致，KDC将返回一个验证成功的响应给服务端。
5.服务端根据KDC的响应，判断客户端的属性信息是否有效，并根据需要进行授权或其他操作。

第七步：DC的KDC向服务端响应

此时KDC将会对服务端发来的PAC进行一个验证，验证流程如下

1.KDC首先会检查PAC中的票据（Ticket）是否有效，即检查票据的签名是否正确、是否过期等。这是基本的票据验证过程，确保票据本身是合法的。
2.KDC会从PAC中提取出客户端的属性信息，如授权信息、组成员资格等。
3.KDC会与自身存储的客户端属性信息进行比对，以验证PAC中的属性信息是否与KDC中存储的信息一致。这样可以确保客户端的属性信息没有被篡改或伪造。
4.如果PAC中的属性信息与KDC中存储的信息一致，KDC将认为PAC是有效的，并返回一个验证成功的响应给服务端。反之如果PAC中的属性信息与KDC中存储的信息不一致，KDC将认为PAC是无效的，并返回一个验证失败的响应给服务端。

第八步：服务端向客户端响应

此时服务端会生成一个票据，该票据包括客户端身份信息，以及服务端的身份信息，并使用之前获得的service session key去加密该票据信息并发送给客户端，然后客户端就可以正常获取到服务端的服务了。

为什么要使用service session key去加密该票据信息？

因为之前KDS已经给客户端发送过了service session key，而service session key就是用来二者安全通信的，故客户端可以使用service session  key去解密获取到票据信息。service session key加密同时也保障了票据信息不被窃取和修改伪造。

Kerberos总流程