最近在做CTF的时候遇到了Kerberos，血妈烦，同样的东西不同的命名。在这里做个简单记录。

如上图所示，假设Client要向Server进行通信，为了保障安全性必须要向KDC [Key Distribution Center]申请一个TGT [Ticket Granting Ticket]，为了方便理解，可以当成去公园玩，在公园售票处购买[通票]的过程。注意：在KDC中，执行这部操作的服务为TGS [Ticket Granting Service]。

为了确保发送的数据[AS_REQ]只有自己以及KDC知道，所以数据的主体部分用自己[Client]的私钥进行加密。其中主体部分含有自己的身份信息。

不用担心，KDC当中包含有所有Account的私钥的DataBase。

KDC中的AS [Authentication Service],接收到[AS_REQ]之后，为了确认数据是否来自真实Client，会调用数据库中的Client的私钥进行解密，如果解密成功且得到的身份信息和数据库中的信息一致，则返回一个Response数据[AS_REP]。而这个数据中又包含两个部分：

用Client私钥加密的[Session Key]以及用自己(也就是KDC)私钥加密的[TGT]。

[successbox title=”TGT中包含”]

[Session Key]

[Client name & realm]: 简单地说就是Domain name\Client 。[Clinet的名字]

[End time]: TGT到期的时间。

[/successbox]

将包含二者的数据[AS_REP]返回给Client之后，Client使用自己的私钥解密也得到未加密的[Session Key]。此时我们的Client已经拥有了去公园玩的通票[TGT]。

有了[TGT]以后便可以向KDC请求访问Server。[有了通票以后就可以开始玩]

这一步我们叫做TGS（Ticket Granting Service）Exchange。拿到数据后我们向
KDC中的TGS [Ticket Granting Service]发送Request数据[TGS_REQ]。

[successbox title=”TGS_REQ中包括”]

[TGT]

[Authenticator]:用以证明当初[TGT]的拥有者是否就是自己，所以用自己得到的[Session Key]来进行加密。

[Client name & realm]: 简单地说就是Domain name\Client。[Clinet的名字]

[Server name & realm]: 简单地说就是Domain name\Server。[我要游玩项目的名字]

[/successbox]

TGS收到这些数据以后，要先看看你的TGT是不是自己的AS颁发的，验证的办法是使用自己(KDS)的私钥解密TGT，因为上文中说到TGT内包含有[Session Key]，再用此[Session Key]来解密数据。若解密成功，则发送Response[TGS_REP]

[successbox title=”TGS_REP中包括”]

用[Session Key]加密的包含有Client和Server通信的[S_Session Key]

以及用Server的私钥加密的[Ticket]

[infobox title=”Ticket中包括”]

[S_Session Key]

[Client name & realm]: 简单地说就是Domain name\Client 。[Clinet的名字]

[End time]: Ticket到期的时间。

[/infobox]

[/successbox]

当Client拿到返回数据以后解密获得[S_Session Key]和[Ticket]，用上述证明自己就是TGT的拥有着的方式证明自己拥有该Ticket也就是创建[Authenticator]，然后[S_Session Key]加密，然后将[Ticket]和[Authenticator]发送给Server[AP_REQ]

Server收到数据以后用自己的私钥解开Ticket获得[S_Session Key]，使用它解开发送来的[Authenticator]，进行身份验证。验证成功，让Client访问需要访问的资源，否则直接拒绝对方的请求。

然而这道CTF的题目。。就是暴力破解返回的[TGS_REP]中的Server私钥。。

[PS:真的。。很麻烦]

参考链接：https://blog.csdn.net/wulantian/article/details/42418231