\r Kerberos,一个数据安全方面专业深奥的却又让人恨不得拿拖鞋拍死它的词，我们今天来一起揭开它的面纱······ \r

\r 首先声明，这是一篇非常严谨的科普文章，请认真的，带着思考进行阅读。 \r

\r \r

Kerberos这一词由来不得不追溯到希腊神话里三头狗的故事，它其实本名叫Cerberus（刻耳柏洛斯），发音是不是很像？\r

最开始的传说里它是有50个头的，后来雕刻工嫌麻烦就……\r

这只dog据说是希腊神话中恶魔王提丰的孩子，这个恶魔王的孩子都比较另类，除了这只dog以外，还有西游路上想吃唐僧肉的九头蛇，以及任何场合都能让人石化的美杜莎等等。这只dog既然不是善类，它肯定不是长这样：\r

\r

网上某百科说它长这样：\r

\r

\r

理论上应该比这样还丑吧，毕竟这张图看久了还有点顺眼了是不是？ \r

姑且不论其长什么样，但它的地位是的：那就是安全的守护者！它既防止活人进入冥界，又防止冥界的亡灵前往人间。 \r

Kerberos是由MIT研发的，对，就是那个和哈佛相爱相杀的MIT，不是下面这家伙（MT），不要搞错了。 \r

\r

\r

研发初衷是为了保护自己的网络服务器。 \r

的版本KerberosV1-V3都是在MIT内部发行使用，所以一直有深深的神秘感。KerberosV4在1980年推出商用，由于使用了DES加密算法，美国出口管制局就把Kerberos归为品禁止出口。 \r

\r

\r

为了打破这种局面，后来瑞典理工在V4版本上包装了一下，绕过了美国出口管制局，让其可以在美国境外发行使用。后来这群人可能觉得人生需要一个新的高度，于是又发明了KerberosV5的版本。 \r

\r

虽然我们现在广泛使用的也是KerberosV5的版本，但是可能和前面那个V5没什么关系。 \r

2000年美国修改了密码出口管理条例，MIT也看到Kerberos的巨大发展前景，于是在2007年专门又成立了Kerberos协会，以推动Kerberos的发展，至此Kerberos的指挥大棒又交回MIT，是不是有点像王老吉的发展历史？\r

\r

\r

Kerberos目前作为一套网络安全认证协议，是为了解决网络上一个“证明自己是自己”问题，让服务端和客户端建立相互信任机制。这个问题如果放到我们自己身上可能会很尴尬，如果你去去开这么一个证明是的证明，往往会这样： \r

\r

\r 那我们怎么证明自己是自己呢？\r

\r \r

\r 对于两个需要需要互相访问的客户端/服务端，它们也需要这么一个证件或者信物，证明它们可以相互信任。简单而言，它的场景是这样的： \r

\r \r

\r \r

\r 当然，Kerberos作为一款有着广泛使用基础，并且安全性的认证协议，其内部机制很复杂，接下来，我们就剖析一下Kerberos认证。 \r

\r
\r

\r \r

\r 在这个认证过程中，会有3个角色：KDC(key distribution center)、Client(客户端)、Server(服务端), 正好象征着三头狗的三个头(不要再纠结是三个头还是五十个头了！)。KDC是整个Kerberos认证的核心模块，负责存储密钥(长期和临时)以及进行认证。 \r

\r 另外，我们需要了解四个概念： \r

\r Long-Term Key: \r

\r 那些长期存储并且不会失效的数据信息； \r

\r Short-Time Key: \r

\r 临时存储的并且一段时间后就失效的数据信息； \r

\r Master Key: \r

\r 存储在KDC中用户标识身份信息的数据信息； \r

\r Session Key: \r

\r 在认证周期中使用到的数据信息，一旦超过认证周期，认证数据信息失效。 \r

\r 一般来说，Master Key属于Long-Term Key，这类信息长期存在KDC中，并且不会失效，无论是KDC自己，Client还是Server都有自己的Master Key. \r

\r Session Key属于Short-Time Key，其实是包含Master Key信息的临时拷贝，这类信息只在认证周期内有效，一旦认证期过，也就没用了。 \r

\r 大概两者就是正式工和临时工的区别吧。 \r

\r
\r

\r \r

\r 整个认证过程会用到Master Key和Session Key，但是认证过程复杂， 一个Kerberos认证过程要正常完成，需要有三个过程: \r

\r
\r

\r Authentication Service Exchange \r

\r (KRB_AS_REQ) \r

\r Client向KDC服务器获取TGT(Ticket Grant ing Ticket)，TGT是获取Service Ticket的基础许可票据，有此票据后可以在有效期内获得KDC中所有需要访问的Server Ticket。 \r

\r Ticket Granting Service Exchange \r

\r (KRB_TGS_REQ)： \r

\r Client向KDC获取Server Ticket（即Session Key），该Server Ticket用于后续Client与Server之间交互使用。 \r

\r Client/Server Exchange \r

\r (KRB_AP_REQ)： \r

\r Client向Server提交Client Info与Server Ticket（即Session Key）,Server端验证通过后，向Client提供服务。 \r

\r \r

\r 这里要注意一下，Server Ticket并不是由KDC直接发给Server端的，而是KDC发给Client, 并由Client转交给Server,这么做的好处是Server端不用维护一个Session列表，同时能够避免因网络问题引起KDC到Client和Server之间的通信问题。\r

\r 看完上面这几个过程，是不是感觉难以理解啊！ \r

\r
\r

\r \r

\r 为了便于理解，我们引入一个场景： \r

\r 一个IT人员出差忘记带了要住酒店。 \r

\r 这个场景中有以下信息： \r

\r KDC: 网内部身份认证系统 \r

\r Server: 酒店 \r

\r Client: 入住IT \r

\r Master Key: 网内的人员身份信息，酒店信息以及信息 \r

\r Session Key: 住宿临时明\r

\r 在这个场景中，酒店要让他入住的话，需要两个信息：入住人信息和证件。 \r

\r 正巧我们的苦逼IT忘记带了证件，他要顺利入住，必须先去部门开一个住宿临时证明，然后再回来办理。\r

\r 这可以分解为Kerberos的三个过程： \r

\r Authentication Service Exchange： \r

\r 户口登记，该人员(Client)必须在(KDC)有登记，有户籍信息（TGT），才能够开出相关证明，当然该户籍信息可能是长期的可能是短期的(例如集体户口)，但是TGT一般是周期比较短的。 \r

\r \r

\r Ticket Granting Service Exchange： \r

\r 临时住宿证明(Session Key)办理，该人员(Client)通过提交户籍信息(TGT),(KDC)查验后，给予其开具临时住宿证明(Session Key)。 \r

\r
\r

\r \r

\r Client/Server Exchange： \r

\r 该人员(Client)向酒店(Server)提交临时住宿证明(Session Key)和入住人信息(Client Info)，酒店(Server)办理入住。 \r

\r \r

\r
\r

\r 在理解以上内容中，需要有一些注意的地方：\r

\r 人员身份信息是Master Key,指的是姓名，出生日期，号这些不会变的东西；\r

\r 而户籍信息是TGT，除了Master Key的信息外，还附带了会变的住址，登记，登记时间等数据信息。\r

\r Kerberos认证过程是双向的，入住人员也可以向验证该酒店是否有登记，是否是黑店。\r

\r 实际的Kerberos过程比这个稍复杂，因为涉及到加密解密的操作。\r

\r Client端拿到的Session Key本身内容包含Client Info，而且是经过Server端Master Key加过密的。 \r

\r Server端在拿到Client提交的Session Key和Client Info以后，会对Session Key进行解密，将Session Key包含的Client Info与之前提交的进行对比，两者一致才予以放行。\r

\r Session Key有效期时间不会太长，一般默认都是8小时或者24小时。因为在网络上一旦被截获，有效期越长带来的解密风险越高，就越可能被篡改和替代。\r

\r 正是有如此复杂的内部过程，Kerberos的解决了网络上Client与Server信任的问题。当然Kerberos还有很多其他特性，我们后续再聊······\r

\r \r