当前位置： 首页 > news >正文

UCAS 24秋网络认证技术 CH15 Kerberos复习

news 2025/1/4 13:18:53

image.png
Key Distribution Center-KDC
image.png
基本流程可分为两大部分：初始认证 和 服务票据获取与使用。

  1. 初始认证
    1. Authenticate：客户端向认证服务器（Authentication Server，AS）发送请求以验证身份。
    2. Receive TGT：AS 验证成功后，返回一个 票据授权票据（Ticket Granting Ticket, TGT） 给客户端。TGT 包含用户的身份信息，并由 KDC（密钥分发中心）加密。
  2. 使用 TGT 获取服务票据
  3. Request Service Ticket：客户端使用 TGT，向票据授予服务器（Ticket Granting Server，TGS）请求特定服务的票据（Service Ticket）。
  4. Receive Service Ticket：TGS 验证 TGT 后，返回特定服务的票据（Service Ticket）。
  5. Get Service：客户端使用 Service Ticket 访问目标服务（Service Server）。
    image.png
    Kerberos 认证协议的整个流程，包括客户端、认证服务器（AS）、票据授予服务器（TGS）和目标服务（S）之间的交互，详细如下：

1. 初始认证阶段：Authentication Service Exchange

目标：客户端通过认证服务器（AS）验证身份并获取票据授权票据（TGT）。

  • 客户端发送 KRB_AS_REQ 请求给 AS：
    • 包含用户名（C）、TGS 服务名（T）、随机数（n1）等。
    • 消息主体加密使用客户端的主密钥（通常是基于用户密码生成的密钥）。
  • AS 响应 KRB_AS_REP：
    • 包含会话密钥（AK，用于客户端与 TGS 的通信）。
    • 包含 TGT（由 TGS 的主密钥加密，包含客户端 ID 和会话密钥 AK 等信息）。
    • 客户端使用自己的主密钥解密，获取会话密钥 AK 和 TGT。
      结果：客户端拥有一个会话密钥 AK 和一个 TGT，准备进入下一阶段。

2. 票据授予阶段：Ticket Granting Service Exchange

目标：客户端通过 TGS 获取访问目标服务所需的服务票据（ST）。
SK：用于Client和Server的会话密钥SServer-Client
tT: ST的有效期

  • 客户端发送 KRB_TGS_REQ 请求给 TGS：
    • 提供从 AS 获得的 TGT。
    • 提供一个认证器（Authenticator），使用会话密钥 AK 加密，包含客户端 ID 和时间戳。
    • 指定目标服务的名称（S）。
  • TGS 验证请求：
    • 使用 TGS 的主密钥解密 TGT，提取会话密钥 AK。
    • 使用 AK 验证 Authenticator，确保请求合法。
    • 如果验证成功，生成服务票据（ST）和会话密钥 SK。
  • TGS 响应 KRB_TGS_REP：
    • 包含服务票据（ST），由目标服务 S 的主密钥加密。
    • 包含会话密钥 SK，用于客户端和服务 S 的通信，使用 AK 加密。

结果：客户端获得了与目标服务 S 通信的会话密钥 SK 和服务票据 ST。

3. 客户端与服务的交互：Client/Server Exchange

目标：客户端使用服务票据与目标服务建立安全通信。

  • 客户端发送 KRB_AP_REQ 给目标服务 S：
    • 提供服务票据（ST）。
    • 提供一个 Authenticator，使用会话密钥 SK 加密，包含客户端 ID 和时间戳。
  • 服务验证请求：
    • 使用服务的主密钥解密 ST，提取会话密钥 SK。
    • 使用 SK 验证 Authenticator，确保请求合法。
    • 如果需要双向认证，服务会返回一个 KRB_AP_REP，加密一个新的时间戳，证明服务的身份。
      结果：客户端和服务之间通过会话密钥 SK 建立了安全通信，完成身份认证和服务访问。

总结

  1. Authentication Service Exchange（AS 认证阶段）：

    • 客户端获取 TGT 和与 TGS 通信的会话密钥 AK。

  2. Ticket Granting Service Exchange（TGS 票据授予阶段）：

    • 客户端获取与目标服务通信的会话密钥 SK 和服务票据 ST。

  3. Client/Server Exchange（客户端与服务交互阶段）：

    • 客户端通过服务票据和会话密钥与目标服务建立安全通信。

通过以上三步，Kerberos 实现了一个安全、可信的认证和授权过程，避免了在网络中直接传输密码，并且通过票据和密钥确保通信的安全性。

image.png
image.png

Kerberos 方案存在的问题及改进建议总结

问题 1: 长期密钥的安全性

  • 描述:

    • Kerberos 协议中，有些加密数据使用主体的长期密钥（Long-term Key）加密。
    • 长期密钥的加密数据如果在网络中传输，可能被窃取后破解。
    • 所有的加密算法都不能完全保证 100% 安全，破解加密数据只是时间问题。

  • 建议改进:

    • 使用短期密钥（Session Key）代替长期密钥加密传输的数据。
    • 如果恶意用户窃取到密钥，由于短期密钥的有效期较短，威胁会被降低。
问题 2: 服务端的安全威胁

  • 描述:

    • 客户端与服务交互时（C/S Exchange），服务票据（ST）是用服务器的主密钥加密的，但仍会在网络中传输。
    • 如果攻击者能够破解 ST，服务端的安全性将受到威胁。

  • 建议改进:

    • 增加 User-to-User 协议 来保护服务端，避免过多依赖服务端主密钥的加密。
    • 对客户端来说，长期密钥主要是用于生成票据授权票据（TGT），但实际上对客户端的直接影响有限。
总结性建议:
  • 在 Kerberos 的第一步（Authentication Service Exchange）中，可以通过改进设计方案来提升安全性，例如更广泛地使用会话密钥（AK/SK）来替代长期密钥。
  • 后续引入的 User-to-User 协议 和其他安全机制能够进一步降低因服务端密钥泄露带来的安全威胁。

通过以上改进，Kerberos 协议可以更好地应对网络攻击风险，提升整体安全性。
image.png
image.png
image.png
image.png

Kerberos 方案存在的问题

1. 长期密钥（Long-term Key）泄露风险
  • 问题：
    • 长期密钥加密的数据在网络中传输，存在被窃取并破解的风险。
    • 任何加密算法都不能完全保证 100% 安全，加密数据的破解只是时间问题。
  • 改进方案：
    • 尽量使用短期密钥（Session Key）代替长期密钥进行加密。
    • 如果恶意用户窃取到短期密钥，由于密钥会过期，风险可以显著降低。
2. 服务端安全威胁
  • 问题：
    • 服务票据（ST）由服务器的主密钥加密并在网络传输，可能威胁服务器的安全性。
    • 攻击者破解 ST 后，可以伪装为合法客户端与服务器通信。
  • 改进方案：
    • 引入 User2User 协议，通过 KDC 和服务端的配合来保护服务端的主密钥安全。
    • 实际上，客户端不直接接触服务器的长期密钥，仅通过会话密钥与服务器交互。

User2User 子协议

核心思路：
  • 利用 Server 与 KDC 之间的会话密钥（KDC-Server） 加密 ST，避免直接暴露服务器的长期密钥。
协议流程：

  1. AS Exchange（客户端获取 TGT）：

    • 客户端通过正常的 AS Exchange 获取属于自己的 TGT。

  2. User2User Protocol（客户端获取服务器的 TGT）：

    • 客户端在请求服务前，先向服务器请求。
    • 如果服务器已经存储有客户端所需的 TGT，则直接返回。
    • 否则，服务器通过 AS Exchange 向 KDC 请求，获取自己的 TGT。

  3. TGS Exchange（客户端与 TGS 交互获取服务票据 ST）：

    • 客户端通过 KDC 提供自己的 TGT，服务器的 TGT，以及 Authenticator，向 KDC 申请访问服务器的服务票据 ST。
    • KDC 验证客户端和服务器的 TGT，生成服务票据（ST），用 KDC-Server 密钥加密后返回客户端。

  4. C/S Exchange（客户端与服务器通信）：

    • 客户端携带加密的 ST 和 Authenticator 访问服务器。
    • 服务器使用会话密钥解密 ST，验证客户端身份后建立安全通信。

改进后的优势

  • 增强服务器安全性：
    • 服务票据（ST）由 KDC-Server 会话密钥加密，避免直接暴露服务器的长期密钥。
  • 减少长期密钥暴露风险：
    • 通过会话密钥（Session Key）代替长期密钥进行通信，加快密钥更新和失效处理。
  • 支持双向认证：
    • Server 可以通过 Authenticator 验证客户端身份，确保通信的安全性和可信性。

总结

通过 User2User 子协议 的引入，Kerberos 协议能够更好地保护服务器的长期密钥安全，同时通过会话密钥和双向认证机制，增强整个系统的抗攻击能力，进一步提高网络认证的安全性。
image.png
image.png

Kerberos 方案存在的问题 2：用户长期密钥暴露风险

问题描述
  • 用户长期密钥（主密钥 kc）来源：
    • 用户的长期密钥是通过用户的口令派生出来的。
  • 风险：
    1. 口令较短，容易受到字典攻击：
      • 如果用户的口令较短或简单，攻击者可以通过暴力破解或字典攻击获取主密钥 kc。
    2. AS 请求阶段的加密数据易受攻击：
      • 在 Kerberos 第一步 AS 认证中，AS 返回的数据是用主密钥加密的，如 {AK, n1, t_k}。
      • 攻击者可以截获这些加密数据并尝试用字典攻击解密，从而获取主密钥 kc。
    3. 字典攻击的后果：
      • 攻击者一旦破解 kc，就可以伪装为合法用户，获取访问服务的权限。
应对措施：预认证（Pre-authentication）
  1. 方案：
    • 在客户端发送认证请求（KRB_AS_REQ）之前，要求客户端先进行预认证。
    • 具体流程：
      • 客户端使用自己的主密钥（kc）加密一个随机值或时间戳，发送给认证服务器（AS）。
      • 认证服务器验证该加密值，确认客户端身份。
      • 只有通过预认证的请求，AS 才会返回加密的 TGT 和会话密钥。
  2. 优势：
    • 增加了一个客户端主动认证步骤，防止恶意用户伪造认证请求。
    • 有效减少了攻击者通过拦截 AS 响应并破解主密钥的可能性。
  3. 局限性：
    • 用户口令仍然可能被暴力破解，但预认证增加了攻击的复杂性，降低了风险。
*补充说明
  • Server 与 KDC 的交互中也存在类似风险：
    • 服务端在向 KDC 请求 TGT 时，可能也使用其长期密钥加密。
    • 攻击者可能尝试通过暴力破解服务端的长期密钥，模拟服务端的行为。
  • 应对方法：
    • 同样可以通过预认证步骤，要求服务端证明自身身份，确保请求的合法性。

总结

  • 问题核心：
    • 用户和服务端的长期密钥（主密钥）如果基于弱口令生成，可能被字典攻击或暴力破解。
  • 解决方案：
    • 引入预认证（Pre-authentication），通过主动验证客户端或服务端身份，增强协议的安全性。
  • 效果：
    • 降低攻击者获取主密钥的可能性，从而保护整个 Kerberos 认证流程的安全性。

image.png

PKINIT：基于公钥的 Kerberos 认证机制

PKINIT（Public Key Cryptography for Initial Authentication in Kerberos）是一种扩展 Kerberos 的认证机制，利用公钥加密技术来增强初始认证阶段的安全性。以下是其主要特点和流程总结：

PKINIT 的两种工作模式

  1. Public-key Encryption Mode（公钥加密模式）：

    • 使用公私钥对（pkC, skC 和 pkS, skS）进行签名和加密。
    • 提供数据加密和完整性验证功能。

  2. Diffie–Hellman (DH) Mode：

    • 使用公私钥对配合 Diffie–Hellman 密钥交换协议来生成共享密钥。
    • 支持数字签名，保护通信中的对称密钥（AK）。

Public-key Encryption Mode（公钥加密模式）

1. PKINIT 的消息结构

PKINIT 的消息部分增加了传统 Kerberos 所没有的内容：

  • 证书（CertC）：
    • 客户端的公钥证书，用于 AS 验证客户端身份。
  • 数字签名：
    • 客户端对时间戳 tc 和随机数 n2 的签名，用于证明身份和支持预认证。
  • 加密部分：
    • 使用 AS 的公钥（pkAS）对签名和随机数加密，确保传输安全。
2. 客户端发送请求消息

客户端向 AS 发送初始请求，包含以下内容：

  • 新增加部分：
    • 客户端证书 CertC。
    • 数字签名 [tc, n2]skC，用于预认证。
    • 加密后的签名 {{[tc, n2]skC}pkAS}，确保机密性。
  • Kerberos 原有部分：
    • 客户端 ID（C）、目标服务类型（T）、随机数（n1）。
3. AS 验证并生成会话密钥

AS 收到客户端请求后，进行如下操作：

  • 验证客户端证书 CertC 的合法性。
  • 解密并验证客户端签名 [tc, n2]skC，确认客户端身份。
  • 生成临时保护密钥（k），对会话密钥 AK 进行保护。
  • 响应内容：
    • 新增部分：
      • {{CertX, [k, n2]skX}pkC}，用客户端公钥加密的临时保护密钥和验证数据。
    • 原有部分：
      • TGT、加密的会话密钥 AK。
4. 客户端解密并获取 AK

客户端收到 AS 的响应后，执行以下操作：

  • 使用私钥 skC 解密 {{CertX, [k, n2]skX}pkC}，提取临时保护密钥 k 和验证数据。
  • 使用解密后的保护密钥 k 解密会话密钥 AK，并获得 TGT。
  • 完成认证后，客户端携带 TGT 和 AK 进入下一步与 TGS 的交互。

总结

  • PKINIT 的核心是利用公钥加密技术取代传统 Kerberos 中基于长期密钥（kc）的认证方式。
  • 通过引入证书、签名和保护密钥（k），PKINIT 在提高初始认证阶段安全性的同时，简化了客户端与 AS 之间的密钥分发过程，为 Kerberos 提供了更强大的防御机制。

PKINIT 的中间人攻击及其危害分析

1. 中间人攻击假设

  • 攻击者被 AS 识别为合法的 Kerberos 客户端，AS 会接受其请求。
  • 攻击者持有一个有效证书 CertA，并且该证书受 KDC 信任。
  • 攻击者可以拦截和替换消息，例如将 CertC 替换为 CertA。
  • PKINIT 使用 public-key encryption mode。

2. 中间人攻击的实施

攻击流程
  1. 攻击者截获客户端发送的消息，并将消息中的客户端证书 CertC 替换为攻击者证书 CertA。
  2. AS 在接收到消息后，用攻击者的公钥解密，并生成对称密钥 AK，同时生成 TGT 和其他认证信息。
  3. AS 将消息返回给攻击者，攻击者收到响应后获取 AK 和 TGT。
  4. 攻击者使用 AK 和伪造的 TGT 与 TGS 或其他服务进行交互，冒充合法客户端。
后果
  • 客户端视角：
    • 客户端以为自己通过了 AS 的验证，并获取了合法的 TGT（实际上攻击者拦截了返回消息）。
  • AS 视角：
    • AS 以为成功验证了客户端身份，但实际上返回的 TGT 是给攻击者的。
  • 攻击者：
    • 攻击者知道 AK 和 TGT，可解密客户端后续的通信内容。

3. 攻击的危害

危害 1：攻击者截获并转发消息
  • 攻击者持有 AK 和 TGT，可以与 TGS 通信，获取访问服务所需的服务票据（ST）。
  • 攻击者伪造 Authenticator，替换身份信息后发起服务请求。
  • 攻击者能够：
    1. 截获 CS Exchange 中的所有数据包。
    2. 解密并修改这些数据，冒充客户端与服务交互。
危害 2：攻击者伪装 TGS 或终端服务
  • 攻击者使用截获的 AK 和 TGT 与 TGS 通信，生成伪造的 ST。
  • 在 CS Exchange 中，攻击者可以伪装为服务端与客户端通信，或者伪装为客户端与服务通信。
  • 攻击者可以解密客户端的 Authenticator，进一步冒充合法用户与服务端交互。

4. 攻击的总结与限制

混合攻击模式
  • 攻击者可以采用两种策略：
    1. TGS Exchange 中充当中间人，截获并转发消息。
    2. CS Exchange 中伪装终端服务，冒充客户端或服务。
攻击限制
  • 假如攻击者试图在 TGS Exchange 中伪造合法的 ST，但没有服务端的主密钥（SKS），则无法创建合法的 ST。
  • 服务票据（ST）依赖于服务端的主密钥加密，没有服务端密钥，攻击者无法生成合法票据。

6. 总结

  • PKINIT 的中间人攻击主要利用了消息的替换漏洞（如伪造证书和替换密钥）。
  • 攻击的危害在于攻击者能够获取客户端的会话密钥（AK）和伪造身份。
  • 防御措施需要加强证书验证、双向身份认证和消息完整性保护。

改进方法：PKINIT 攻击的修复方案

问题产生的原因
  • 在 PKINIT 中，中间人攻击能够成功的核心原因在于：
    • 客户端无法验证 AS 返回的会话密钥（AK）和 TGT 是不是专门为自己生成的。
    • 攻击者可以截获并修改客户端与 AS 的交互消息。

改进方法 1：Abstract Fix

  1. 指导思想：

    • 在 AS 返回给客户端的消息中，加入客户端的身份标识（例如 C）。
    • 客户端能够识别返回的消息中是否包含自己的身份，从而确认消息的合法性。

  2. 实现方式：

    • 在返回消息中，将客户端身份 C 和随机数 ni 结合形成函数 F 的输出。
      • 示例：F(C, ni) = F(C', n1')，若 F 中的身份与客户端不匹配，则客户端可以检测出异常。
    • 使用 AS 的私钥对内容签名，确保消息完整性。

  3. 消息修改：

    • 将 {CertC, [k, F(C, ni)]skX}pkC 包含在 AS 的返回消息中。
    • 客户端验证 AS 的签名，并检查身份是否匹配。

  4. 效果：

    • 中间人无法篡改消息，因为签名和身份绑定。
    • 客户端能够确认返回的会话密钥和 TGT 是为自己生成的。

改进方法 2：Checksum-based Fix

  1. 背景：
    • 这种方法在 PKINIT Version 27 及其后续版本中被广泛采用。
    • 指导思想与 Abstract Fix 类似，但对客户端身份的校验基于一个不可伪造的校验和。
  2. 实现方式：
    • AS 使用 ck = Hk(CertC, [tc, n2]skC, C, T, n1) 生成校验和 ck，并将其加入到返回的消息中。
      • H 是一个不可逆的消息认证函数（MAC），例如 HMAC-SHA1-96。
      • 攻击者无法生成合法的校验和，确保消息的真实性和完整性。
  3. RFC 3961 规范：
    • Kerberos 5 中规定了常用的 HMAC 算法，如 hmac-sha1-96-aes128。
  4. 效果：
    • 客户端验证校验和 ck 后，能够确认返回的消息确实是为自己生成的。
    • 消息完整性通过 MAC 确保，中间人无法篡改。

总结

  • Abstract Fix 和 Checksum-based Fix 都有效地解决了中间人攻击的问题。
  • 核心思路是通过绑定客户端身份（C）和返回消息内容，并通过签名或校验和确保消息的完整性和真实性。
  • Checksum-based Fix 由于使用标准化的 MAC 函数，成为实际中广泛使用的解决方案。

http://www.mrgr.cn/news/82141.html

相关文章：

  • Springboot - Web
  • Spring实现输出带动态标签的日志
  • LLM（十二）| DeepSeek-V3 技术报告深度解读——开源模型的巅峰之作
  • 基于SpringBoot+Vue实现的在线点餐小程序【源码+文档+部署讲解】
  • 【PCIe 总线及设备入门学习专栏 4.1 -- PCI 总线的地址空间分配】
  • SpringBootWeb AOP
  • leetcode之hot100---148排序链表（C++）
  • pg_wal 目录下 wal 日志文件异常累积过大
  • ACE之ACE_Message_Queue
  • 2、pycharm常用快捷命令和配置【持续更新中】
  • GPT分区 使用parted标准分区划分，以及相邻分区扩容
  • [羊城杯 2024]不一样的数据库_2
  • ultralytics库RT-DETR代码解析
  • 创建型设计模式、结构型设计模式与行为型设计模式 上下文任务通用方案 设计模式 大全
  • Unity Excel转Json编辑器工具
  • GeekPad 智慧屏连接到VirtualBox的Ubuntu虚拟机上的Home-Assistant
  • 曾仕强解读《易经》
  • win32汇编环境下，对话框程序中生成listview列表控件，点击标题栏自动排序的示例
  • canvas+fabric实现时间刻度尺(一)
  • C进阶-字符串与内存函数介绍（另加2道典型面试题）
  • Oracle 11g 中 MODEL语法使用 详解
  • 2024年度学习总结
  • Linux 内核调试
  • 30天开发操作系统 第 10 天 -- 叠加处理
  • GRAPE——RLHF微调VLA模型：通过偏好对齐提升机器人策略的泛化能力(含24年具身模型汇总)
  • win32汇编环境下，提取对话框程序中，listview列表控件里的内容示例