🪴 Cyril

kerberos 协议

17分钟阅读

定义

先来明确一些关键术语及其英文全称和缩写，这有助于我们更好地理解其背后的原理逻辑。

  1. 认证 (Authentication)：验证用户或服务身份的过程，确保他们是自己声称的那个人或服务。
  2. 授权 (Authorization)：确定经过身份验证的用户或服务是否有权访问特定资源或执行特定操作的过程。Kerberos 主要关注认证，授权通常由应用程序或服务本身处理。
  3. 密钥分发中心 (Key Distribution Center, KDC)：Kerberos 协议的核心组件，负责管理用户的密钥和颁发票据。KDC 通常包含两个逻辑部分：
    • 认证服务器 (Authentication Server, AS)：验证用户的初始身份，并为通过验证的用户颁发票据授予票据（Ticket-Granting Ticket, TGT）。
    • 票据授予服务器 (Ticket-Granting Server, TGS)：使用 TGT 为用户颁发访问特定服务的服务票据（Service Ticket）。
  4. 票据 (Ticket)：一种包含客户端身份信息、会话密钥以及其他信息的加密数据结构，用于向服务证明用户的身份。
  5. 票据授予票据 (Ticket-Granting Ticket, TGT)：由认证服务器颁发给用户的临时凭据，用于向票据授予服务器请求访问特定服务的服务票据。
  6. 服务票据 (Service Ticket)：由票据授予服务器颁发给用户的临时凭据，用于向特定的目标服务进行身份验证。
  7. 用户 C 和 服务器 V

发展逻辑

在早期的网络环境中，身份验证通常依赖于用户每次访问服务的时候提供用户名和密码，这种方式有很多缺点：

  • 安全风险大 密码在网络中传输的时候容易被截获（尤其是粗心的程序员和垃圾的实现方式），或者在存储服务器上就泄露了
  • 管理复杂 用户需要记住多个服务的不同密码，服务也需要管理大量用户的凭据（想要一个谷歌账户就能登录所有网站这种感觉）
  • 缺乏相互认证 客户端没有办法知道自己连接的是不是我想要的那个服务，服务也没有办法确定客户端的身份（上了一个假的大麦）

kerberos 协议的目标就是解决上面的问题，它的核心思想是引入一个可信的第三方（KDC）来管理身份验证的过程，从而避免直接在客户端和服务器之间传递敏感数据，并且提供权威的认证服务。

工作原理

kerberos 的工作原理基于密钥加密和票据机制

密钥加密

每一个主体都和 KDC 共享一个只有他们自己和 KDC 知道的密钥。用户的密钥通常基于其密码产生，服务的密钥是预先配置好的。这些密钥用来传递消息。（先别管怎么放密钥的）

票据机制

用户在首次登录的时候和 KDC 的认证服务器 AS 证明自己的身份（通常通过输入密码，这个密码只用这一次，类似于登录谷歌账号，之后不在网络中传输了），AS 验证用户的身份之后，会颁发一个 TGT（Ticket-Granting Ticket）给用户（类似于在这台电脑上记住我的登录状态）。

这个 TGT 包含了用户的身份信息和一个会话密钥，上面的过程使用 KDC 和用户的共享密钥进行加密传输，这个 TGT 是用 AS 和 TGS 加密过的。用户在访问特定服务的时候，会把这个密钥提交给 KDC 的票据授予服务器 TGS，TGS 会验证 TGT 的有效性，如果有效，则发一个 ST（Service Ticket）给用户。

这个服务票据包含了用户的身份信息和一个新的会话密钥，并且使用 KDC 和目标服务 V 的共享密钥进行加密。（类似于谷歌弹出来一个 authorize 界面，里面有服务的名称和共享的信息——这个服务肯定先和 google 注册了，即共享密钥了）。用户之后把这个 ST 发送给目标服务，服务用自己和 KDC 共享的密钥解密票据，验证用户的身份，获得和用户进行安全通信的会话密钥。

通过这种方式，用户只用记一个密码，就能在一个有效期内在不同服务之间直接登录，并且不用担心自己访问了一个假的服务。

但是，考虑到重放攻击等，要做一定的增强：

  • 一开始用户发给 AS 的消息要一个时间戳，防止重放攻击
  • AS 回复给用户的 TGT 中要包含一个生存时间，定义 TGT 的有效期（微信登录唉），过期之后需要重新验证（防止设备不是你的设备了）
  • 类似的，后面 TGS 发给客户的 ST 也要一个生存时间
  • 用户向 TGS 请求 ST 的时候，除了发送 TGT，也要发送一个认证器 。认证器通常包括用户的身份信息和当前的时间戳，并使用客户和 KDC 的会话密钥加密，
  • 类似的，后面和服务器 V 发起请求的时候的时候，除了发送 ST 之外，也要发送 ，这个认证器使用客户和 V 之间的密钥进行加密
  • V 在成功验证用户身份之后，通常会向用户 C 发送一个可选的验证器 ，这个认证器包含时间戳，并且使用客户端和 V 之间的会话密钥进行加密，这样就实现了有明确返回信息的相互认证。

再谈会话密钥的传递～全流程

需要提前配置好的东西有：AS 和 TGS 之间要有共享密钥，AS 自己要有用户 ID 和对应散列口令之类的数据库，TGS 要有和服务器 V 提前注册搞定共享密钥。也就是 AS 要知道 TGS 的长期密钥，AS 能查到用户 C 的长期密钥，TGS 能查到某个服务 V 的长期密钥。

  • AS 和客户 AS 和客户之间可以没有啥会话密钥，但是可以这么搞：发给 AS 的是一个自己 C 的 ID，然后 AS 那边直接通过 ID 找到这个 ID 的加盐散列口令（用户长期密钥 ），然后用这个作为发回去打包的密钥，这只有知道自己口令的 C 才能解开。然后 AS 会做两件事：
    • 颁发 TGT：TGT 本身包含用户的身份信息，TGS 的身份信息，C 和 TGS 之间的会话密钥和一个生存时间，整个东西 AS 会使用 TGS 的长期密钥加密
    • 发送加密消息给用户：将 C 和 TGS 之间的会话密钥，用户身份信息，TGS 身份信息，时间戳和 TGT 用 AS 用用户的长期密钥 加密发回去
  • TGS 和客户 这里的 TGS 和用户之间的会话密钥从 AS 发回来的内容中有了。
    • C 向 TGS 请求的内容包括：想要的服务 V 的身份信息、TGT、一个认证器（包括用户信息、时间戳，这个使用 C 和 TGS 之间的会话密钥加密）
    • TGS 收到请求后：使用自己的长期密钥解密 TGT，从而获得会话密钥和用户的身份信息。通过解密得到的会话密钥解密认证器，验证用户的身份和请求的新鲜性。如果成功，则生成一个 C 和 V 之间的会话密钥。然后 TGS 会做两件事：
      • 颁发 ST：ST 包括用户的身份信息、目标服务的身份信息、C 和 V 的会话密钥和一个生存时间（和之前一模一样嘛），这个 ST 会使用 V 的长期密钥加密
      • 发送加密消息给用户：把 C 和 V 的会话密钥、目标服务的身份信息、时间戳和 ST 用 TGS 和客户的会话密钥加密传回去
  • C 和 V 和上面同理，会话密钥让 TGS 生成了。
    • C 向 V 请求的内容有：ST 和一个认证器（包括用户信息、时间戳，这个使用 C 和 V 之间的会话密钥加密）
    • V 收到请求之后，使用自己的长期密钥解密 ST 得到会话密钥和用户的身份信息。通过解密得到的会话密钥解密认证器，验证用户身份和请求的新鲜性（又是一样的）。如果成功，则最后把时间戳用会话密钥加密回去（双向认证）

因为是在网络中的传输，所以可以在票据和认证器中需要加上网络地址，防止票据被转发或者在不正确的网络环境中使用。

AS 在颁发 TGT 的时候，它会将客户端的网络地址记录在 TGT 中，然后 TGS 收到 TGT 时，会检查客户端来源的网络地址是否和 TGT 中的相符，如果不相符，则可能意味着票据在被其他主机使用或者网络环境发生变化，可以拒绝这个请求。类似的 TGS 颁发的 ST 也可以这样，

在认证器中也可以包含客户端的网络地址，服务器在验证认证器的时候，可以再一次核对客户端的地址。

可能的攻击

如果是上面这么实现的话，一种可能的攻击是口令的离线猜测攻击：攻击者可以冒充 C 执行协议的第一步，从而获得用户长期密钥加密后的消息。收到这个消息之后，就可以离线，没有限制的去猜测口令（批量）。

Transclude of kerberos.canvas

旧笔记

Kerberos 的核心目标

  1. ​避免明文传输密码：用户密码不会直接通过网络传输。
  2. ​防止重放攻击：通过时间戳和票据有效期限制攻击窗口。
  3. ​单点登录（SSO）​：用户只需登录一次即可访问多个服务。

核心角色与组件

  1. ​客户端（Client）​：需要访问服务的用户或设备。
  2. ​服务端（Server）​：提供服务的资源（如文件服务器、邮件服务器等）。
  3. ​密钥分发中心（KDC, Key Distribution Center）​：
    • ​认证服务（AS, Authentication Server）​：验证用户身份，颁发初始票据（TGT）。
    • ​票据授予服务（TGS, Ticket Granting Server）​：基于 TGT 颁发访问具体服务的票据。

Kerberos 是一种用于计算机网络中身份认证的协议，旨在通过加密和可信第三方（KDC，密钥分发中心）的帮助，在非安全网络环境下实现安全的身份验证。它由 MIT 开发，名字来源于希腊神话中的三头犬，象征其三方协作的机制（客户端、服务端、认证中心）。

​Kerberos 认证流程（简化版）​

  1. ​用户登录请求：
    • 用户输入用户名和密码，客户端将密码转换为加密密钥​（用户密钥）。
    • 客户端向认证服务器 AS 发送认证请求（明文用户名）。
  2. ​获取 TGT（Ticket Granting Ticket）​：
    • AS 验证用户是否存在，生成TGT​（包含用户身份、时间戳、有效期等），用KDC 的密钥加密。
    • AS 同时生成一个临时会话密钥​（用户 -KDC 会话密钥），用用户密钥加密后发送给客户端。
    • 客户端用用户密钥解密得到会话密钥和 TGT（但无法解密 TGT 内容）。
  3. ​请求服务票据：
    • 客户端向 TGS 发送请求，包含：
      • 目标服务名（如文件服务器）。
      • 加密的 TGT（用 KDC 密钥加密）。
      • 认证符（Authenticator）：用会话密钥加密的用户身份和时间戳。
    • TGS 解密 TGT，验证用户身份和有效期，生成服务票据​（用服务端密钥加密）和一个服务会话密钥​（用户 - 服务端会话密钥），用会话密钥加密后返回给客户端。
  4. ​访问服务：
    • 客户端向服务端发送请求，包含：
      • 服务票据（用服务端密钥加密）。
      • 新的认证符（用服务会话密钥加密的时间戳）。
    • 服务端解密服务票据，获取服务会话密钥，验证认证符的时间戳和有效期。
    • （可选）服务端向客户端发送确认信息，完成双向认证。

关键机制

  1. ​票据（Ticket）​：
    • 票据许可票据 TGT（ticket granting ticket）和服务许可票据 SGT(Server Granting Ticket) 均由 KDC 颁发，包含用户身份、会话密钥、有效期等信息。
    • 客户端无法篡改票据，因为它们用 KDC 或服务端的密钥加密。
  2. ​时间戳（Timestamp）​：
    • 所有票据和认证符都包含时间戳，防止重放攻击。
    • 系统需要严格时间同步（通常通过 NTP 协议）。
  3. ​加密保护：
    • 使用对称加密（如 AES），依赖预共享密钥（用户密钥、KDC 密钥、服务端密钥）。

关系图谱

最近笔记

反向链接