PDF文档的加解密及数字签名技术（一）

PDF文档的加解密及数字签名技术（一）

 

写在本文之前

 

首先，笔者假定在阅读本文之前，读者已经对文中提到的相关知识有一定了解，如PDF文档的结构组织、对称密钥加密、数字签名技术等。所以本文对以上内容做大致上的介绍，而不会对细节进行描述，如果读者需要了解本文中未能详细介绍的知识，可以自行寻找相关的文章阅读，当然了，最好的相关文章就是PDF手册啦。

 

前言

 

有时候，我们会用PDF文档存储一些敏感的信息，如用电子邮件发送的大宗货物订单等。要存储敏感信息，应保证PDF文档的机密性、真实性、完整性和不可否认性。要满足机密性，就要对PDF文档进行加密处理。而要保证PDF文档的真实性、完整性和不可否认性，则需要对PDF文档进行数字签名。

 

熟悉PDF文档结构的读者都知道，PDF文档是由对象组成的，这些对象有大纲对象、页面对象、内容流对象等。加密和数字签名也一样，通过在PDF中增加对象或者对原有对象做修改实现。下面我们将分别介绍PDF文档加密和数字签名是如何实现的，需要增加或改变哪些对象的内容。不过本文毕竟不是翻译PDF手册，介绍对象时，只会对其中相关或必须的部分作介绍，其余的部分信息，读者可查阅PDF手册。

 

加密的PDF文档结构的变化

 

打开Acrobat，我们先看看Acrobat是如何对文档进行加密的。在“文档属性”对话框的“安全性”标签下，将“安全性方法”设为“口令安全性”，会弹出一个对话框。其中有两个口令可以选择：一个口令是打开文档口令，我们称之为User Password，如果设上该口令，则每次打开PDF文档都需要输入这个口令；另一个口令是权限限制口令，我们称之为Owner Password，如果设置上了此口令，则除非输入权限口令，否则只能做权限限制允许的操作，比如禁止打印、禁止更改等。

 

那么加密后的PDF文档将变成什么样呢？让我们用UltraEdit打开一个加密的PDF文档一探究竟。

PDF的交叉引用表多出了一项，我们将其标出：

   

    trailer

    << 

    /Size 13

    /Root 1 0 R

    /Info 3 0 R

    /Encrypt 2 0 R

    /ID [ <D5B3E2C646DE3D8266F471E24D231133> <D5B3E2C646DE3D8266F471E24D231133> ]

    >>

 

可以看到，其中多出了一个对象的引用，这个对象就是加密字典对象，让我们追踪一下它，看看它到底是什么样的，又有哪些内容呢？

 

找到2 0 obj，它的内容如下：

   

    2 0 obj
    <<
    /Filter /Standard
    /Length 128
    /CF << /StdCF << /Length 16/AuthEvent/DocOpen/CFM/AESV2 >> >>
    /R 4
    /P -3392
    /O <DDBC87D3B71D554BB67A4B42C2FE9212A5C2BD37CAF1127469340E8425CD2FA0>
    /U <20A3B675D1531C4959BC129A6BD2A68400000000000000000000000000000000>
    /EncryptMetadata false
    /V 4
    /StrF /StdCF
    /StmF /StdCF
    >>
    endobj

 

Filter项，Standard指明了此PDF文档是标准的基于口令的文档安全性方法。

 

Length项，指明了加密密钥的长度（位），PDF支持的两种加密算法，RC4和AES。其中RC4算法的密钥长度为40-128位，且必须是8的倍数。对于AES算法，则有128位（PDF1.6）和256位（PDF1.9）两种。

 

V项，指明了文档是用什么样的算法加解密的。0是一种不再支持的算法，我们恐怕不会在某个PDF文档中看到这种算法的出现；1是使用算法3.1（详见PDF手册，在PDF Reference 1.7中，在119页），密钥长度仅为40位时；2同样采用算法3.1但是支持比40位更长的密钥；3表示采用了一种未公开的算法，支持40-128位密钥；4表示算法将由CF项、StrF项、StmF项指定，同时如果V项值为4，Length项也可以省略了，密钥长度在CF中指定。

 

CF项，如果V项值为4，则算法由CF项描述，那么此例中CF是如何描述的？/StdCF说明采用的是标准算法：AES算法，16字节长的密钥，重复一遍：注意这里Length描述的密钥长度是字节哦！亲。这里可以指定多种算法，以便为字符串加密和流对象加密指定不同算法，虽然我个人认为这是吃饱了撑的，但是也许能为试图破解者找点麻烦呢？

 

StrF项，指明了PDF文档中字符串的加密方法，取值必须在CF项中指定过。

 

StmF项，指明了PDF文档中流对象的加密方法，取值必须在CF项中指定过。

 

R项，如果采用的是口令安全性方法，R表示标准口令安全方法的修订版本号。V值小于2时，R为2；V为2或者3时，R为3；V为4时，R为4。

 

P项，表示文档的权限限制，为啥它是个负数呢？其实它是用32位有符号整数表示的，部分位用来表示权限。1为有权限，0为无权限，其余位均必须为1。至于哪些位代表什么意思（PDF Reference 1.7里123页的表3.20告诉你）。

 

O项，用用户口令（User Password）和权限口令（Owner Password）生成的一个二进制串，用来做生成加解密密钥计算用的。

 

U项，用用户口令（User Password）生成的一个二进制串，用来在打开文档时验证口令使用。

 

以上这些谁生成谁，谁又用来干吗的问题，请看PDF Reference 1.7里125页开始的算法3.2-3.7，我后文中将详细介绍。（我这打个广告，高价出售现成算法咯！！！啊~~捂头逃跑）

 

EncryptMetadata项，指明是否加密文档中的Metadata，Metadata在PDF文档中是一种流对象，如果不对其加密，则搜索引擎可以借助Metadata大致了解PDF文档的一些信息，便于他人搜索到这篇文档。如果这是你想要的结果，那么设false吧。只是有一点要注意，设true还是false，都会影响到O项值的结果，两处要对应上。

 

嗯，加密字典介绍完了，加密的PDF文档就额外多出这么一个对象，是不是很简单哇？

 

这就完了？加上这个PDF文档就算加密了？不不，下一篇文章，我们会介绍如何用加密字典提供的信息对PDF文档进行加解密，以及一些在加解密中容易出现的误区。