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

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

Basic

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

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

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

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

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

solution：

1. 引入票据许可服务器（TGS，类似售票处），AS只认证，认证之后发放票据许可票据（类似允许你买票的身份证明）\(Ticket_{tgs}\)，用来访问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之间生成\(K_{c,tgs}\)，TGS帮C和V生成\(K_{c,v}\)，同时，这两个密钥也要放到票据中，用来身份认证，防止敌手等到用户退出之后使用窃听到的票据备份进行重用

AS为TGS和C生成了\(K_{c,tgs}\)后，就连同\(Ticket_{tgs}\)一起发给C，TGS收到\(Ticket_{tgs}\)后，解密得到里面的\(K_{c,tgs}\)，然后回复C的消息就用\(K_{c,tgs}\)加密。

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

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

\(Ticket_{tgs}=E_{Ktgs}\{Kc,tgs, IDc, ADc, IDtgs, TS_2, LT_2\}\)

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

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

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