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
来说是比较麻烦而低效的