Adobe Reader验签结果分析(一)

简介: Adobe 对于PDF Digital Signature验证


下图是Adobe旗下PDF软件验证digital Signature时会出现的标记

image


图1


由于Acrobat已经到Xi了所以根据版本大家可能会看到两套标记
上面一行是6,7,8版本的老标记
下面一行是9,X往后的版本的新标记

第一列的红叉是一般指文档存在完整性问题,即此签名无效——文档被篡改。也有其他原因,如签名是在签名证书已失效(不在有效期或者已吊销)的情况下被签署的——这个很难出现,一般会在签署时就会做有效性检查的。( 后面试着做一个例子)
第二列的黄三角是指签名正确,签名结果不可信,但文档未被修改,造成的原因有很多,涉及的情况也很复杂,下面会详细分析。
第三列的蓝勋章是使用Adobe旗下软件的自带的签名功能签出的签名。
第四列的绿勾文档未篡改签名可信,是最理想的状态。

数字签名三要素:
1.the integrity of the document— we want assurance that the document hasn’t been changed somewhere in the workflow——完整性,必须确保在(被一系列人依次签名的)工作流中的文档都没有被修改过
2.the authenticity of the document— we want assurance that the author of the document is who we think it is (and not somebody else)——真实性,必须确保文档的作者(即签名者们)身份的真实性,是我们所认为的人而不是其他人
3.non-repudiation— we want assurance that the author can’t deny his or her authorship——不可抵赖的,必须确保作者(签名者)们不能抵赖他们的作者的身份(签名行为)。

点击签名后可以看到签名属性,从签名属性上看可以大致得出Adobe对PDF数字签名的检查项目,不难得出都是从三要素出发的。

image


图2


A.完整性:3,4
B.真实性:5,6,7,8,9,10,11
C.不可抵赖性:10
D.参考:1,2
排除文档被篡改,最有可能出现的情况就是黄三角,下面开始详细分析这种情况:
产生这种情况

1.时间戳无法验证(如图3修订版3:签名包含嵌入时间戳,但时间戳无法验证)或无时间戳(如图3修订版6:签名时间来自签名者计算机的时钟)的情况:
A.当前时间(2017-11-24),签名证书不在有效期(如图3,签名者的身份无效,因为其已过期或尚未生效)

image


图3


image


图4


如果没有时间戳的话,签名时间会以机器时间为准。——换言之,通过修改机器时间就能使用已过期的证书进行签名
如图5将机器时间调至2022年,修订版1所对应的签名证书有效期为2017/02/27-2019/02/27,验签结果就由绿勾变为黄三角。

image


图5


2.当前时间,签名证书已被吊销。(暂时没有图,后面补)
证书的吊销信息需要在签名时添加CRL(Certificate Revocation List)或者OCSP(Online Certificate Status Protocol)信息。(细化一下CRL和OCSP)

使用CRL:
A.通过签名证书链的CRL Url在线获取CRL。(Url可能会改变)
B.通过证书链获取CRL
C.通过离线文件获取CRL
使用OCSP:
我们可以通过http请求来验证证书的状态,这样就可以不用在文件中嵌入体积庞大的CRL了。

如何选择CRL和OCSP:
A.文件大小
对比一下同一个文件分别以嵌入CRL和OCSP的形式签名后的文件大小,一个例子中,CRL版有10M 而OCSP版只有28K,当然差距不会永远这么大,这取决于CA的策略,有些CA会将它们所有的证书的吊销信息保留一个文件中(PS:这个有点夸张,现在用的应该不多了),而另一类CA则不会保留已过期证书的吊销信息。
为了进一步减小CRL,CA还会进行分层分类(常规证书,U盾证书,HSM(Hard Security Module (安全卡,门禁等)),对于小规模使用的如HSM,会比使用OCSP还小。
B.性能
CRL更快,OCSP需要网络连接,因此当需要批量验证时,CRL是更好的选择。
C.法律因素
有些国家,验签时不仅需要验证证书未被吊销,而且还得验证证书是否存在。以德国为例,未出现在CRL上的证书,并不意味着这些证书真实存在。

现在假设下面这种场景:
张三的证书有效期为2012-2014,但是2013年张三离职后,证书被吊销。
图6,7,8中的每行箭头代表在起始时间点签署的签名随时间变化的验证状态。
一、在无时间戳无吊销信息的情况下:

image
图6


A.2014年签署的签名,由于证书过期后再签署自然是红叉
B.2013年签署的签名,证书被吊销,但是由于没有吊销信息,依然可以通过验证,但在证书过期后,因为没有时间戳,签名时间可以被伪造,因此会变为不可信。
C.2012年签署的签名,证书未被吊销,同时也仍旧在有效期内,到2014年前都是绿勾通过,但是2014年后会降级为不可信任。

二、有CRL的情况

image
图7


A.2013年签署的签名,证书已被吊销,红叉不通过。
B.2012年签署的签名,2013年前绿叉通过,13年后变为红叉。
三、有CRL 有时间戳的情况:

image
图8


A.2013年签署的签名,证书已被吊销,红叉不通过。
B.2012年签署的签名,由于有时间戳,可以证明签名是在证书有效(未吊销,已生效未过期)的情况下签署的,只要时间戳可用就可以一直保持绿勾通过。

现在问题来了,从图3可以看到即便嵌入了时间戳也会出现时间戳无法验证的情况,毕竟我们不愿意看到一定时间以后签名变成不可信,有没有什么办法可以使得签名有长时间的验证效力一直保持“绿勾”呢?见图3修订版6,签名已启用LTV(Long-Term-Validation)。

下期预告:1.更新LTV相关内容

            2.完整性检查里的一些“莫名其妙”的坑
相关文章
|
2月前
|
IDE 开发工具 数据安全/隐私保护
Python编程实现批量md5加密pdf文件
Python编程实现批量md5加密pdf文件
|
4月前
|
API
【Azure 媒体服务】使用媒体服务 v3 对视频进行上载、编码和流式传输时遇见的AAD错误
【Azure 媒体服务】使用媒体服务 v3 对视频进行上载、编码和流式传输时遇见的AAD错误
|
7月前
|
API 数据安全/隐私保护
单页源码加密屋zip文件加密API源码
单页源码加密屋zip文件加密API源码 api源码里面的参数已改好,往服务器或主机一丢就行,出现不能加密了就是加密次数达到上限了,告诉我在到后台修改加密次数
46 1
|
7月前
|
存储 算法 安全
在线SM4加密/解密工具
在线SM4加密/解密工具支持快速、便捷地对数据进行SM4算法加密与解密。
529 0
|
对象存储
使用流式下载从阿里OSS获取PDF文件时,确保正确处理输入流的读取。
使用流式下载从阿里OSS获取PDF文件时,确保正确处理输入流的读取。
156 1
|
存储 域名解析 安全
Nest 实现OSS 服务端签名直传并设置上传回调
Nest 实现OSS 服务端签名直传并设置上传回调
597 0
|
Java PHP 开发工具
工银e生活开发脱坑日志(2)AES解码后乱码
工银e生活开发脱坑日志(2)AES解码后乱码
110 0
|
XML 消息中间件 JavaScript
服务端自定义生成PDF的几种方案
服务端自定义生成PDF的几种方案
如何使用工具验签
说明:    工具下载地址:【点击查看】    工具仅支持异步通知验签,不支持同步验签。    注意:工具解压建议放到英文目录下运行。  验签流程:    1.解压文件》打开secret_key_tools_RSA_win文件夹》双击运行RSA签名验签工具.
637 12
|
安全 Android开发 Windows
Adobe Reader、Acrobat和Flash成攻击热点
据国外媒体报道,Adobe公司近日发布其公司Reader、Acrobat和Flash产品的零日漏洞警告,并已开始着手补救,但目前尚未有对应补丁推出。 虽然目前公司尚未有补丁正式发布,但是已经发布了补救方案来有效组织后续入侵者。
875 0