原文：Digital Signatures in a PDF

二、公钥基础设施（PKI）

PDF的数字签名功能旨在与企业和政府环境中部署的与主流公钥基础设施（PKI）相关的所有标准兼容。PKI是在创建，分发，管理，吊销以及使用数字ID时使用的人员，策略，过程，硬件和软件的集合，这些数字ID中包含签署PDF时使用的公钥/私钥对。

在PDF签名工作流的上下文中，“PKI”通常指数字ID的颁发者、用户、管理员以及任何在这些工作流中使用的软硬件。实现并符合PDF语言标准的PDF阅读器能够以无缝且健壮的方式与这些组件交互。

common-pki-elements.png

在签署重要的纸质文件时，人们通常需要向公证人或其他受信任的机构提供令人满意的身份证明，之后在他们面前对文件进行签署。 因为公证人被认为是值得信赖的，所以你可以信任公证人见证的签名。 使用PKI是一种提供类似信任的方法。

与提供信任直接相关的一些常见PKI组件包括：

  • 证书颁发机构（CA）：最终的信任机构，可以出售或发行数字ID（例如Verisign或Geotrust）。 CA会签署自己的证书（自我签名），并且其证书通常是证书链顶部的“根”证书。
  • 中间证书（ICAs）：一种CA，在证书链中其位于终端用户和根证书之间。 该证书不是自签名的，并且ICA通常提供诸如策略，时间戳，吊销列表等服务。
  • 终端用户证书（EE）：签署者的证书，也是签署链上最后的元素。根据定义，终端用户证书不包含CA基本约束值。
  • 数字ID：与个人或实体相关联的基于ITU-T X.509 v3标准的数据电子表示形式。 它存储在计算机或网络上受密码保护的文件，USB令牌，智能卡等中。数字ID包含公钥证书，私钥和其他数据
  • 公钥证书：一个包含公钥/私钥对的数字公钥部分以及用于定义证书所有者，有效期和用法的关联扩展和属性的文件。
  • 私钥：PKI系统中的密钥，用于验证传入消息和对传出消息进行签名。在密钥生成期间，私钥始终与其公钥配对。

尽管数字ID及其发行实体是任何PKI的核心，但PKI还包括许多其他企业所有和第三方项目。 PKI管理员通常管理着数字ID的创建与分发，LDAP（Light Directory Access Portocol）服务器，时间戳服务器，吊销列表和其他项目。PDF语言支持所有与这些组件交互所需的数据。

1. PKI，PDF和签署

PDF支持将签名嵌入文件自身，而不是作为单独的数据管理或者添加到现有文件格式中。这意味着查看应用程序可以不破坏签名而进行特定类型的修改。对于其它数字签名格式，用户可能需要使用两个应用来处理文件和签名，或者需要为每个签名文件管理两份单独的文件。

PDF中的每个签名都与签名处理程序关联。签名被放置在PDF签名字典中，里面包含用于处理签名的签名处理器名字（如图3）。Adobe Acrobat leverages Public/Private Key（PPK）加密技术内置了签名处理程序。PPK基于这样一种思想，即用私钥加密的值只能使用公钥解密（反之，在为特定收件人加密文件时也是同样的，但这不在本文档的范围之内）。

对PDF进行签名后，签名者的证书将嵌入在PDF文件中。图3展示了存储在用户硬件设备上的数字ID与嵌入PDF文件中签名值的关系。签名值可能还包含额外的信息，例如签名图片，时间戳和可能特定于用户，系统或应用程序的其他数据。

relation-between-id-pdf

签署过程如下：

  1. 待签名文件被处理成字节流。
  2. 将整个PDF文件写入磁盘，并留出适当大小的空间用于签名值以及ByteRange数组中的最坏情况值。
    • ByteRange数组由四个数字组成。每对中的第一个数字是对于文件的偏移量（从头开始，起始是0），表示需要被包含在哈希计算中的字节流的起始。第二个数字是该流的长度。这两对定义了两个字节序列，这些字节序列定义了要哈希的内容。实际签名值存储在第一个序列的末尾与第二个序列的开头之间的/Contents键中。图4中，哈希是针对字节0到839和960到1200计算的。
  1. 一旦根据文件中的偏移量知道了签名值的位置，就可以使用正确的值填充ByteRange数组。因为字节偏移禁止修改，所以新数组语句之后的多余字节将被零覆盖。
  2. 使用诸如SHA-256之类的哈希算法，由实际ByteRange值指定的字节来计算整个文件的哈希。Acrobat始终在整个PDF文件中计算文件签名的哈希值，该哈希值从字节0开始到物理文件的最后一个字节结束，但不包括签名值字节。
  3. 哈希值由签署者的私钥加密，并生成一个十六进制编码的PKCS#7对象签名对象。
  4. 签名对象放置在磁盘上的文件中，覆盖占位符/Contents值。 未用于签名对象的任何空间都将被零覆盖。
  5. 将PDF文件重新加载到Acrobat中，以确保内存和磁盘上的版本相同。

提示： 这是一个高层级展示。对于更详细的一些应用程序级配置选项的快速键，请参阅“签名创建工作流”。

2. PKI，PDF和签名校验

由于私钥和公钥仅仅是数字，因此任何人都可以使用任意数量的工具生成公钥和私钥对。 诸如Acrobat之类的应用程序提供了一种生成自签名证书的机制，该证书将简单的用户提供的身份绑定到由应用程序生成的公钥。 然后使用相应的私钥对其进行签名。 显然，没有什么可以阻止某人生成使用他人名字的自签名证书的。 因此，未知的自签名证书没有很高的保证水平。

为了解决这种类型的信任问题，组织者使用一种PKI，该PKI包括发布，记录和跟踪数字ID的独立权限。 由于PDF支持将签名者的公共密钥作为签名的一部分进行嵌入，因此文件接收者始终可以使用它来进行签名验证。要验证签名，验证者只需检索签名者的证书，并将其与自己的受信任证书列表进行比较：

  1. 收件人的应用程序使用签名者使用的相同算法（不包括签名值）来生成文件的单向哈希。
  2. 使用签名者的公钥对文件中加密的哈希值进行解密。
  3. 将解密的哈希值与本地生成的哈希值进行比较。
  4. 如果它们相同，则将签名报告为已知。

提示： 签名是否受信任或有效是单独的问题。 签名信任取决于收件人的应用程序配置。 签名状态还取决于文件完整性检查。