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.完整性检查里的一些“莫名其妙”的坑
相关文章
|
25天前
|
存储 API 网络架构
【Azure 媒体服务】Azure Media Service上传的视频资产,如何保证在Transfer编码后音频文件和视频文件不分成两个文件?保持在一个可以直接播放的MP4文件中呢?
【Azure 媒体服务】Azure Media Service上传的视频资产,如何保证在Transfer编码后音频文件和视频文件不分成两个文件?保持在一个可以直接播放的MP4文件中呢?
|
26天前
|
API
【Azure 媒体服务】使用媒体服务 v3 对视频进行上载、编码和流式传输时遇见的AAD错误
【Azure 媒体服务】使用媒体服务 v3 对视频进行上载、编码和流式传输时遇见的AAD错误
|
4月前
|
Android开发
【苹果安卓通用】xlsx 和 vCard 文件转换器,txt转vCard文件格式,CSV转 vCard格式,如何批量号码导入手机通讯录,一篇文章说全
本文介绍了如何快速将批量号码导入手机通讯录,适用于企业客户管理、营销团队、活动组织、团队协作和新员工入职等场景。步骤包括:1) 下载软件,提供腾讯云盘和百度网盘链接;2) 打开软件,复制粘贴号码并进行加载预览和制作文件;3) 将制作好的文件通过QQ或微信发送至手机,然后按苹果、安卓或鸿蒙系统的指示导入。整个过程简便快捷,可在1分钟内完成。
|
4月前
|
API 数据安全/隐私保护
单页源码加密屋zip文件加密API源码
单页源码加密屋zip文件加密API源码 api源码里面的参数已改好,往服务器或主机一丢就行,出现不能加密了就是加密次数达到上限了,告诉我在到后台修改加密次数
38 1
在线JWT Token解析解码工具
在线JWT Token解析解码工具
889 0
|
Java PHP 开发工具
工银e生活开发脱坑日志(2)AES解码后乱码
工银e生活开发脱坑日志(2)AES解码后乱码
102 0
|
XML 消息中间件 JavaScript
服务端自定义生成PDF的几种方案
服务端自定义生成PDF的几种方案
|
JavaScript 算法 安全
某音乐App 抓包和signature签名分析
某音乐App 抓包和signature签名分析
某音乐App 抓包和signature签名分析
PDF Digital Signature(尚未完成)
因为上周微信群里有同事问了一个PDF 电子签名的问题:为什么前面的Digital Signature不会认为后续的Signature是对文档的更改。借此机会详细讲述一下PDF Digital Signature的机制,包括签名和验签。
1966 0