【问题标题】:adding digital signature to PDF with visible timestamp and Reason field using ESIG/DSS使用 ESIG/DSS 将数字签名添加到带有可见时间戳和原因字段的 PDF
【发布时间】:2019-02-15 05:26:51
【问题描述】:

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

  • 没有容器
  • PAdES 签名表
  • 封装
  • PAdES_BASELINE_LT 签名级别
  • SHA256 摘要算法

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

我还想填写签名的原因字段 - 随后当您使用 Adob​​e Acrobat Reader 等程序查看签名属性时会显示该字段。

到目前为止,我的问题如下,我似乎既找不到示例也找不到其他类型的信息。

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

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

  • getDataToSign - 这里是根据 PDF 内容计算摘要
  • signDocument - 这里是实际的签名 - (我猜是把签名嵌入到文档中吧?)。

我为这两个阶段提供了一系列参数,其中包括指定签名时间戳、原因以及我希望出现在第一页上的文本的视觉参数。我在这两个阶段使用相同的参数(因为我不确定我应该在哪个阶段给出哪个阶段)

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

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

【问题讨论】:

    标签: java pdf digital-signature pades


    【解决方案1】:
    1. 我已经解决了签名的原因字段的奇怪问题。
    2. 我似乎没有发现签名日期与时间戳权威提供的时间戳有任何不同。

    解释如下。

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

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

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

    据我在 DSS 代码中看到的(大约),已对上传的 PDF 的内存表示进行签名,并在 getDataToSign 期间计算其摘要 - 但结果被丢弃。

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

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

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

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

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

    这更像是 - 当然我对其他 cmets 和答案持开放态度。谢谢!

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2017-12-21
      • 1970-01-01
      • 2020-05-06
      • 1970-01-01
      • 1970-01-01
      • 2021-05-14
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多