pki

本文最后更新于：2025年1月1日 晚上

PKI系统功能——证书撤销：如何主动撤销？

在公钥基础设施（PKI）系统中，证书的撤销是确保系统安全性的重要功能。当一个证书不再有效或被认为不可信时，需要撤销该证书。撤销证书的方式可以有不同的实现方式，主要分为以下几个方面：

1. 撤销方式：离线 vs. 在线

离线（发布撤销声明）

  • 定义：离线撤销通常指的是证书撤销信息以某种方式发布（如通过撤销列表），而不需要实时查询操作。
  • 工作原理：当证书需要被撤销时，撤销者将证书信息加入到证书撤销列表（CRL, Certificate Revocation List）中。用户或应用程序可以定期下载此CRL文件，查看哪些证书被撤销。
  • 优点：
    • 减少对在线查询服务的依赖。
    • 用户可以离线访问撤销信息。
  • 缺点：
    • CRL可能会较大，更新频率有限，存在滞后性。
    • 用户未及时下载最新CRL，可能会错过最新的撤销信息。

在线（提供查询服务）

  • 定义：在线撤销则依赖于实时查询服务来确认证书的有效性，最常见的实现方式是通过在线证书状态协议（OCSP, Online Certificate Status Protocol）。

  • 工作原理：当需要验证证书是否被撤销时，客户端可以通过OCSP查询服务器，服务器会立即返回证书是否有效的信息。

  • 优点：

    • 实时更新证书撤销状态，查询结果精确及时。
    • 适用于高安全性要求的环境。

  • 缺点

    ：

    • 需要持续的网络连接。
    • 依赖在线查询服务的可用性，如果服务中断，会影响证书验证。

2. 白名单 vs. 黑名单

白名单

  • 定义：白名单是在撤销机制中，列出了哪些证书或实体是被信任的。这些证书被认为是有效的，其他没有列出的证书默认视为无效。

  • 应用场景：适用于需要高度可信的环境，例如政府机构、金融行业等，常常只允许白名单中的证书通过验证。

  • 优点

    ：

    • 可信度高，能够有效防止恶意证书的使用。
    • 可以减少查验和撤销操作的频率，简化管理。

  • 缺点

    ：

    • 需要精确维护和更新，白名单中任何的遗漏都会带来安全风险。
    • 不适合动态变化的环境，因为新的可信证书要通过严格的审查和批准。

黑名单

  • 定义：黑名单列出了被撤销的证书或被认为不可信的实体，只有在证书被列入黑名单时，它才被认为无效或撤销。
  • 应用场景：适用于动态更新和频繁撤销的环境，例如商业应用中，证书被撤销后会直接加入黑名单。
  • 优点：
    • 更新灵活，撤销证书的过程较为简单。
    • 适用于证书较多、撤销频繁的情况。
  • 缺点：
    • 黑名单可能会变得庞大，增加查询和维护的复杂度。
    • 如果黑名单更新不及时，可能会导致已经撤销的证书仍然被信任。

总结

  • 离线撤销适合于无需实时验证的场景，维护成本较低，但存在更新滞后性。在线撤销则适用于高安全要求的应用，提供实时的撤销状态查询，但需要稳定的网络连接。
  • 白名单适合高度可信的环境，但维护较为严格；而黑名单适用于证书动态撤销场景，更新灵活，但可能导致黑名单信息量增大，需要更频繁的更新和查询服务。

通过结合这些撤销机制和管理策略，PKI系统能够有效地维护证书的可信性与安全性。

信任模型——层次化信任：设计与潜在问题

在公钥基础设施（PKI）中，层次化信任模型是最常见的信任体系结构之一。通过引入分级的权威和证书链，层次化信任模型实现了可扩展的信任管理。然而，这一模型也带来了一些需要关注的潜在问题，尤其是对根权威（Root Authority）的依赖。

1. 为什么需要层次化信任？

  • 单一CA认证的局限性：
    • 由单一的认证机构（CA）对所有公钥进行认证在实际中难以实现，因其需要处理大量证书的签发、管理和验证。
    • 单点失败：一旦单一CA失效，整个系统的信任链将崩溃。
  • 层次化信任模型的引入：
    • 通过设立“根权威”（Root Authority），信任从根权威逐级传递至下一级权威和最终用户。
    • 每一级认证机构（Subordinate CA）只负责自己授权范围内的证书，分散管理负担。

2. 层次化信任的关键设计

根权威（Root Authority）

  • 根权威是整个信任模型的顶层，其公钥被视为整个体系中唯一无需额外验证的“信任锚”。
  • 所有人必须知晓用于验证根权威签名的公钥：
    • 用户和系统内置了根权威的公钥，例如操作系统和浏览器中存储的“受信任的根证书”列表。
    • 例如：DNS根区的KSK（密钥签名密钥）用来验证DNS根区数据的真实性。

证书链

  • 根权威通过为下一级权威（如子CA）颁发证书，将信任传递到下级机构。
  • 下级机构再为具体的实体或用户签发证书，以形成完整的证书链。
    • 例如：
      • 根权威签署子CA：sigCERNET("HIT", PKHIT)
      • 子CA签署用户证书：sigHIT("CS", PKCS)
    • 验证时，用户从根权威的公钥开始验证证书链中的每一级签名。

3. 层次化信任的优点

  • 可扩展性：通过分级认证机构实现分布式管理，大大减少了根权威的工作量。
  • 灵活性：各级认证机构可以独立管理自己的信任范围，提高系统灵活性。
  • 提高效率：根权威只需要维护有限数量的下级CA，而不直接管理所有用户。

4. 潜在问题：根权威出问题怎么办？

问题描述

根权威作为信任模型的基础，一旦发生问题，可能会导致整个信任体系的崩溃。以下是常见的威胁：

  1. 根权威密钥泄露：
    • 攻击者可利用泄露的根密钥签发虚假证书，导致整个体系的信任崩溃。
  2. 根权威过期或失效：
    • 如果根权威的密钥到期而未及时更新，可能导致所有依赖其签发的证书无法验证。
  3. 根权威遭受攻击：
    • 网络攻击或物理攻击可能导致根权威服务中断，影响证书的验证和签发。

5. 应对根权威问题的策略

多根权威模型

  • 设置多个根权威作为备份或互相独立的信任来源。
  • 即使一个根权威失效，其他根权威仍然可以维持信任体系。

密钥轮换机制

  • 定期更换根权威的密钥，并通过安全渠道分发新密钥。
  • 引入后备密钥（Backup Key）以应对主密钥泄露或失效。

证书吊销与撤销机制

  • 一旦根权威密钥泄露，应迅速通过全球范围内的证书吊销机制撤销相关证书。

根权威透明性与监控

  • 利用证书透明性（Certificate Transparency，CT）技术，对所有证书签发记录进行公开和实时监控。
  • 提前发现根权威的异常行为，降低风险。

分布式信任模型的引入

  • 在某些场景中，使用分布式信任模型（如区块链）替代单一的根权威，将信任分布在多个节点上，避免单点失效。

总结

  • 层次化信任模型通过分级管理和证书链有效解决了信任分发的问题，但其核心在于根权威的安全性。
  • 如果根权威失效，将严重威胁整个信任体系的稳定性。 通过引入多根权威、密钥轮换、证书透明性等机制，可以有效降低这一风险，同时增强整个系统的鲁棒性。

层次化信任 vs. 网状信任：对比与总结

特性 层次化信任 网状信任
结构 树状结构，单一根CA 有向图，去中心化
信任传播 自上而下传递，逐级验证 点对点传播，信任路径灵活
管理复杂度 简单，中心化管理 复杂，用户需手动管理信任关系
安全性 高，依赖于权威CA的可信度 不稳定，依赖节点间的信任
灵活性 较低，信任路径固定 高，可自由选择信任路径
单点失效风险 存在单点失效风险（根CA失效可能导致全局信任崩溃） 无单点失效风险（信任路径分布在多个节点上）
应用场景 HTTPS、企业PKI、政府电子政务 PGP、区块链、社交网络、小型网络

桥信任模型 vs 网状信任模型

特性 桥信任模型 网状信任模型
复杂度 低，信任关系由桥CA管理 高，每个CA需要与其他CA逐一交叉认证
扩展性 高，新根CA只需与桥CA认证 低，新根CA需要与所有现有CA认证
信任锚 保留原始信任锚，桥CA不干预内部信任体系 每个节点独立选择信任关系
适用场景 跨域互操作、跨机构PKI体系 小型网络、去中心化系统
优势 减少证书签发工作量，提升扩展性 灵活，可自由选择信任路径
管理模式 中心化的桥CA管理 去中心化节点管理

Web信任模型、垄断信任模型、寡头信任模型 和 无政府信任模型：

特性 Web信任模型 垄断信任模型 寡头信任模型 无政府信任模型
信任锚 浏览器内置多个根CA证书 单一CA，被视为世界上唯一的信任锚 多个根CA，预置于系统或浏览器 用户自行决定信任锚
结构 类似树形层次模型，浏览器厂商相当于“根” 扁平化模型，层次化信任的特例 多个中心化节点（信任锚）组成，属于寡头模式 去中心化模型，每个用户独立管理信任
优点 简单、方便，用户无需自行配置信任链 简化信任模型，单一信任来源 相较于垄断模式更灵活，能容忍部分根CA失效 完全自由，用户决定信任关系
缺点 用户不了解根CA来源；根CA无法废除；根密钥泄露时，无法有效废除 不存在普遍被信任的实体；CA公钥难以更改或分发；垄断者对PKI系统拥有完全控制权 容易受到木桶效应影响（最弱的CA决定整体安全性）；更多故障点；用户更易被不可信的CA诱导 使用复杂；难以控制信任链；缺乏统一标准，导致不可控
扩展性 中等，预置的根CA列表需要浏览器厂商更新 差，扩展新的信任锚几乎不可能 中等，需要多个根CA协调管理 高，但扩展带来的信任链复杂性不易管理
安全性 较低，依赖于浏览器厂商选择的根CA，若私钥泄露或CA不可信，安全性受损 极低，单点失效风险极高；若唯一的CA被攻破，整个信任体系崩溃 一定程度的安全性冗余，但受木桶效应制约 较低，用户可能信任不安全或错误的实体
管理复杂度 低，根CA由浏览器厂商统一管理 低，单一CA统一管理 中等，需要协调和维护多个根CA 高，用户需手动选择和管理信任锚
适用场景 Web浏览器（如HTTPS中的SSL证书验证） 内部系统或理论上的全球唯一信任模型 Web PKI体系（例如浏览器内置多个CA） 个体通信或小型网络，适合不依赖外部系统的个人通信
代表技术 Web PKI 理论信任模型（几乎不实际应用）；类似DNSSEC的根KSK 浏览器预置的多个受信任的CA，如Web浏览器的信任机制 PGP（Pretty Good Privacy）；网状信任模型

总结

  • Web信任模型：适合大众用户，简单易用，但其安全性依赖于浏览器厂商选择的根CA，且存在私钥泄露难以废除的问题。
  • 垄断信任模型：理论上最简单，但现实中难以实现，且单点失效风险极高。
  • 寡头信任模型：较常见的模式（如Web PKI），具有一定冗余性，但仍需依赖多个中心化节点，容易受到木桶效应影响。
  • 无政府信任模型：完全去中心化，但使用复杂，不适合开放系统或敏感通信。

名字约束模型 的对比

包括 自顶向下带有名字约束的信任模型 和 自底向上带有名字约束的信任模型：

特性 自顶向下带有名字约束的信任模型 自底向上带有名字约束的信任模型
基本结构 类似于DNS的层次结构，父域的CA对其子域CA进行认证（如.edu.cn认证hit.edu.cn）。 每个组织独立建立PKI，通过链接（自上而下、自下而上或交叉链接）与其他组织形成信任关系。
信任划分方式 每个CA仅在以其名字为根的名字空间内具有权限（如hit.edu.cn的CA只能管理其域下的证书）。 每个节点是其子树的CA，信任关系通过层级或交叉链接灵活构建，覆盖更广泛的名字空间。
信任链认证方式 通过层级认证，从根CA逐级验证子域的身份，天然形成清晰的信任链条。 从信任锚开始验证，若信任锚不是目标节点的祖先，则通过交叉链接尝试找到可信的证书链，最终验证目标节点身份。
安全性 更容易找到可信的证书链；名字空间的划分增强了安全性；易于用户理解和接受。 每个组织控制内部安全，无需依赖外部PKI；无单点失效风险，密钥泄露不会导致大规模重新配置。
灵活性 中等，信任链基于层次化命名规则，扩展性取决于层次结构的复杂性。 高，非常灵活，支持组织内部独立管理，也可轻松扩展信任链，通过交叉链接实现信任横向传递。
管理复杂度 较低，信任链清晰，基于域名层级授权管理；需要达成对根CA的全局一致。 较高，信任链可能需要动态解析交叉链接，配置和管理复杂，但更具自主性。
密钥更换与撤销 密钥更换和撤销涉及整个层次结构，可能需要影响多个子域。 本地密钥更换轻松，对其他组织无影响；轻量级，撤销速度快。
信任锚 根CA需要全局一致，若根CA受损，整个体系面临威胁。 初始公钥由组织自主管理，信任锚分布式，无需全局一致。
适用场景 DNSSEC、层次化域名体系、需要全球一致的场景（如.edu.cn认证子域）。 内部网络、组织间的跨域信任、需要高度自治和灵活性的场景。
优点 - 层次化信任更直观清晰- 基于名字划分信任，易于管理- 支持RA和CA授权- 实践中更安全，用户理解成本低。 - 灵活性高，可本地部署- 组织内部安全由自己控制- 无需借助外部组织，独立管理- 无单点失效风险，密钥泄露影响有限。
缺点 - 需要全局达成对根CA的信任一致- 根CA受损可能导致体系崩溃- 密钥更换复杂，撤销速度较慢。 - 配置复杂，尤其是在多个组织间建立信任链时- 信任链动态解析和管理较难- 用户需要较高的技术水平来理解和操作。
代表技术 DNSSEC（域名系统安全扩展），X.509/PKIX中的“NameConstraints”字段支持。 内部PKI系统，组织内部信任管理，与外部组织通过交叉链接建立信任关系。

总结

  • 自顶向下带有名字约束的信任模型：适用于层次化的信任体系，如DNSSEC，天然形成层次化的名字约束和信任链，管理简单，但根CA需全局一致。
  • 自底向上带有名字约束的信任模型：适用于组织内的独立信任管理，灵活性高，无单点失效风险，但信任链的动态解析和管理复杂。

证书日志与记录器（Logger）

证书日志（Certificate Log）

  • 定义： 证书日志是一个公开的数据库，用于记录由CA颁发的所有证书（在理想情况下应包含所有证书）。 目的是提供透明性，方便任何人检查证书的真实性与合法性。
  • 特点：
    1. 来源多样：证书可以由CA上传，也可以由任何其他人（如网站管理员或审计者）上传。
    2. 功能：
      • 防止CA滥发证书或滥用权限。
      • 为公众提供一种透明的方式，验证CA签发证书的合法性。
    3. 安全性：
      • 理想情况下，日志应该完整可信，避免遗漏或伪造。
      • 若存在恶意行为（如某些证书未被记录），可能导致透明性受损。

记录器（Logger）

  • 定义： 记录器是提供证书日志服务的服务器，负责记录CA颁发的证书。记录器通常由浏览器开发商（如Google、Mozilla）或CA（如DigiCert、Symantec）运行。

  • 运行机制：

    1. CA发送证书：当CA颁发一个证书后，需将其发送给记录器。

    2. 记录器返回SCT

      ：记录器在接收证书后，会向CA返回一个SCT（Signed Certificate Timestamp，签名的证书时间戳）。

      • SCT 是一种数字签名，表明该证书已经被成功记录在日志中。
      • SCT 相当于记录器向CA提供的“收据”。

    3. 网站服务器提供SCT：当一个网站使用该证书时，服务器需要同时提供对应的SCT，证明该证书是经过记录并可信的。

  • 特点：

    1. 安全性：
      • SCT 由记录器签名，能够防止证书未被记录或记录造假的情况。
    2. 责任分配：
      • 浏览器厂商运行记录器：通常较为可信，能为用户提供更高的保障。
      • CA运行记录器：可能存在利益冲突。若CA运行自己的记录器，可能会隐藏某些不合法的证书，削弱透明性。

思考与问题

  1. CA运行记录器的风险：
    • 可能由于利益关系而掩盖其滥发证书的行为。
    • 用户难以完全信任CA运行的记录器。
  2. 证书透明性（Certificate Transparency, CT）依赖记录器：
    • 记录器是整个证书透明性系统的关键，必须保证其可靠性和中立性。
    • 如果记录器出现故障或被攻破，可能影响整个系统的透明性。
  3. 记录器与浏览器的配合：
    • 浏览器必须通过证书日志来检查SCT是否存在，以及证书是否真实可信。
    • 如果记录器提供不完整的数据或滥发SCT，浏览器可能会被误导。

总结

  • 证书日志：是所有证书的公开数据库，为证书透明性提供基础保障。
  • 记录器：负责记录证书并签发SCT，是证书透明性系统中的核心组件。
    • 由独立第三方（如浏览器厂商）运行的记录器更可靠，而CA运行的记录器可能存在信任问题。

Merkle树与一致性证明（Proof of Consistency, PoC）

问题背景

在分布式系统或区块链中，Merkle树（Merkle Tree）是一种常用的数据结构，用于验证数据完整性和一致性。当我们面对以下问题时，需要用到一致性证明（PoC）：

问题：对于两颗Merkle树，如何验证“新树是否完整包含了旧树中的所有数据”？ 例如，随着时间推移，新的数据被添加到Merkle树中，形成一颗新的Merkle树，我们需要一种高效的方式验证“新树”包含“旧树”所有数据，而无需比较两棵树的所有节点。

一致性证明（Proof of Consistency, PoC）

一致性证明是一种高效验证机制，通过提供少量哈希值即可验证新树是否包含旧树中的所有数据。

基本原理

  1. Merkle树的更新： 每当添加新的数据块到Merkle树时，新的叶子节点会生成，同时树的整体哈希值（Root Hash）会发生变化。

  2. 一致性关系： 新树包含旧树的所有数据，因此可以将新树看作是从旧树扩展而来的。新树的根哈希值与旧树的根哈希值之间具有一致性关系。

  3. 关键点

    ：

    • 无需传输整棵树的数据。
    • 只需通过 少量的哈希值，即可证明新树确实是从旧树扩展而来。

一致性证明的实现

  1. 初始树（旧树）： 旧Merkle树的根哈希值 HoldH_{old}，以及叶子节点的哈希值序列。
  2. 扩展树（新树）： 新Merkle树的根哈希值 HnewH_{new}，包含了旧树的所有数据并添加了新的数据。
  3. 证明内容：
    • 提供新旧两棵树的 一部分内部节点哈希值（通常是树的路径上少数节点的哈希值）。
    • 验证路径可以证明旧树的哈希值是新树的一部分。
  4. 步骤：
    • 从旧树的根哈希值 HoldH_{old} 开始，利用提供的哈希值逐步计算和验证路径。
    • 验证这些路径是否与新树的根哈希值 HnewH_{new} 相符。

特点与优势

  1. 效率高： 一致性证明无需遍历和比较整棵Merkle树，只需传输部分节点的哈希值，减少了计算和通信成本。
  2. 安全性： 基于加密哈希函数的不可逆性和唯一性，证明过程具有极高的安全性。
  3. 广泛应用： 一致性证明广泛用于区块链、证书透明性系统（如CT）、分布式存储和版本控制等场景。

直观示例

  1. 旧树： 包含4个数据块 D1,D2,D3,D4D_1, D_2, D_3, D_4，其根哈希值为 HoldH_{old}。
  2. 新树： 添加了2个新的数据块 D5,D6D_5, D_6，其根哈希值为 HnewH_{new}。
  3. 证明过程：
    • 提供旧树根哈希值 HoldH_{old} 的路径节点哈希值，以及新数据对应的路径。
    • 验证这些哈希值是否能重新生成新树的根哈希值 HnewH_{new}。

总结

一致性证明是一种有效的验证机制，用于确认新Merkle树是否完整包含旧Merkle树的数据。 通过提供部分哈希值，一致性证明实现了：

  1. 高效性：避免比较整棵树的数据。
  2. 安全性：基于加密哈希函数的不可篡改性。
  3. 可靠性：适用于分布式存储、区块链和透明性系统等多种场景。

CT方案全貌与问题分析

CT（Certificate Transparency）概述

CT方案是一种通过日志记录和公开审计机制来增加数字证书颁发透明性的系统，旨在解决传统PKI体系中信任问题的不足。其核心机制涉及三个主要角色：监视器（Monitor）、审计员（Auditor） 和 记录器（Logger）。这些角色协同工作，监控和验证证书颁发的合法性，从而避免不当颁发的证书被滥用。

CT的核心组成

  1. 监视器（Monitor）：
    • 功能：
      • 持续监控证书日志，发现可疑证书。
      • 验证证书提交的可见性，确保每个颁发的证书都被记录到日志中。
      • 提供服务，供证书所有者查询，确认其域名下是否存在非法证书。
    • 目的：
      • 通过监控日志，快速发现并报告非法证书。
  2. 审计员（Auditor）：
    • 功能：
      • 验证记录器是否正确记录了所有证书。
      • 检查某个证书是否存在于日志中。
      • 验证日志的行为是否合规，避免篡改或分叉日志。
    • 目的：
      • 审计记录器行为是否符合透明性要求。
  3. 记录器（Logger）：
    • 功能：
      • 提供证书日志的存储服务。
      • 接收来自CA或其他实体的证书，并返回SCT（Signed Certificate Timestamp，签名证书时间戳）作为提交的证明。
    • 目的：
      • 确保证书公开记录，并生成一个不可篡改的日志。

CT方案中的问题与挑战

1. 违规行为证明（Proof-of-Misbehavior, PoM）

CT方案的一个重要目标是确保当记录器或CA出现违规行为时，能生成违规行为证明（PoM），从而追责。但在某些情况下，PoM可能无法提供：

  • 情景1：记录器不发布包含坏证书的STH（Signed Tree Head） 记录器故意不记录坏证书，导致依赖方不信任证书，但无法追责记录器的行为。
  • 情景2：记录器不响应PoC（Proof of Consistency）请求 当依赖方请求一致性证明时，记录器可能拒绝响应，从而隐藏问题证书。

目标：

  • 设计系统，使攻击要么无效（无法生效），要么生成PoM，以便追责。
  • 确保诚实方不会产生虚假的PoM。
2. 用户隐私暴露问题

在审计过程中，依赖方需要与审计员交互以验证证书的合法性，这可能导致用户访问的网站信息被暴露给CA或审计员。

解决目标：

  • 设计隐私保护机制，确保审计过程中用户的隐私信息不被泄露。
3. 吊销透明性问题
  • CT方案虽然增加了证书颁发的透明性，但不能确保吊销信息的透明性。
  • 可能受到“僵尸证书攻击”（Zombie Certificate Attack）的影响：
    • 攻击者继续使用已吊销的证书，依赖方无法实时获取吊销信息，从而继续信任失效的证书。

CT方案的审计特点

  • 审计的前提是日志不可篡改，通过透明性和公开性来代替传统的验证机制。
  • 通过以下机制提升安全性：
    1. 不可篡改性：基于Merkle树结构，确保日志数据一旦记录就无法修改。
    2. 透明性：所有颁发的证书都会被记录，避免隐秘颁发伪造证书的行为。

PKI安全小结

  1. PKI的基本功能：
    • 为网络通信提供身份认证。
    • 通过数字签名绑定身份和公钥，建立可信身份。
    • 依靠可信权威（CA）为身份背书。
  2. PKI的局限性：
    • 无法彻底解决信任问题，例如CA的信任问题和不当行为。
    • 需要额外机制（如CT）来增强透明性。
  3. CT的核心价值：
    • 提供公开的审计机制，增强证书颁发和使用的可信度。
    • 通过审计代替验证，实现信任机制的改进。
  4. CT审计的前提：
    • 日志数据的不可篡改性是CT有效性的基础。

总结

CT方案通过监视器、审计员和记录器三者的协同工作，改进了传统PKI体系的透明性和信任管理。虽然仍面临PoM难以生成、隐私暴露和吊销透明性等问题，但其通过公开日志、审计机制和透明性手段，显著提升了证书管理的安全性和可靠性。

notes > CS
#互联网基础设施安全 #PKI
pki
https://cdro.tech/notes/CS/pki/
作者
k9Q6CK42
发布于
2025年1月1日
更新于
2025年1月1日
许可协议