PKI安全

1. 概述

• 公钥加密可以解决开放系统中的安全通信问题
  • 与私钥加密（对称加密）相比，密钥数量少、密钥分发容易
• 公钥的分发需求
  • 不要求保密，但要求真实、完整

2. PKI概念

• 数字签名
• 数字证书
• 证书示例（极简版）

  • $Alice$ (公钥持有者的身份标识)

    $PK_a$ 公钥

    $[Alice, PK_a]_{SK_c}$ 签名者生成的数字签名

    $Charlie$ 签名者的身份标识

• 认证
  • 收到的公钥在被使用之前，必须先经过可信方的认证
  • 认证公钥：为公钥与身份的绑定关系做担保/背书，即做出“公钥P属于用户A”的声明
• 公钥基础设施（PKI）
  • 是一种标准的、为利用公钥加密技术实现保密通信而提供的一套安全基础平台

PKI术语

名词	解释
主体	任何持有公钥的一方
证书	主体的公钥被签名的消息
颁发者	证书的签名者
证书主体	被签名的公钥所属的实体
验证者	评估证书或证书链的可信赖的一方
证书链	如果信任证书的颁发者，可以传递信任，即将证书主体视为证书颁发机构，并从证书主体获取其颁发的证书
信任锚	验证者通过外部途径信任的公钥，是验证者认为可以信任的公钥
注册权威（RA）	由CA信任并指派，负责验证证书主体的身份

信任模型

• PKI需要解决的核心问题是信任问题
  • 信任谁、如何验证
• 两种信任关系：层次化（树），网状（有向图）
• 五个典型模型：垄断、寡头、无政府、自顶向下带有名字限制、自底向上带有名字限制

小世界理论（六度分割理论）

• 世界上任何互不相识的两人，只需要很少的中间人就能够建立起联系
• 信任链不会太长

层次化信任

• 设立根权威
  • 所有人都必须知晓用于验证根权威签名的公钥
• 根权威可为下一级权威颁发证书，依此类推
  • 用证书链替代单一证书

网状信任

• 被PGP（Pretty Good Privacy）采用
• 自主决定信任的起点：每个人都有自己信任的一系列公钥
• 信任可以任意传递

垄断信任模型

• 垄断（monopoly）
  • 每个人都相信一个组织是世界上唯一的CA
  • 该CA的密钥作为PKI信任锚嵌入到所有软件和硬件中
  • 该CA签署所有公钥证书
• 是一种“扁平”的信任模型，层次化信任的特例

寡头信任模型

• 寡头
  • 预置多个根CA
• 缺点
  • 更多的故障点，木桶效应
• Web PKI是寡头
  • Web浏览器预先配置了许多受产品供应商信任的信任锚

无政府信任模型

• 无政府
  • 每个用户自行决定其信任锚
  • 对于个人通信是实用的，不适合开放系统或敏感通信
• 名字约束
  • 名字=身份的标识符
  • 根据其身份，CA只能为一部分用户颁发证书

自顶向下带有名字约束的信任模型

• 与DNS层次结构类似，每个域有一个CA服务器，父域的CA负责为子域的CA生成证书
• 层次化信任，但根据名字天然形成CA的层次

自底向上带有名字约束的信任模型

• 每个组织创建一个独立的 PKI，然后链接到其他组织
  • 自上而下的链接：认证子节点身份
  • 自下而上的链接：认证父节点身份
  • 交叉链接：一个节点证明另一个节点

Web PKI

• 面向Web应用（HTTPS协议），是PKI最主要的应用形式
• 采用寡头信任模型，浏览器内置100+个根CA的自签名证书
• 根CA名单由业界共同决定
• 设置中间CA，允许证书链
• 证书主体（网站）的证书一般由中间CA颁发

证书撤销（Revocation）

• 被撤销的证书不应再被使用
  • 谁颁发，谁撤销
• 撤销证书的理由
  • 与证书中公钥相对应的私钥泄露
  • 证书颁发机构停止为证书主体服务
  • 证书颁发机构的证书不再可信
• 隐式撤销：证书有效期满
• 主动撤销

证书发布（Publication）和获取

• 验证者需要能够便捷、高效地获取验证所需的全部证书
• 安全需求
  • 证书是公开信息，无需保护机密性
  • 期望证书未被窜改，否则影响可用性
• 目录服务：支持根据名字检索信息

3. X.509/PKIX体系（Web PKI）

“证书”一般指“X.509 v3证书”

证书格式

略（有空填坑）

4. 证书透明方案

在Web PKI（Public Key Infrastructure）中，CT（Certificate Transparency）方案验证是指验证证书是否已经被记录在公共的CT日志中。

CT是一种公开可查的日志系统，旨在增加对证书颁发过程的透明度和安全性。根据CT方案，证书颁发机构（CA）必须将颁发的每个证书提交到至少一个公共的CT日志中。这些日志是公开可访问的，任何人都可以查看其中的记录。

CT方案验证通过以下步骤来进行：

1. 客户端（如浏览器）接收到服务器发送的证书。
2. 客户端检查证书中是否包含Signed Certificate Timestamps（SCTs），这些SCTs是由颁发机构或其他可信的第三方签名的。
3. 客户端使用证书中的公钥验证SCT的签名。
4. 客户端从公共的CT日志中获取相应的证书记录。
5. 客户端比较证书中的信息与CT日志中的记录，确保证书已被正确记录在CT日志中。

CT方案验证的目的是防止恶意的或错误的证书颁发。通过公开记录证书的过程，可以增加对证书颁发机构的监督和审查，减少潜在的证书欺诈和滥用。同时，CT方案验证也有助于发现和解决证书链中的问题，提高Web安全性。