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月前
|
应用服务中间件 网络安全 开发工具
利用 KMS 对文本信息进行签名验签实践
通过阿里云的KMS产品针对文件或者证书文件进行签名验签,可以有效解决攻击者针对敏感文件、重要文件在传输过程中被篡改,其次可以实现证书双向认证过程中的证书合法性校验,真正做到传输链路安全。
86 0
|
8月前
|
数据安全/隐私保护
[虚幻引擎] UE DTBase64 插件说明 使用蓝图对字符串,字节数组或文件进行Base64加密解密
本插件可以在虚幻引擎中使用蓝图对字符串,字节数组,文件进行Base64的加密和解密。
98 0
|
8月前
在线JWT Token解析解码工具
在线JWT Token解析解码工具
589 0
|
12月前
|
XML 消息中间件 JavaScript
服务端自定义生成PDF的几种方案
服务端自定义生成PDF的几种方案
|
JavaScript 前端开发 数据安全/隐私保护
js前端使用AES加解密及在线解密工具验证
js前端使用AES加解密及在线解密工具验证
507 0
js前端使用AES加解密及在线解密工具验证
|
安全 Android开发 Windows
Adobe Reader、Acrobat和Flash成攻击热点
据国外媒体报道,Adobe公司近日发布其公司Reader、Acrobat和Flash产品的零日漏洞警告,并已开始着手补救,但目前尚未有对应补丁推出。 虽然目前公司尚未有补丁正式发布,但是已经发布了补救方案来有效组织后续入侵者。
848 0
|
API
google reader api,互联网营销
Google Reader 是一个使用了大量JavaScript构建的feed聚合器,它能非常及时地抓取最新的feed数据。Google的Ajax前台调用到的数据采用了Atom格式,这种数据技术降低了Google Reader的开发难度,同时也使得第三方应用很容易对其进行扩展。
1027 0