java - 使用 ESIG/DSS 向 PDF 添加带有可见时间戳和原因字段的数字签名

Question

我正在尝试理解并实现基于欧盟委员会资助的解决方案 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 设置原因。如有任何有用的见解，我们将不胜感激 - 谢谢。

Answer 1

1. 我已经解决了签名的 Reason 字段的奇怪问题。
2. 我似乎没有发现签名日期与时间戳机构提供的时间戳有任何不同。

解释如下。

就第一个案例而言，是我的错。详细地说，根据我的理解，使用 SigningService.fillParameters() 方法两次向 DSS 方法提供签名参数。

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

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

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

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

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

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

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

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

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