一篇文章带你弄懂Kerberos的设计思路

川长思鸟来 2024-03-16 12:27 42阅读 0赞

这篇文章将会带大家详细梳理和理解Kerberos的设计思路。

Basic  
为了减轻服务器的负担，我们需要设计一个专门的认证服务器AS，储存所有用户的口令，认证了用户身份之后再通知应用服务器

引入ticket：客户把自己的ID（IDc)，要访问的服务器的ID (IDv) 和自己的口令 (Pc) 发给AS，AS查验用户和口令是否合法，是否有权访问V，都符合就给客户发一张ticket，客户凭借ticket和IDc去访问V

（用户网络地址）（用户网络地址）ticket=EKv\[IDc,ADc（用户网络地址）,IDv\]，ticket中包含的信息，谁的票，访问哪儿的票，这些信息用V与AS之间的共享密钥Kv加密，加密的同时也认证了AS（避免敌手假扮AS）

上述机制中还存在4个问题

Q1：访问多个服务器需要多次申请票据，多次输入口令会造成不安全

solution：

1.  引入票据许可服务器（TGS，类似售票处），**AS只认证**，认证之后发放票据许可票据（类似允许你买票的身份证明）Tickettgs，用来访问V的服务许可票据TicketV由TGS来发。这样ID和password就只在认证时使用1次
2.  一类V之间可以共享Kv和票据

Q2：口令明文传送（C->AS）

solution： AS与C之间共享用户口令Pc->Kc，AS与TGS之间共享Ktgs，TGS和V之间共享Kv，不用再发送口令

Q3：票据重用

solution：引入时间戳（TS，消息发送时间）和有效期（LT）

PS：时间戳和序列号可以保证消息的新鲜性，但很容易被预测，可以使用挑战-响应协议，用随机数来防止重用，但复杂度比较高

Q4：票据冒领

solution：给谁的信息就用谁的密钥来加密，防止被冒领

但是TGS没有Kc，C也没有Kv，于是就由AS来帮TGS和C之间生成Kc,tgs，TGS帮C和V生成Kc,v，同时，这两个密钥也要放到票据中，用来身份认证，防止敌手等到用户退出之后使用窃听到的票据备份进行重用

AS为TGS和C生成了Kc,tgs后，就连同Tickettgs一起发给C，TGS收到Tickettgs后，解密得到里面的Kc,tgs，然后回复C的消息就用Kc,tgs加密。

现在我们解决了以上四个问题，来梳理一下，现在的票据长啥样？

票据包含双方的ID，为双方生成的共享密钥，TS，TL，给谁的票据就用谁的密钥加密

Tickettgs=EKtgs\{Kc,tgs,IDc,ADc,IDtgs,TS2,LT2\}

更近一步的优化：C和V之间也要改成双向认证，C也要确认V的身份，TGS、V回复C的时候最外层就用会话密钥加密（信任第三方）

V回复C\{TS5+1\} ，用TS5（用户发送消息的时戳）可以保证每次都不一样，类似TCP的序列号，+1可以记录交互了多少次

最后我们就得到了Kerberos的整个流程：

![c2c7a8e60bedce8e68fc49d14850bff5.png][]

![ac3d0015dae0c0a05cece1c6655dc85d.png][]

[c2c7a8e60bedce8e68fc49d14850bff5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/e241dd8e7bbc4d1ca05cbb173df40599.png
[ac3d0015dae0c0a05cece1c6655dc85d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/7584cfeb561349d48fbb513011ca6687.png