Pdf数字签名方法和系统以及pdf数字签名验证方法和系统的制作方法
【专利说明】
统
技术领域
[0001]本发明涉及数据签名技术领域，具体而言，涉及一种PDF数字签名方法、一种TOF数字签名验证方法，一种PDF数字签名系统和一种PDF数字签名验证系统。
【背景技术】
[0002]随着TOF已经成为主流文件交换格式之一，PDF文件的数字签名已经成为保证文件的真实性和完整性的重要技术手段。根据《IS032000:1-2008文献管理一便携式文献格式一第1部分:PDF1.7》规范，PDF文件的签名的范围由PDF签名字典中的字节范围(ByteRange)指定，一般取值为去除签名字典内签名结果(Contents)以外的文档其他内容，PDF签名的流程如图1所示，具体描述如下:
[0003]1.计算待签名文件中字节范围对应的字节范围数据；
[0004]2.对字节范围数据进行摘要计算，得到摘要值；
[0005]3.使用签名人私钥将摘要值进行摘要；
[0006]4.将摘要结果、数字证书、时间戳(可选)封装后写入PDF签名字典中的签名结果中；
[0007]在PDF文件多重数字签名时，每次签名是将上次签名的结果文件作为一个签名源，重复签名的过程，如图2所示。
[0008]上述多重签名的处理方式具有如下几个缺点:
[0009]1.不满足需要对同一内容进行联合签名的业务需求，由于每次签名覆盖的字节范围不同，因此每次数字签名保护的文档内容是不一样。
[0010]2.验签时性能比较低，阅读器需要提取每次签名的数据进行验证；
[0011]另一方面，PDF阅读器对数字签名的验证依赖于数字签名字典中的过滤器(Filter)和子过滤器(SubFilter)属性中指定的签名处理程序及签名结果编码格式，为保证不同提供商的签名处理程的互操作，PDF规范进一步定义了 adbe.pkcs7.detached、adbe.pkcs7.shal、adbe.x509.rsa.shal 几个 SubFilter,通过实现这几个预定义的SubFilter，通用 PDF 阅读器可以支持 RSA、DSA 签名算法及 SHA1、SHA256、SHA384、SHA512、RIPEMD160摘要算法的验证。
[0012]adbe.x509.rsa.shal指定了数字签名中使用RSA加密算法、摘要算法可以是SHA1、SHA256、SHA384、SHA512、RIPEMD160 之一，数字签名的结果按照 DER 编码的 PKCS#1二进制数据是直接存储在PDF文件签名字典的Contents条目中，用于签名的证书链存储在PDF文件签名字典的Cert条目中。adbe.pkcs7.detachecUadbe.pkcs7.shal指定了签名结果是按照 DER编码的 PKCS#7 (RFC3852Cryptographic Message Syntax) 二进制数据的格式存储在PDF文件签名字典的Contents条目中，PKCS#7的签名可以包括直接签名结果、签名证书链、证书回收列表、时间戳等信息。
[0013]要实现非RSA、DSA签名算法及其他摘要算法，需要定义自己的Filter和SubFilter属性，并开发特定的签名处理程序，实现自定义签名算法的签名和验证。签名处理程序可以通过插件机制嵌入在Adobe Reader等通用PDF阅读器中，实现在Adobe Reader等通用阅读器上支持自定义签名算法的验证。
[0014]基于Adobe Reader等通用阅读器开发自定义签名算法验证插件的方法需要在用户的客户机上安装专用插件，具有如下一些缺点:
[0015]1、用户体验差:采用现有技术，签名的验证依赖于专用插件，对于未安装插件的常规客户端，使用自定义算法签名的文档将显示为签名无法验证或验证失败，用户对文档的真实完整无法确认。
[0016]2、分发维护困难:阅读器插件需要安装在客户机阅读器安装目录下的特定子目录，阅读器的版本不同，该子目录也有所差别，如Acrobat的插件子目录为\Acrobat\plug_ins,而Adobe Reader的插件子目录为Reader\plug_ins。由于客户端环境的复杂度，自定义签名算法验证专用插件的分发和维护都非常困难。
[0017]3、成本较高:使用通用阅读器的插件接口需获得源厂商的开发许可，增加了开发成本。
[0018]4、与阅读器绑定:由于不同阅读器开发商的插件接口没有统一标准，为降低开发和维护成本，开发商需要绑定1-2款阅读器进行专用插件的开发。
[0019]因此，需要一种新的技术方案，可以支持对PDF文件的同一版本实现多次签名，并能使现有通用roF阅读器兼容自定义签名和摘要算法，提升用户使用体验的同时，降低分发维护的难度，节省开发成本。
【发明内容】
[0020]本发明正是基于上述问题，提出了一种新的技术方案，可以支持对PDF文件的同一版本实现多次签名，并能使现有通用roF阅读器兼容自定义签名和摘要算法，在提升用户使用体验的同时，降低分发维护的难度，节省开发成本。
[0021]有鉴于此，本发明提出了一种PDF数字签名方法，包括:根据待签名的PDF文件及签名属性信息计算数字签名对应的字节范围；根据所述字节范围提取所述PDF文件中的字节范围数据；根据所述字节范围数据计算摘要值；根据副署签名证书私钥、副署签名算法和所述摘要值计算出副署数字签名结果；根据主签名证书私钥、主签名算法和所述摘要值计算出主数字签名结果；将所述副署数字签名结果封装在所述主数字签名结果中，并将封装后的数字签名结果和所述字节范围、所述签名属性数据存储在PDF文件数字签名字典中。
[0022]在该技术方案中，电子文件的副署签名(Counter Signature),指的是多人(多证书)对同一个电子文件的同时签名时，电子文件主要责任人的数字签名为主签名，其他人的数字签名为副署签名，主签名结果采用符合RFC3852标准的PKCS#7格式，副署签名结果作为PKCS#7格式中的未签名属性(Unsigned Attribute)封装在主签名结果中；PDF签名字典中的子过滤器(SubFilter)属性需指定为 adbe.pkcs7.detached或adbe.pkcs7.shal。采用上述技术方案对PDF文件进行数字签名时，副署签名和主签名覆盖的字节范围完全相同，因此它们保护的文档内容相同，实现了对同一内容进行联合签名；验签时，只需要提取一次签名数据进行验证，提高了验证性能。
[0023]其中，所述签名属性信息包括签名日期、签名原因、位置、联系人信息、显示外观坐寸。
[0024]在上述技术方案中，优选地，所述副署数字签名为多个，在将所述副署签名结果封装在所述主数字签名结果之前，还包括:根据所述副署数字签名的个数，重复计算副署数字签名，即根据每个副署数字签名对应的副署签名证书私钥、副署签名算法和所述摘要值计算出每个副署数字签名对应的副署数字签名结果。
[0025]在上述技术方案中，优选地，在将所述副署签名结果封装在所述主数字签名结果之前，还包括:分析所述副署数字签名结果的格式，根据所述格式判断所述副署数字签名结果是否需要封装；在判断结果为不需要封装时，直接将所述副署签名结果封装在所述主签名结果中。
[0026]在上述技术方案中，优选地，在判断结果为需要封装时，将所述摘要值、所述副署数字签名对应的签名证书链、签名算法、所述副署签名结果封装成预设格式的签名结果，并将所述预设格式的签名结果封装在所述主签名结果中。所述预设格式可以是符合RFC3852标准的PKCS#7格式，也可以是自定义格式。
[0027]在上述技术方案中，副署签名与主签名采用不同的签名算法。副署签名的算法可以是自定义算法，主签名算法是PDF规范定义的标准算法。自定义算法的签名结果作为副署签名(Counter Signature)封装在标准算法的主签名结果中，通用PDF阅读器可以直接显示和验证主数字签名，自定义算法的签名结果由外部程序提取和验证。这样，避免通用PDF阅读器无法验证签名的错误，提升用户使用体验；避免了针对每个通用阅读器开发和分发签名处理程序，降低分发维护的难度，节省开发成本。
[0028]根据发明的另一方面，还提供了一种PDF数字签名验证方法，包括:从PDF文件数字签名字典中获取字节范围、封装后的数字签名结果；根据所述字节范围提取PDF文件中的字节范围数据，并计算摘要值；从所述封装后的数字签名结果中逐一提取出副署签名结果；根据所述摘要值和所述副署签名结果验证所述副署数字签名。
[0029]采用上述PDF数字签名方法对PDF文件进行数字签名后，主数字签名的显示和验证由通用roF阅读器完成，副署签名结果的提取和验证由外部程序完成，外部程序提取和验证时，按照所述步骤从签名提取字节范围、副署签名，进而计算字节范围数据的摘要值，根据所述摘要值和所述副署签名结果验证所述副署数字签名。这样，PDF阅读器只用验证主数字签名，主数字签名内含的副署数字签名验证时，计算的摘要值可以被多个副署签名验证所使用，避免了多个字节范围的提取和摘要值计算，降低了签名验证的复杂度，提高了验证时的性能。
[0030]在上述技术方案中，优选地，在根据所述摘要值和所述副署签名结果验证所述副署数字签名前，还包括:对所述副署签名结果进行解析，以获得副署签名对应的签名数据、签名结果、签名算法、签名证书链；对所述摘要值和所述签名数据进行比对，并根据所述签名数据、所述签名结果