当前位置: 首页 > 知识库问答 >
问题:

我们收到了经过别有用心修改的签名PDF文件

陆才俊
2023-03-14

也许这件更适合你的安全感?我不确定。。。

以下是事实:

>

  • 我们有一个web应用程序,用户可以下载带有表单的PDF文档,他们填写表单,用电子证书签名,然后将其上传回我们的环境。

    我们已经展示了上传的文档被签名的情况,但它显示了签名后被修改的一些字段。如果我们检查PDF签名的完整性,就会发现签名后数据发生了更改,但签名是正确有效的。

    如果我们右键点击签名并选择“查看签名版本”,我们会看到签名时加载的真实数据。

    现在,这违背了我对电子签名功能的一般看法。如果在我签名后对文档(或加载到其中的数据)进行了任何更改,则该签名应无效,因为文档已被更改。

    PDF的行为似乎有所不同,因为不仅签名仍然有效,而且打开文档时看到的“默认版本”是最后一个,而不是签名版本。

    现在我想知道

    • 这是某种bug还是一种预期行为

    如果这是一种明确的行为,你该如何应对?

  • 共有1个答案

    谢海阳
    2023-03-14

    现在,这违背了我对电子签名功能的一般看法。如果在我签名后对文档(或加载到其中的数据)进行了任何更改,则该签名应无效,因为文档已被更改。

    PDF的行为似乎有所不同,因为不仅签名仍然有效,而且打开文档时看到的“默认版本”是最后一个,而不是签名版本。

    这是某种错误还是预期的行为?

    这是预期的行为。你必须意识到这里的两个特殊因素:

    >

    可以通过向现有文档追加内容来添加PDF,这一过程称为增量更新。这些更新可以再次签名等,也可以参考上面提到的答案:

    因此,通过增量更新对PDF进行更改,文档中现有的集成签名仍然正确地签署了各自的范围签名。尽管添加了更改,但它们在数学上仍然有效。

    此外,PDF的当前内容尤其是由最新的增量更新定义的,因此当您打开文档时,它会显示包含上次更改的内容,而不是已签名的内容。

    虽然这听起来像是PDF签名没有意义,但事实并非如此。ISO 32000-1规范明确规定了在对文档的认证(使用某些特殊标志签名)基础版本进行增量更新时允许进行哪些更改,Adobe在其Acrobat和Reader软件中对已签名但未经认证的文档进行了限制,请参阅此关于堆栈溢出的回答。

    特别是,最多允许以下更改:

    • 添加签名字段
    • 添加或编辑注释
    • 提供表单字段值
    • 数字签名

    如果这是一种明确的行为,你该如何应对?

    由于文档来自您,您可以首先将证书签名应用于文档,这只允许在您的用例中尽可能少的更改。

    然后可以为用户要签名的签名字段定义签名锁信息。在这些锁定信息中,您可以规定,在签署给定的签名字段后,许多表单字段应为只读。

    最后,您只接受仍包含您的认证签名且未添加任何不允许更改的返回PDF。

    实际上,有许多PDF经过认证,包含许多用于附加批准签名的字段,每个批准签名字段都与一些表单字段相耦合,这些表单字段在签名后将不再可编辑。所有签名字段签名后,所有字段都是只读的。

    有什么地方可以找到关于这件事的信息吗?(谷歌一次又一次地将我重定向到“如何签署PDF”文章)。

    您应该特别关注PDF规范ISO 32000-1和一些有关其软件行为的Adobe文档。您可以在堆栈溢出文档页面的底部找到上述链接指向的链接。

     类似资料:
    • 我正在编写一个服务,其中我用一个空容器预签名pdf文件,从pdf文件中提取一个字节范围的散列,并将其发送到另一个服务,这将允许用户使用移动电话对散列进行签名。我拿回一个证书,我将注入到预签名pdf文件中的签名容器中。 签名本身起作用,数字签名是有效的,但我只需要更改可见签名本身的文本。我认为这是可能的,因为可见签名实际上与证书本身没有任何关系,所以显示来自证书的名称只是一种方便,特别是在多个签名的

    • 本地的也是在svn上版本的基础上开发的,但是大量文件都修改过了,没有提交过。这一更新把很多文件合并了,还恢复了删除的文件,以及各种冲突,救命啊! svn上的版本完全不能用的,怎么保住我修改过的文件啊。

    • 目标是实现一个PDF签名过程,在该过程中,服务器(.NET核心服务)根据请求(Electronic)向客户端提供要签名的散列。然后,客户端使用通过PKCS#11接口从智能卡获得的私钥对给定散列进行签名。然后将签名发送回服务器,以便使用iTextSharp将其附加到PDF文件中。 使用node-webcrypto-p11使用智能卡令牌签名哈希的过程目前非常简单(需要进行大量的尝试和错误)。采用的算法

    • 作为我对客户机/服务器pdf签名研究的一部分,我测试了itext pdf延迟签名示例。不幸的是,我得到的合并空签名pdf和哈希值的pdf ie输出显示无效签名。 下面是我的代码片段 我正在使用pkcss11 usb令牌进行签名

    • 我想通过使用锁签署一个pdf文件。我正在使用PDFBox 2.0.9 我想实现的流量是: null 我可以签名,更改字段值,然后再次签名,签名就可以了。问题是当我在第二个签名之后更改字段的值时,签名仍然有效。我希望在上次更改后,第二个签名一定是无效的。

    • 目标是实现一个PDF签名过程,其中服务器根据请求向客户端提供要签名的哈希。然后,客户端使用通过PKCS#11接口从智能卡获得的私钥对给定哈希进行签名。然后,签名被发送回服务器,以便使用iTextSharp 5.5.4附加到PDF文件中。 在Acrobat Reader中查看签名时,我发现错误“自签名应用以来,文档已被更改或损坏”。 下面是我在服务器上计算哈希的方法。 客户端对给定的哈希签名后,我将