基于对称加密的密钥分配和Kerberos认证

基于对称加密的密钥分配和Kerberos认证

对于对称加密，加密双方必须共享同一密钥，而且必须保护密钥不被他人读取。此外，常常需要频繁地改变密钥来减少某个攻击者可能知道密钥带来的数据泄露。因此，任何密码系统的强度都取决于密钥分发技术。密钥分发技术指的是将密钥传递给希望安全交换私密数据的双方，且不允许其他人看见密钥的方法。

密钥分发能用很多方法实现，对 A 和 B 双方，有下列选择：

1. A 能够选定密钥并通过物理方法传递给 B；
2. 第三方 C 可以选定密钥并通过物理方法传递给 A 和 B；
3. 如果 A 和 B 不久之前使用过一个密钥，一方能够把使用旧密钥加密过的新密钥传递给另一方；
4. 如果 A 和 B 各自有一个到达第三方 C 的加密链路，C 能够在加密链路上分别传递新密钥给 A 和 B。

第1、2种方法的物理方法指的是手动地交换密钥（比如邮寄纸质密钥文件、飞鸽传书…），对于链路层加密是合理可行的。因为每个链路层加密设备只和此链路另一端的设备交换数据，因此，链路层加密并不需要大量地、频繁地生成并交换密钥。但是对于端到端加密来说，物理方法显然是笨拙的。在分布式系统中，任何主机或终端都可能需要不断地和许多其他的主机或终端进行通信，因此每个设备都需要大量的动态供应的密钥。

第3种方法对于链路层加密和端到端加密都是可行的，但是如果攻击者成功地获得了一个密钥，那么接下来的所有新密钥都暴露了。为端到端加密，第4种方法更可取。

第4种方法需要一个密钥分发中心（key distribution center KDC），KDC判断哪些系统或主机允许互相通信，当两个系统或主机被允许建立连接时，KDC就为这条连接提供一个唯一的一次性会话密钥（session key）。

这个自动密钥分发方法提供了允许大量终端用户访问大量主机及主机间交换数据所需要的灵活性和动态特性。实现这一方法最广泛的一种应用就是 $Kerberos$ 认证。

一、Kerberos 介绍

---

Kerberos 是一种认证服务，这种认证服务作为 Athena 计划的一个组成部分，由 MIT 开发。Kerberos 要解决的问题是：假设在一个开放的分布式环境中，工作站的用户希望访问分布在网络各处的服务器上的服务。在这个环境中，让一个工作站去正确地对网络服务识别用户是靠不住的想法，特别是存在以下三种威胁：

1. 一个用户可能进入一个特定的工作站，并冒充使用这个工作站的其他用户；
2. 一个用户可能改变一个工作站 A 的网络地址来冒充另一个工作站 B，是的从 A 发出的请求好像是从 B 发出的；
3. 一个工作站可能窃听数据交换，并使用重放攻击来获取连接服务器，或是破坏正常操作。

在以上任何一种情况下，一个非授权用户都可能获得他没有被授权得到的服务和数据。 $Kerberos$ 没有采取在每个服务器设立细致认证协议的方法，而是利用集中的认证服务器来实现用户对服务器的认证和服务器对用户的认证。值得说明的是，Kerberos 仅依赖于对称加密体制，而不使用公钥加密体制。

目前常用的 Kerberos 有两个版本，版本4虽然被逐渐淘汰，但仍然被采用和认可；版本5修正了一些版本4的安全缺陷，已经被发布为RFC标准。考虑到 Kerberos 的复杂性，本文仅介绍 Kerberos 版本4，先不去考虑一些解决微妙安全威胁的细节。

二、Kerberos 认证核心思想

---

在一个没有受保护的开放网络环境中，服务器为了保证只给被授权的客户端提供服务，必须要能够确定请求服务的客户端的身份，但如果每个服务器都被要求来承担客户端和服务器之间交互时确定用户身份的任务，会给服务器增加很多负担。

$Kerberos$ 的核心思想是，使用集中的认证服务器（authentication server, AS），它知道所有用户的口令，并把它们存储在集中式数据库中。另外，AS 和每个服务器之间也共享一个独立的密钥。这些密钥已经从物理途径或其他安全途径进行了分发。

考虑下面这个假定的会话：

$$C \rightarrow AS: \,ID_c \, || \, P_c\, || \, ID_v \tag1$$
$$AS \rightarrow C: \, Ticket,\,\,\,Ticket=E(K_v,[ID_C\,||\,AD_C\,||\,ID_v]) \tag2$$
$$C \rightarrow V: \, ID_c \, || \, Ticket \tag3$$

（1） 式表示客户端将客户端用户身份标识、客户端用户口令、请求访问的服务器身份标识串接成消息发送给认证服务器。

（2）式表示认证服务器 $AS$ 在查看集中的认证数据库，确认客户端 $C$ 已经被授权可以访问服务器 $V$ 之后，将客户端 $C$ 请求服务器 $V$ 的票据发送给 $C$。从（2）式可以看到，这个票据是将客户端身份标识、客户端网络地址、服务器身份标识的串接消息用服务器 $V$ 和认证服务器 $AS$ 共享的密钥 $K_v$ 加密过的，用户 $C$ 获得之后仅可以用来证明自己获得了授权许可来请求 $V$ 的服务，而并不能篡改它，同样，攻击者截获这个票据也不能篡改其中的身份或地址信息来进行攻击。

（3）式表示客户端 $C$ 将自己的客户端用户身份标识和获得的票据串接的消息发送给服务器 $V$，让服务器 $V$ 来验证身份。服务器 $V$ 用自己和 $AS$ 共享的密钥 $K_v$ 来解密票据，对比票据中包含的客户端身份标识 $ID_c$ 、客户端网络地址 $AD_c$ 以及请求服务器的身份标识 $ID_v$ 是否和请求匹配，如果匹配，服务器 $V$ 则认为这个请求来自的用户是被授权的，并准许其获得服务。

这个会话包含了 $Kerberos$ 认证的核心思想，即通过一个认证服务器 $AS$ 来认证用户并分发票据。但是仅靠这三个简单步骤是无法让服务器相信服务请求的消息真正来自被授权的 “$C$”。

首先，步骤一中，用户 $C$ 的口令 $P_c$ 是串接在明文消息中发送给认证服务器 $AS$ 的，这在开放网络环境中意味着攻击者可以轻而易举地获得 $P_c$、$ID_c$，只要攻击者伪装成真实客户端的网络地址 $AD_c$ （这是相当容易实现的），他就可以假冒 $C$ 向 $AS$ 请求授权获取服务器的服务票据。

其次，因为票据 $Ticket$ 也是明文发送给客户端 $C$ 的，且没有设置有效时间戳，因此为了保证票据认证的有效性，这种票据只能是一次性会话有效的，否则攻击者截获这个明文票据之后，也可以轻而易举地冒充用户 $C$ 来请求服务。那么用户 $C$ 在早上登录客户端来查看邮件，输入口令来得到一个邮件服务器的票据，如果用户 $C$ 想多次检查邮箱的更新，就要反复输入口令来获取票据，这无疑是不方便的。

三、一个更安全的认证会话

---

为了解决上一节中的会话方案中遗留的一些问题，我们引入一个避免明文传输密钥的方案，和一个称谓票据授权服务器（Ticket-Granting Server TGS）的新服务器。

先让我来看看整个认证会话方案的实现：

1. 每次用户登录会话就会执行一次以下步骤：
   

   $$C \rightarrow AS: ID_c \, || \, ID_{tgs} \tag1$$
   $$AS \rightarrow C: E(K_c,Ticket_{tgs}) \tag2$$

2. 用户请求每个尚未获得服务票据的服务器就会执行一次以下步骤：
   

   $$C \rightarrow TGS: ID_c \, || \, ID_v \, || \, Ticket_{tgs} \tag3$$
   $$TGS \rightarrow C: Ticket_v \tag4$$

3. 每次用户向服务器请求服务就会执行一次以下步骤：