HCIA-Security_V4.0 | 10_PKI 证书体系

1 数据安全通信技术

演进过程

数字信封

发送方采用接收方的公钥加密对称密钥后所得的数据。

发送方：

  • 对称密钥加密明文 → 密文
  • 接收方公钥加密对称密钥 → 数字信封

接收方：

  • 私钥打开数字信封 → 对称密钥
  • 对称密钥解密密文 → 明文

存在的问题：攻击者可拦截发送方的信息，用自己的对称密钥加密伪造信息，并用接收方的公钥加密自己的对称密钥，然后发给发送方，以冒充发送方。

数字签名

发送方用自己的私钥对数字指纹进行加密后所得的数据。

数字指纹又称消息摘要（Hash 算法的计算结果）。

发送方：

  • 接收方公钥加密明文 → 密文
  • Hash 算法计算明文 → 数字指纹
  • 发送方私钥加密数字指纹 → 数字签名

接收方：

  • 发送方公钥解密数字签名 → 数字指纹
  • 接收方私钥解密密文 → 明文
  • Hash 算法计算明文 → 数字指纹
  • 比较数字指纹

作用：

  • 证明信息未被篡改
  • 证明发送方的身份

存在的问题：攻击者伪造接收方的公钥给发送方，拦截接收方给发送方的信息，用自己的私钥对伪造的信息进行数字签名，将其与使用发送方的公钥加密的伪造信息一起发送给发送方，以伪造接收方。

数字证书

简称证书，是一个经证书授权中心（即在 PKI 中的证书认证机构 CA）数字签名的文件，包含拥有者的公钥及相关身份信息。

提供网络上的身份证明，解决了数字签名技术中无法确定公钥是指定拥有者的问题。

生成

前提：收到数字证书申请+认证申请者真实身份
消息明文：申请者的公钥+身份信息+数字证书的有效期等

  1. Hash 消息明文 → 摘要
  2. CA 私钥加密摘要 → 数字签名
  3. 数字签名+证书拥有者的公钥、身份信息、证书有效期等 → 数字证书

使用 CA 公钥对签名进行解密 → 证明证书由 CA 发布。

消息明文中的公钥和身份信息是 CA 的，则是 CA 自签名的过程。

结构

  • 版本：即使用 X.509 的版本，目前普遍使用的是 v3 版本（0x2）；
  • 序列号：颁发者分配给证书的一个正整数，同一颁发者颁发的证书序列号各不相同，可用与颁发者名称一起作为证书唯一标识；
  • 签名算法：颁发者颁发证书使用的签名算法；
  • 颁发者：颁发该证书的设备名称，必须与颁发者证书中的主体名一致。通常为 CA 服务器的名称；
  • 有效期：包含有效的起止日期，不在有效期范围的证书为无效证书；
  • 主体名：证书拥有者的名称，如果与颁发者相同则说明该证书是一个自签名证书；
  • 公钥信息：用户对外公开的公钥以及公钥算法信息；
  • 扩展信息：通常包含了证书的用法、CRL 的发布地址等可选字段；
  • 签名：颁发者用私钥对证书信息的签名。

验证

确认公钥的正确性需要通信方的证书 + CA 根证书。

分类

格式

数据通信全过程

向 CA 申请认证 → 发布自己的公钥
向 CA 验证 → 确认自己获得了别人的公钥

申请、发布及使用

  • 向 CA 发起数字证书申请；
  • CA 对发送方进行身份认证，认证通过后生成数字证书；
  • CA 将生成的数字证书发送给发送方；
  • 接收方下载发送方的数字证书；
  • 接收方收到数字证书后，使用 CA 公钥对数字签名解密生成消息摘要，对证书内容进行 hash 生成摘要，两份摘要进行比对可证明证书内容的完整性与真实性。

通信双方互相获得公钥完成身份认证后

发送方处理过程：

  • 发送方对要传输消息明文进行 Hash，生成数字指纹，再用发送方的私钥生成数字签名；
  • 发送方随机生成对称密钥，对明文加密，生成密文；
  • 发送方用接收方公钥加密对称密钥；
  • 将加密后的对称密钥、数字签名与密文一同发送给接收方。

接收方处理过程：

  • 接收方收到消息后，用自己的私钥解密对称密钥；
  • 用对称密钥解密密文，得到明文；
  • 对明文 Hash 得到数字指纹，用发送方的公钥解密签名得到数字指纹，对比两份指纹。

非对称加密安全性高，但计算量大效率低，因此使用对称密钥对通信的主要内容进行加密。对称密钥每次使用随机生成，用完即丢弃，降低风险。

用接收方公钥加密对称密钥，保证了只有接收方才能对密文进行解密。
用发送方私钥进行签名，使得接收方可以验证消息的发送方和消息是否被修改过，保证了消息的完整性和抗否认性。

2 PKI 体系架构

PKI（Public Key Infrastructure，公钥基础设施）本质是把非对称密钥管理标准化。

由终端实体 EE、证书认证机构 CA、证书注册机构 RA 和证书/CRL 存储库四部分共同组成。

  • 终端实体 EE（End Entity）：也称为 PKI 实体，它是 PKI 产品或服务的最终使用者，可以是个人、组织、设备（如路由器、防火墙）或计算机中运行的进程。
  • 证书认证机构 CA（Certificate Authority）：CA 是 PKI 的信任基础，是一个用于颁发并管理数字证书的可信实体。它是一种权威性、可信任性和公正性的第三方机构，通常由服务器充当。
    • CA 通常采用多层次的分级结构，根据证书颁发机构的层次，可以划分为根 CA 和从属 CA；
      • 根 CA 是公钥体系中第一个证书颁发机构，它是信任的起源。根 CA 可以为其它 CA 颁发证书，也可以为其它计算机、用户、服务颁发证书。对大多数基于证书的应用程序来说，使用证书的认证都可以通过证书链追溯到根 CA。根 CA 通常持有一个自签名证书；
      • 从属 CA 必须从上级 CA 处获取证书。上级 CA 可以是根 CA 或者是一个已由根 CA 授权可颁发从属 CA 证书的从属 CA。上级 CA 负责签发和管理下级 CA 的 证书，最下一级的 CA 直接面向用户。例如，CA2 和 CA3 是从属 CA，持有 CA1 发行的 CA 证书；CA4、CA5 和 CA6 是从属 CA，持有 CA2 发行的 CA 证书。
    • 当某个 PKI 实体信任一个 CA，则可以通过证书链来传递信任，证书链就是从用户的证书到根证书所经过的一系列证书的集合。当通信的 PKI 实体收到待验证的证书时，会沿着证书链依次验证其颁发者的合法性；
    • CA 的核心功能就是发放和管理数字证书，包括：证书的颁发、证书的更新、证书的撤销、证书的查询、证书的归档、证书废除列表 CRL 的发布等。
  • 证书注册机构 RA（Registration Authority）：是数字证书注册审批机构，RA 是 CA 面对用户的窗口，是 CA 的证书发放、管理功能的延伸，它负责接受用户的证书注册和撤销申请，对用户的身份信息进行审查，并决定是否向 CA 提交签发或撤销数字证书的申请。RA 作为 CA 功能的一部分，实际应用中，通常 RA 并不一定独立存在，而是和 CA 合并在一起。RA 也可以独立出来，分担 CA 的一部分功能，减轻 CA 的压力，增强 CA 系统的安全性。
  • 证书/CRL（Certificate Revocation List，证书吊销列表） 存储库：由于用户名称的改变、私钥泄漏或业务中止等原因，需要存在一种方法将现行的证书吊销，即撤消公钥及相关的 PKI 实体身份信息的绑定关系。在 PKI 中，所使用的这种方法为证书废除列表 CRL。任何一个证书被撤消以后，CA 就要发布 CRL 来声明该证书是无效的，并列出所有被废除的证书的序列号。因此，CRL 提供了一种检验证书有效性的方式。证书/CRL 存储库用于对证书和 CRL 等信息进行存储和管理，并提供查询功能。构建证书/CRL 存储库可以采用 LDAP（Lightweight Directory Access Protocol）服务器、FTP（File Transfer Protocol）服务器、HTTP（Hypertext Transfer Protocol）服务器或者数据库等。其中，LDAP 规范简化了笨重的 X.500 目录访问协议，支持 TCP/IP，已经在 PKI 体系中被广泛应用于证书信息发布、CRL 信息发布、CA 政策以及与信息发布相关的各个方面。如果证书规模不是太大，也可以选择架设 HTTP、FTP 等服务器来储存证书，并为用户提供下载服务。

PKI 证书生命周期

  • 证书申请：证书申请即证书注册，就是一个 PKI 实体向 CA 自我介绍并获取证书的过程。
  • 证书颁发：PKI 实体向 CA 申请本地证书时，如果有 RA，则先由 RA 审核 PKI 实体的身份信息，审核通过后，RA 将申请信息发送给 CA。CA 再根据 PKI 实体的公钥和身份信息生成本地证书，并将本地证书信息发送给 RA。如果没有 RA，则直接由 CA 审核 PKI 实体身份信息。
  • 证书存储：CA 生成本地证书后，CA/RA 会将本地证书发布到证书/CRL 存储库中，为用户提供下载服务和目录浏览服务。
  • 证书下载：PKI 实体通过 SCEP 或 CMPv2 协议向 CA 服务器下载已颁发的证书，或者通过 LDAP、HTTP 或者带外方式，下载已颁发的证书。该证书可以是自己的本地证书，也可以是 CA/RA 证书或者其他 PKI 实体的本地证书。
  • 证书安装：PKI 实体下载证书后，还需安装证书，即将证书导入到设备的内存中，否则证书不生效。该证书可以是自己的本地证书，也可以是 CA/RA 证书，或其他 PKI 实体的本地证书。通过 SCEP 协议申请证书时，PKI 实体先获取 CA 证书并将 CA 证书自动导入设备内存中，然后获取本地证书并将本地证书自动导入设备内存中。
  • 证书验证：PKI 实体获取对端实体的证书后，当需要使用对端实体的证书时，例如与对端建立安全隧道或安全连接，通常需要验证对端实体的本地证书和 CA 的合法性（证书是否有效或者是否属于同一个 CA 颁发等）。如果证书颁发者的证书无效，则由该 CA 颁发的所有证书都不再有效。但在 CA 证书过期前，设备会自动更新 CA 证书，异常情况下才会出现 CA 证书过期现象。
  • 证书更新：当证书过期、密钥泄漏时，PKI 实体必须更换证书，可以通过重新申请来达到更新的目的，也可以使用 SCEP 或 CMPv2 协议自动进行更新。
  • 证书撤销：由于用户身份、用户信息或者用户公钥的改变、用户业务中止等原因，用户需要将自己的数字证书撤消，即撤消公钥与用户身份信息的绑定关系。在 PKI 中，CA 主要采用 CRL 或 OCSP 协议撤销证书，而 PKI 实体撤销自己的证书是通过带外方式申请。

PKI 证书申请流程

  • 用户申请：用户获取 CA 的数字证书（根证书），与安全服务器建立连接，同时生成自己的公钥和私钥，将公钥和自己的身份信息提交给安全服务器。安全服务器将用户的申请信息传送给 RA 服务器。
  • RA 审核：RA 收到用户的申请，用户向 RA 证明自己的身份，RA 进行核对。如果 RA 同意用户申请证书的请求，则对证书申请信息做数字签名，否则拒绝用户的申请。
  • CA 发行证书：RA 将用户申请和 RA 签名传输给 CA，CA 对 RA 数字签名做认证，如果验证通过，则同意用户请求，颁发证书，然后将证书输出。如果验证不通过，则拒绝证书申请。
  • RA 转发证书：RA 从 CA 得到新的证书，首先将证书输出到 LDAP 服务器以提供目录浏览，再通知用户证书发行成功，告知证书序列号，到指定的网址去下载证书。
  • 用户证书获取：用户使用证书序列号去指定网址下载自己的数字证书，只有持有与申请时提交的公钥配对的私钥才能下载成功。

申请方式

PKI 实体向 CA 申请本地证书的方式包括在线申请和离线申请。

PKI 证书验证

PKI 实体获取对端实体的证书后，当需要使用对端实体的证书时，通常需要验证对端实体的本地证书和 CA 的合法性。通常检查证书状态的方式有三种：CRL 方式、OCSP 方式、None 方式。

  • CRL（Certificate Revocation List，证书注销列表）方式
    • PKI 实体可以通过 SCEP、HTTP、LDAP 和 LDAPv3 模板方式下载 CRL。
    • 当 PKI 实体验证本地证书时，先查找本地内存的 CRL，如果本地内存没有 CRL，则需下载 CRL 并安装到本地内存中，如果对端实体的本地证书在 CRL 中，表示此证书已被撤销。
  • OCSP 方式
    • 在 IPSec 场景中，PKI 实体间使用证书方式进行 IPSec 协商时，可以通过 OCSP 方式实时检查对端实体证书的状态。
    • OCSP 克服了 CRL 的主要缺陷：PKI 实体必须经常下载 CRL 以确保列表的更新。当 PKI 实体访问 OCSP 服务器时，会发送一个对于证书状态信息的请求。OCSP 服务器会回复一个“有效”、“过期”或“未知”的响应。
      • 有效：证书没被撤销；
      • 过期：证书已被撤销；
      • 未知：OCSP 服务器不能判断请求的证书状态。
  • None 方式
    • 如果 PKI 实体没有可用的 CRL 和 OCSP 服务器，或者不需要检查 PKI 实体的本地证书状态，可以采用 None 方式，即不检查证书是否被撤销。

PKI 证书注销流程

  • 用户申请：用户向 RA 发送一封签名加密邮件，申请撤销证书；
  • RA 审核：注册机构同意证书撤销，并对申请签名；
  • CA 更新 CRL：CA 验证证书撤销请求的 RA 签名，如果正确，则同意申请，更新 CRL，并输出；
  • RA 转发 CRL：注册中心收到 CRL，以多种方式将 CRL 公布（包括 LDAP 服务器）；
  • 用户告知：用户访问 LDAP 服务器，下载或浏览 CRL。

3 PKI 工作机制

工作机制

针对一个使用 PKI 的网络，配置 PKI 的目的就是为指定的 PKI 实体向 CA 申请一个本地证书，并由设备对证书的有效性进行验证。PKI 具体工作过程如下：

  • PKI 实体向 CA 请求 CA 证书，即 CA 服务器证书。
  • CA 收到 PKI 实体的 CA 证书请求时，将自己的 CA 证书回复给 PKI 实体。
  • PKI 实体收到 CA 证书后，安装 CA 证书。
    • 当 PKI 实体通过 SCEP 协议申请本地证书时，PKI 实体会用配置的 Hash 算法对 CA 证书进行运算得到数字指纹，与提前配置的 CA 服务器的数字指纹进行比较，如果一致，则 PKI 实体接受 CA 证书，否则 PKI 实体丢弃 CA 证书。
  • PKI 实体向 CA 发送证书注册请求消息（包括配置的密钥对中的公钥和 PKI 实体信息）。
    • 当 PKI 实体通过 SCEP 协议申请本地证书时，PKI 实体对证书注册请求消息使用 CA 证书的公钥进行加密和自己的私钥进行数字签名。如果 CA 要求验证挑战密码，则证书注册请求消息必须携带挑战密码（与 CA 的挑战密码一致）；
    • 当 PKI 实体通过 CMPv2 协议申请本地证书时，PKI 实体可以使用额外证书（其他 CA 颁发的本地证书）或者消息认证码方式进行身份认证。
      • 额外证书方式：PKI 实体对证书注册请求消息使用 CA 证书的公钥进行加密，和 PKI 实体的额外证书相对应的私钥进行数字签名；
      • 消息认证码方式：PKI 实体对证书注册请求消息使用 CA 证书的公钥进行加密，而且证书注册请求消息必须包含消息认证码的参考值和秘密值（与 CA 的消息认证码的参考值和秘密值一致）。

应用场景

通过 HTTPS 登录 Web（管理员）

在设备上为 HTTPS 客户端指定由 Web 浏览器信任的 CA 颁发的本地证书。这样，Web 浏览器可以验证本地证书的合法性，避免了可能存在的主动攻击，保证了管理员的安全登录。

在 SSL 连接建立的过程中，HTTPS 客户端和 HTTPS 服务器之间的主要交互流程如下：

  • HTTPS 服务器向 PKI 认证中心申请本地证书；
  • PKI 认证中心向 HTTPS 服务器颁发本地证书；
  • HTTPS 服务器将携带自己公钥信息的数字证书发送给 HTTPS 客户端；
  • HTTPS 客户端验证 HTTPS 服务器的本地证书合法后，利用证书中的公钥加密 HTTPS 客户端随机生成的密钥，并发送给 HTTPS 服务器；
  • HTTPS 客户端和 HTTPS 服务器通过协商，最终确定所使用的密钥和加密套件；
  • 后续传输的数据，双方都会使用该密钥和加密套件进行加密处理。

IPSec VPN（企业分支）

IPSec 采用基于 PKI 的证书进行身份认证后，在进行 IKE 协商过程中交换密钥时，会对通信双方进行身份认证，保证了密钥交换的安全。

IPSec 技术在对端设备建立 IPSec 隧道，保护数据的安全性。通常采用预共享密钥方式协商 IPSec，但在大型网络中，设备之间可以采用基于 PKI 的证书进行身份认证来完成 IPSec 隧道的建立。

采用基于 PKI 的证书进行身份认证后：

  • IPSec 在进行 IKE（Internet Key Exchange）协商过程中交换密钥时，会对通信双方进行身份认证，保证了密钥交换的安全。
  • 证书可以为 IPSec 提供集中的密钥管理机制，并增强整个 IPSec 网络的可扩展性。
  • 在采用证书认证的 IPSec 网络中，每台设备都拥有 PKI 认证中心颁发的本地证书。有新设备加入时，只需要为新增加的设备申请一个证书，新设备就可以与其他设备进行安全通讯，而不需要对其他设备的配置进行修改，这大大减少了配置工作量。

SSL VPN（出差员工）

可以为出差员工提供方便的接入功能，设备可以采用 PKI 的证书方式来对用户进行认证以提高访问安全性。

SSL VPN 客户端可以通过证书验证 SSL VPN 网关的身份；
SSL VPN 网关也可以通过证书来验证客户端的身份。

posted @ 2024-09-27 12:12  Guanz  阅读(9)  评论(0)  编辑  收藏  举报