难逢敌手Kerberos

目录

前文简介

Windows域：

接下来，进入正题！

第一步：账号A和KDC相互认证

第二步：账号A请KDC帮忙认证资源B

第三步：账号A和资源B相互认证：

---

前文简介

非常有意思的一个协议，其名字Kerberos来源于古希腊神话中的地狱看门犬刻耳柏洛斯（Cerberus）。刻耳柏洛斯住在冥河岸边（在希腊神话中，死人在进入冥界时要先乘坐卡戎划的船渡过冥河），为冥王哈迪斯看守冥界的大门。刻耳柏洛斯允许每一个死者的灵魂进入冥界，但不让任何人出去（同时也不允许活人出入）。因此在希腊神话与罗马神话中只有寥寥数人从冥界生还。

本文要介绍的身份认证协议Kerberos有着非常广泛的应用，最常见的应用当属Windows域环境的身份验证。在我们使用域账号登里电脑使，就不知不觉的完成了一次Kerberos认证。

Windows域：

Windows域是计算机网络的一种形式，其中所有用户账户 ，计算机，打印机和其他安全主体都在位于称为域控制器的一个或多个中央计算机集群上的中央数据库中注册。 身份验证在域控制器上进行。 在域中使用计算机的每个人都会收到一个唯一的用户帐户，然后可以为该帐户分配对该域内资源的访问权限。

Kerberos的认证是双向的：当账号A访问资源B时，不但B要确保A并非冒充，A也要查明B不是假货。人们应该不会质疑自己要访问的资源的假的，但后者是有必要被确认的。Kerberos的做法是引用一个权威的第三方来负责身份验证，KDC，它知道域里所有账号和资源的密码，假如账号A要访问资源B，只需要把KDC拉出来认证双方身份就可以了，A和B在认证阶段无需直接进行交流，直接依赖于KDC就可以了。

接下来，进入正题！

第一步：账号A和KDC相互认证

首先是关于身份验证的问题：我如何才能知道你真的是你。身份验证是密码学关注的一个大问题。接头暗号、帐号密码都是解决身份鉴别问题的办法。在互联网上，“用户名/密码”模式是最常见的用户身份鉴别模式。但这里出现了一个前面没有出现过的严峻问题：如何防止第三方截获？有人可能会脱口而出：把密码加个密发出去？A计算密码的md5值并发送出去KDC接收到该md5值并与自己机器上预先算出来的md5结果进行比较。数据以md5的形式进行传输，即使被第三方截获也能保证密码安全。其实，这种方法仍然是不可靠的，原因在于，鉴别问题和消息泄露问题有着本质的区别。在前面的消息传输一例中，为了防止第三方截取者，我们采用了消息加密的方法，避免第三者获取原始信息；而这里，第三方截取者根本就不需要知道你的原始信息是什么，只要照着你发的信息发就是了。如果我想假冒你，只要知道了密码的md5值就可以模拟发送相同的数据包；这个md5值就已经成为了开门的钥匙，你的真实密码是什么对我根本不重要。况且这种办法也无法进行双向认证，A有可能会直接把开门钥匙发送给了一个冒牌货。所以普通的加密是行不通的，Kerberos有着更为复杂且优雅的验证方式。

1. 账号A把密码hash成一把密钥，称之为Kclt
2. 用Kclt把当前时间戳加密，生成一个字符串，用“{时间戳}Kclt“来表示
3. 把上一步生成的字符串 “{时间戳}Kclt“，账号A的信息和一段随机字符串发送给KDC，把上面三个信息打包发送给KDC的东西组成了Kerberos的身份认证请求AS_REQ

   AS_REQ = “{时间戳}Kclt“ ,“账号A的信息”, “随机字符串”

4. KDC收到AS_REQ之后，先读到账号A的信息，于是就调出A的密码，再用同样的hash函数把密码转化为Kclt。然后就可以解开“{时间戳}Kclt“了，如果能解开就说明请求是真正的账号A发送来的，因为其他账号没有Kclt可以加密

   在这里刹一下车，考虑为什么要选用时间戳来进行加密？这和我前面说过的，防止第三方来截获你的开门钥匙“{时间戳}Kclt“进行重放攻击，因为这个过程需要耗费一点时间，所以KDC把解密到的时间戳和现在的时间做个对比，相差过大就可以被认定为是重放攻击了。KDC会对请求回复拒绝访问

5. 接下来轮到KDC向账号A证明自己的身份，KDC只需要把账号A发送过来的随机字符串用Kclt加密，在回复给账号A就可以证明自己的身份了。只要账号A解密出来的字符串和自己发送的一样，那对方就是正牌KDC了。
6. 第五步是一个只存在于理论上的模型，真正的过程是略有不同的，因为每次认证都需要调出密码，hash，解密，这样对KDC的会有很大的负担，本身KDC做的只有保存密码的工作。接下来是Kerberos对于算法更优雅的一种优化
7. KDC生成两把一模一样的密钥Kclt-Kdc，其中一把要发送给账号A保管，另外一包委托给账户A保管，以后每次需要验证的时候再把密钥还回来，尽可能的减少KDC自身的工作负担。KDC把自己的密码hash成Kkdc，然后用它加密委托给账号A的那把密钥，称之为TGT。

   TGT = {账户A的相关信息，Kclt-kdc}Kkdc

8. 总结下来，KDC回复给账户A的AS_REP包涵：

   AS_REP = TGT，{Kclt-kdc,时间戳,随机字符串}Kclt

9. 账号A收到AS-REP之后用Kclt解密{Kclt-kdc,时间戳,随机字符串}Kclt。通过字符串和时间戳来确定KDC的真实性，然后把kclt-kdc和TGT保存备用。

第二步：账号A请KDC帮忙认证资源B

1. 第一步肯定先要把TGT还给KDC的，还有自己的信息和要访问的资源B的信息，称之为TGS- REQ，总结一下就是：

   TGS_REQ = TGT，{账户A的信息，时间戳}kclt-kdc，资源B的相关信息

2. KDC收到TGS- REQ之后先用Kkdc解密TGT得到Kclt-kdc，再用Kclt-kdc解密账号A的相关信息和时间戳来验证身份，一旦认证账号A为真，就需要充当第三方来帮忙认证双方了。
3. KDC生成两把同样的密钥供A和B之间使用，称之为Kclt-srv，其中一把直接交付给账号A，Kerberos把B的密码hash成Ksrv，然后加密另外一把Kclt-srv，委托账号A转交给资源B。这个称之为Ticket，只有B才能解密。把上面信息打包形成TGS- REP，总结下来：

   Ticket = {账号A的信息，Kclt-srv}Ksrv

   TGS_REP = {Kclt-srv}Kclt-kdc，Ticket

4. 账号A收到TGS_REP之后，先用Kclt-kdc解密{Kclt-srv}Kclt-kdc，得到Kclt-srv。Ticket发送给资源B。如果之后还要频繁访问资源B的话也只需要使用同一个Ticket从而降低KDC的负担。

第三步：账号A和资源B相互认证：

1. 几经波折，A和B终于鹊桥相会，但是在此之前，还是有必要确认一下对方是不是自己真正的梦中人。By the way，账号A给资源B发送 {账号A的信息，时间戳}Kclt-srv，和上一步收到的Ticket，这个过程称之为AP_REQ。总结：

   AP_REQ =  {账号A的信息，时间戳}Kclt-srv，Ticket

2. 如果资源B是真的，那这个时候就可以把自己的密码hash成Ksrv来解密Ticket，从而得到Kclt-srv。之后再用Kclt-srv来解开 {账号A的信息，时间戳}Kclt-srv，这样资源B便能确认账号A为真，然后回复AP_REP来证明自己也是真的

   AP_REP = {时间戳}Kclt-srv

3. 账号A再利用Kclt-srv来解密AP_REP来判断对方是否为真。

自此，鹊桥相会，互换资源。原理说起来这么困难，正常人此时的反应应该是云里雾里（建议多看几遍）事实上，程序实行起来——更加困难...正式因为Kerberos的复杂性才能够让安全得以保障。最文艺的Kerberos的诠释当属麻省理工学院出品的话剧。搜索引擎搜索一下“Kerberos四幕话剧”就能找到，不过还是偏干，建议自备茶水。毕竟，学习之路没有顺风顺水。