Kerberos认证原理

Kerberos 认证原理

去年做hadoop的时候使用kerberos，现在来整理一下它的原理，不对的地方请见谅

 

一、 基本原理

Authentication 解决的其实是 如何证明你就是你说的那个人 的问题，对于如何进行 Authentication ，一半采用这样的方法：如果一个秘密（ Secret ）仅仅存在于 A 和 B ，那么有个人对 B 声称自己就是 A ， B 通过让 A 提供这个秘密来证明这个人就是他或她所声称的 A ，相当于局限于两个人所知道的口令一样。这个过程涉及到三个 Authentication 方面：

 

•   Secret 如何表示

•   A 一开始是如何向 B 提供这个 Secret 的

•   B 又是如何识别这个 Secert 的

 

基于这三个方面，对 Kerberos Authentication 进行简化，整个过程涉及到 Client 和 Server ，他们之间的 Secret 用 Key （ Kserver-client ）来表示， Client 为了让 Server 对自己进行有效认证，提供以下两组信息：

 

•    代表 Client 的 identity 的信息，为了简便，它以明文的形式进行传递

•    将 Client 的 identity 使用 Kserver-client 作为公钥 public key 、并且采用 对称加密算法 进行加密

 

因为 Kserver-client 仅仅只被 Client 和 Server 知晓，所以被 Client 使用 Kserver-client 加密过的 Client Identity 只能被 Client 和 Server 解密， Server 接受到这两组信息，先对后面的这条信息使用相对应的 Kserver-client 进行解密，然后将机密的信息与前面的一条信息进行比较，如果一致，可以证明这个 Client 能够提供正确的 Kserver-client ，而这个世界上仅仅只有这个 Client 和 Server 知道这个 Kserver-client ，所以对方就是他声称的那个人。

Kerberos 基本上就是按照这样一种原理来进行 Authencation 认证的，但是 kerberos 远远比这个要复杂的多，为了后面更方面理解，先引入两个概念：

•    Long-term Key/Master Key ：在Security 安全的领域中，有的Key 可能长期内保持不变，比如你在密码，可能几年都不曾改变，这样的 Key 、以及由此派生的 Key 被称为 Long-term Key 。对于 Long-term Key 的使用有这样的原则：被 Long-term Key 加密的数据不应该在网络上传输。原因很简单，一旦这些被 Long-term Key 加密的数据包被恶意的网络监听者截获，在原则上，只要有充足的时间，他是可以通过计算获得你用于加密的 Long-term Key 的 —— 任何加密算法都不可能做到绝对保密。

 

在一般情况下，对于一个Account 来说，密码往往仅仅限于该 Account 的所有者知晓，甚至对于任何 Domain 的 Administrator ，密码仍然应该是保密的。但是密码却又是证明身份的凭据，所以必须通过基于你密码的派生的信息来证明用户的真实身份，在这种情况下，一般将你的密码进行 Hash 运算得到一个 Hash code, 我们一般管这样的 Hash Code 叫做 Master Key 。由于Hash Algorithm （哈希算法）是不可逆的，同时保证密码和Master Key 是一一对应的，这样既保证了你密码的保密性，有同时保证你的 Master Key 和密码本身在证明你身份的时候具有相同的效力。

 

•    Short-term Key/Session Key ：由于被Long-term Key 加密的数据包不能用于网络传送，所以我们使用另一种 Short-term Key 来加密需要进行网络传输的数据。由于这种 Key 只在一段时间内有效，即使被加密的数据包被黑客截获，等他把 Key 计算出来的时候，这个 Key 早就已经过期了。

 

二、 引入 Key Distribution （密钥分发）： Kserver-client 从何而来

第一节展示了 Kerberos 的 Authentication 的基本原理，通过让被认证的一方提供一个仅限于他和认证方知晓的 Key 来鉴定对方的真实身份。而被这个 Key 加密的数据包需要在 Client 和 Server 之间传送，所以这个 Key 不能是一个Long-term Key ，而只可能是 Short-term Key ，这个可以仅仅在 Client 和 Server 的一个 Session （会话）中有效，所以我们称这个Key 为 Client 和 Server 之间的 Session Key （ SServer-Client ）。

 

   那么 Client 和 Server 是如何获取这个 SServer-Client 的，需要引入一个重要的角色： Kerberos Distribution Center-KDC 。 KDC 在整个 Kerberos Authentication 中作为 Client 和 Server 共同信任的第三方起着重要的作用，而 Kerberos 的认证过程就是通过这 3 方协作完成。顺便说一下， Kerberos 起源于希腊神话，是一支守护着冥界长着 3 个头颅的神犬，在 keberos Authentication 中， Kerberos 的 3 个头颅代表中认证过程中涉及的 3 方： Client 、 Server 和 KDC 。

 

个人打个比方，你钥匙忘记在了家里，这时候你叫来了一个开锁工人，开锁工人需要你提供相关证件证明这个房子就是你的才会去开门，可是你身上只有一张身份证，开锁工人可以肯定你是你所声明的那个人，但是并不能证明这个房子是你的，这时候你拿着身份证去你们两个人都信任的警察局，警察局根据你提供的身份证，先确认你是你声明的那个人，然后通过公安系统去查询你声明的那套房子是否是你的（这一步相当于解开根据你身份证所隐藏的其他信息），如果一致，这时候开锁工人就会帮你去开门。

 

对于一个 Windows Domain 来说，Domain Controller 扮演着 KDC 的角色。 KDC 维护着一个存储着该 Domain 中所有帐户的 Account Database （一般地，这个 Account Database 由 AD 来维护），也就是说，他知道属于每个 Account 的名称和派生于该 Account Password 的 Master Key 。而用于 Client 和 Server 相互认证的 SServer-Client 就是有KDC 分发。下面我们来看看 KDC 分发 SServer-Client 的过程。

 

通过下图我们可以看到 KDC 分发 SServer-Client 的简单的过程：首先 Client 向 KDC 发送一个对 SServer-Client 的申请。这个申请的内容可以简单概括为“ 我是某个 Client ，我需要一个 Session Key 用于访问某个 Server ” 。 KDC 在接收到这个请求的时候，生成一个 Session Key ，为了保证这个 Session Key 仅仅限于发送请求的 Client 和他希望访问的 Server 知晓， KDC 会为这个 Session Key 生成两个 Copy ，分别被 Client 和 Server 使用。然后从 Account database 中提取Client 和 Server 的 Master Key 分别对这两个 Copy 进行对称加密。对于后者，和 Session Key 一起被加密的还包含关于 Client 的一些信息。

 

KDC 现在有了两个分别被 Client 和 Server 的 Master Key 加密过的 Session Key ，这两个Session Key 如何分别被 Client 和 Server 获得呢？也许你 马上会说， KDC 直接将这两个加密过的包发送给 Client 和 Server 不就可以了吗，但是如果这样做，对于 Server 来说会出现下面 两个问题：

•    由于一个Server 会面对若干不同的 Client, 而每个 Client 都具有一个不同的 Session Key 。那么 Server 就会为所有的 Client 维护这样一个 Session Key 的列表，这样做对于 Server 来说是比较麻烦而低效的