PDF Digital Signature(尚未完成)

简介: 因为上周微信群里有同事问了一个PDF 电子签名的问题:为什么前面的Digital Signature不会认为后续的Signature是对文档的更改。借此机会详细讲述一下PDF Digital Signature的机制,包括签名和验签。

因为上周微信群里有同事问了一个PDF 电子签名的问题:为什么前面的Digital Signature不会认为后续的Signature是对文档的更改。借此机会详细讲述一下PDF Digital Signature的机制,包括签名和验签。
首先简单直观地解答一下上面的这个问题。
Q_HC0KZ_5_GKCQ49_C7BZ_Q
每个签名下有一个“单击以查看本版本”
WU_6J4G0SNPIZL_DTT_5_EN
点开以后可以看到当次签名时的版本。可以得出两个结论:
1.每个签名是对签名前的文档进行签名,而不是未签名的原文档。
2.被签名内容是包括本次签名内容的。

下面两张图:
一个被签名的PDF概念图:
image
一个被多次签名的pdf概念图:
image
这里可以看出来几点:
1.签名是线性有序的,不能多人同时签名

  1. 每个签名里的Signed Message Digest 是此签名当时版本的Hash
  2. 每次验签时,对比的是此签名版本前的内容(仅仅以RSA为例,ECC和SM2不同)不对后续版本(增加的内容)负责——即(在正常情况下)除了最后一个签名以外,之前的签名都无法覆盖整个PDF。

下面讲一下PDF验签的内容:
首先从电子签名的三要素开始:
1.内容完整性——即无篡改

  1. 签名者身份的真实性
  2. 不可抵赖性

1.针对完整性,提取出所有签名,用每个签名的各自的签名算法的验签算法做一次验签就可以了,所有签名验签成功即可保证PDF内容违背篡改,当然也会有例外——如果最后一个签名没有覆盖整个文本就说明存在问题——即pdf版本数和签名数不一致的情况,如下:
image
这是一段输出签名是否覆盖全文档,签名是全部版本数中的第几版本和签名验签结果的代码输出,可以看出有4个签名却有5个版本,本例是
image
文档被sig4锁定,sig2锁定自己的签名域,第五个人Chuck修改了approved_carol after Dave has signed.
image
可以看到第一个Alice的签名是Certification (author) signature(这个我们会在后期继续细化整理时提到),在一个PDF文档中,最多只允许有一个,它是附带权限的,而后续三个是Ordinary (approval) signature 一个PDF文档中可以有多个。Certification (author) signature的权限根据设置,有三种限制:。1.CERTIFIED_NO_CHANGES_ALLOWED 不许任何更改,否则签名失效 即连Ordinary (approval) signature都不许添加了
2.CERTIFIED_FORM_FILLING 后续可以添加表单和Ordinary (approval) signature而不影响签名的有效性
3.CERTIFIED_FORM_FILLING_AND_ANNOTATIONS 可以添加Ordinary (approval) signature ,表单和注释,不影响签名的有效性。
回到上面的例子,在sig4签名后,Chuck对Carol的approved_carol(我暂时还是没弄清楚回头再细化)但是不影响签名,只是“违抗”了之前签名的权限。

2.针对签名者身份真实性和不可抵赖性,主要是针对签名证书涉及以下几点:
i.签名证书在签名时是否过期,一般通过对比签名时间或者时间戳来验证,签名时间是签名者的机器时间可伪造(改时间即可)所以可信度不高,时间戳也是一段签名,再通过一次验签就可以验证有效性。
ii.签名证书在签名时是否被吊销——通过CRL或者OCSP来验证
iii.签名证书是否可信的——是否是可信机构颁发的,一般由证书链来验证,证书链上的证书一级一级向下级证书签名,根证书是可信证书

下面讲一个例子:
假设Alice有一个有效期到2014年的证书,但是2013年离职了。
如果没有CRL,OCSP和时间戳的话:
第一行,2014年之后签出来的签名肯定无效的。
第二行,因为没有CRL和OCSP,2013年之后,签证证书无论是否吊销,签名还是可以验证通过的,到2014年之后显示签名验证通过但是不可信任。
第三行,2014年之前用AdobeReader 验证Alice签的文档都是有效的。但是2014年之后,如果签名里没有CRL,没有OCSP也没有时间戳的话,Adobe就会显示三角而不再是绿勾——显示不信任此签名,因为已不在签名证书有效期。
image
假设2013年吊销了Alice的证书
第一行:2013年之后的签名都是无效的
第二行:2013年之前验的签名是有效的,2013年之后的签名是无效的
image
理想状态下
第一行:2013年之后的签名无效
第二行:2013年之前的签名都应该可以验签成功
image

PS:152页的英文文档花一周勉强看完了,还要整理一下。

相关文章
|
8月前
|
Dart 安全 数据安全/隐私保护
Crack App | 某都市魔幻 FM 请求参数 sign 的加密分析
Crack App | 某都市魔幻 FM 请求参数 sign 的加密分析
|
4月前
|
存储 数据库
PACS(Picture Archiving and Communications System)图像存储与传输系统源码
PACS(Picture Archiving and Communications System)图像存储与传输系统源码
34 0
|
8月前
|
JavaScript 安全 算法
Crack App | 某资讯 app 参数 Signature 与 request_sign_q 加密逻辑分析
Crack App | 某资讯 app 参数 Signature 与 request_sign_q 加密逻辑分析
Google Earth Engine(GEE)——found inconsistent types: UInt16 and Byte.影像数据导出到Google硬盘中的错误
Google Earth Engine(GEE)——found inconsistent types: UInt16 and Byte.影像数据导出到Google硬盘中的错误
205 0
Google Earth Engine(GEE)——found inconsistent types: UInt16 and Byte.影像数据导出到Google硬盘中的错误
【1022】Digital Library (30 分)
【1022】Digital Library (30 分) 【1022】Digital Library (30 分)
72 0
|
数据安全/隐私保护
【错误记录】创建密钥报错 ( Key was created with errors: Warning: JKS 密钥库使用专用格式。建议使用 “ keyto “ 迁移到行业标准格式 PKCS12 )
【错误记录】创建密钥报错 ( Key was created with errors: Warning: JKS 密钥库使用专用格式。建议使用 “ keyto “ 迁移到行业标准格式 PKCS12 )
865 0
【错误记录】创建密钥报错 ( Key was created with errors: Warning: JKS 密钥库使用专用格式。建议使用 “ keyto “ 迁移到行业标准格式 PKCS12 )
SAP UI5 ComponentBase createMetaData signature - why is MD hard coded
Created by Wang, Jerry, last modified on Mar 23, 2015
115 0
SAP UI5 ComponentBase createMetaData signature - why is MD hard coded
|
文字识别 图形学
带你读《计算机文化》之一:Digital Content
在全球信息化大潮的推动下,我国的计算机产业发展迅猛,对专业人才的需求日益迫切,而专业教材的建设在教育战略上显得举足轻重,因此,引进一批国外优秀计算机教材将对我国计算机教育事业的发展起到积极的推动作用,也是与世界接轨、建设真正的世界一流大学的必由之路。
|
Web App开发 数据安全/隐私保护
漫说数字签名digital signature(转载)
前提:公钥和私钥是成对的,它们互相解密。加密数据:公钥加密,私钥解密数字签名:私钥加密,公钥解密 一、漫说公钥与私钥原理 1)鲍勃有两把钥匙,一把是公钥,另一把是私钥 image 2)鲍勃把公钥送给他的朋友们----帕蒂、道格、苏珊----每人一把。
1299 0