代码之家 › 专栏 › 技术社区 › hello_earth

使用esig/dss向具有可见时间戳和原因字段的PDF添加数字签名

pades digital-signature pdf java

0

hello_earth · 技术社区 · 6 年前

我正试图理解并实施一个由欧盟委员会赞助的解决方案。 Digital Signature Service project . 在NowinaNexu客户机软件的帮助下,我目前已经成功地使用了上述Github链接中提到的DSS-DEMO应用程序提供的抽象。我希望用以下配置对PDF文档进行数字签名:

无容器
PADES签名表
包膜的
pades_baseline_lt签名级别
sha256摘要算法

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

我还想填写签名的原因字段,然后在使用类似AdobeAcrobat Reader的程序查看签名属性时显示该字段。

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

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

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

getdatatosign-此处根据PDF内容计算摘要
签名文档-这里是实际签名(我想是将签名嵌入到文档中吗?)发生。

我将为这两个阶段提供一系列参数,其中包括指定要在第一页上显示的文本的签名时间戳、原因和视觉参数。这两个阶段的参数相同(因为我不确定应该给出哪个阶段)

我的签名日期——它是否合理地尽可能接近时间戳授权服务器的时间戳?好的-我正在将其设置为签名过程开始时我自己服务器的当前时间戳。

我正在使用padesSignatureParameters.setReason设置原因。感谢您的帮助-谢谢。

1 回复 | 直到 6 年前

1

0

hello_earth 6 年前

我用签名的原因字段解决了这个奇怪的问题。
我似乎看不出在签署日期周围有任何不同于时间戳权威提供的时间戳的方式。

解释如下。

就第一个案例而言,这是我的错。为了详细说明,根据我的理解,使用signingService.fillParameters()方法将签名参数提供给DSS方法两次。

在SigningService.GetDataToSign(…)中,然后
在SigningService.SignDocument(…)中

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

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

在实际的signdocument方法期间(在此期间,摘要已返回安装了nexu的客户机,并返回到已签名的服务器),上载的PDF将再次签名,其摘要将再次计算,但这次实际的已签名摘要(我们从客户机获得)也将应用于该文档以及IS操作作为已签名的PDF文档发送回客户端。

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

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

至于第二件事,我们决定保持原样,尽管签名时间戳和时间戳权限1之间有一个相当大的差距。我真的不知道在这种情况下应该允许什么样的差距。我想这是因为

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

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