使用ESIG / DSS将数字签名添加到具有可见时间戳和原因字段的PDF中

时间:2018-09-10 18:29:21

标签: java pdf digital-signature pades

我正在尝试了解和实施基于欧盟委员会赞助的Digital Signature Service project的解决方案。目前,在Nowina NexU客户端软件的帮助下,我目前已成功使用DSS-DEMO应用程序提供的抽象,该抽象在前面提到的github链接中提到。我的愿望是使用以下配置对PDF文档进行数字签名:

  • 没有容器
  • PAdES签名表格
  • 被包住
  • PAdES_BASELINE_LT签名级别
  • SHA256摘要算法

我希望签名具有可见的部分,即可以在文档的第一页上看到。 here在某种程度上得到了证明。就个人而言,我需要实际的签名时间戳和她的证书中的签名者的姓名。在上面的演示中,这是通过为签名函数提供“参数”来完成的。

我还想填写签名的“原因”字段-当您使用诸如Adobe Acrobat Reader之类的程序查看“签名”属性时,随后将显示该字段。

到目前为止,我的问题是以下问题,我似乎既找不到示例,也找不到与之相关的其他信息。

  1. 如果我想显示我将从时间戳记授权服务获得的签名时间戳记,我将如何获得它,因为与时间戳记服务器的通信是在签名过程中完成的,即在如上所述指定参数之后。我想我必须深入研究DSS代码,并亲自为我完成所有步骤。
  2. 当前,发生了一件奇怪的事情。当我指定硬编码的原因(如“ testtest”)或根本没有原因时,似乎签名被认为是有效的,或者至少是未知的。当我从其他结果填充它时,签名无效。因为像这样的事情通常不会因魔术而发生,所以我一定做错了什么。

代码大致是这样组织的-两台机器之间有REST通信-服务器和安装了NexU的客户端。 NexU与客户端计算机上的智能卡或任何其他证书存储区进行所有通信-它与服务器交换摘要值和已签名的摘要值。除其他外,服务器代码中有两个特定阶段:

  • getDataToSign-这里的摘要是根​​据PDF内容计算的
  • signDocument-此处是实际的签名-(我想将签名嵌入文档中?)。

我给这两个阶段都提供了一系列参数,这些参数除其他外,指定了要在首页上显示的文本的签名时间戳,原因和视觉参数。我在两个阶段都使用相同的参数进行此操作(因为我不确定应该在哪个阶段给出)

我的签名日期-使其尽可能接近时间戳授权服务器的时间戳是否合乎逻辑?好的-我将其设置为签名过程开始时我自己服务器的当前时间戳。

我正在使用PAdESSignatureParameters.setReason设置Reason。 感谢您提供任何有用的见解-谢谢。

1 个答案:

答案 0 :(得分:0)

  1. 我已经解决了“签名”的“原因”字段中的奇怪问题。
  2. 我似乎看不到签名日期前后与时间戳记管理局提供的时间戳有任何不同。

说明如下。

就第一种情况而言,这是我的错。详细地说,根据我的理解,使用SigningService.fillParameters()方法两次将签名参数提供给DSS方法。

  1. 在SigningService.getDataToSign(...)中,然后
  2. 在SigningService.signDocument(...)

这在两种方法中都非常重要,因为在第一次时,将计算待签名文档的哈希/摘要。由于我选择了要封装的签名,即包含在要签名的文档中,因此我们需要首先应用签名,然后根据该“最终”文档计算摘要。

据我在DSS代码中大致看到的那样,在getDataToSign期间对上载的PDF的内存表示形式进行了签名,并计算了其摘要-但结果被丢弃。

在实际的signDocument方法期间(在此之间,摘要已回到安装了NexU的客户端,并返回到已签名的服务器),上载的PDF再次被签名,其摘要再次被计算,但这一次是实际的签名摘要(我们从客户端获得的摘要)也应用于文档-并且此操作的内存结果作为签名的PDF文档发送回客户端。

我做错了,是在第一次,我丢失了要添加的变量作为Reason(它在模型属性的某个地方丢失了-我没有在请求之间的某个地方传递它),我传递给getDataToSign的第一个参数映射的结果不同于第二个参数映射-因此,逻辑上是,文档的实际哈希/摘要与保存的签名中的摘要不同(因为当时计算了要签名的摘要,我没有通过原因。这就是为什么当我传递一个硬编码的值时,因为它是硬编码的,所以在两次调用fillParameters时都存在该值。我知道这是一个愚蠢的错误。我应该知道这一点,因为将原因(或其他字段,例如位置)传递给签名绝对没有任何困难。

顺便说一句,签名使用Apache PDFBox完成,并且增量完成。

关于第二件事,我们决定保持原样,尽管在签名时间戳和时间戳授权者之间存在相当大的差距。我真的不知道在这种情况下应该允许的差距是多少。我想这是因为

  1. 我的服务器的本地时间可能会稍微偏离正常时间
  2. 因为签名的整个过程都是在两台机器(安装了NexU的服务器和客户端以及智能卡)之间进行,并且因为出现了不同的对话框,要求输入密码等,所以这一切都会推迟在最后一步中完成签名并调用时间戳记机构。当然,我不确定这是否是一个问题,因为从理论上讲,时间戳记权威机构不知道实际的内容已更改-在这种情况下会触发先前的错误。

更像是-当然,我愿意接受其他评论和答案。谢谢!