java检测自身签名_使用签名检测PDF更改

签名和验证工作正常，直到文件第二次签名(使用用户的证书) . 在那之后，第一个签名以某种方式变得无效

正如在评论中已经阐明的那样，如果希望第一个签名保持有效，则第二个签名必须以附加模式(iText lingo)/作为增量更新(PDF规范术语)应用 . 否则，签名字节很可能会改变，并且签名的哈希值不再匹配 .

是否可以检查文件是否在2个签名之间被修改了？

更确切地说，您的问题应该是是否可以检查两个签名之间的文档修改是否超出嵌入第二个签名的可能变化 .

简而言之：在您的用例中有可能，但仍然意味着相当多的工作和使用iText低级API . 详细地：

一般来说，这并非易事，因为可视化地添加新的签名

更改了相关页面的注释，因为签名可视化是一个小部件注释;

更改PDF表单定义，因为签名锚定为表单字段;

可以为其他表单字段创建外观流，以便在签名文件中修复它们的确切外观;

可以更改元数据流以记录签名行为;

可能会更改文档的数字安全存储;

可能会更改 .

因此，检查变化是否属于这些类别中的任何一个都是非常重要的 .

此外，你必须检查其他作弊，例如签名可视化可能覆盖整个页面并显示该内容的操纵版本......

但是你说你的用户

必须使用Adobe Acrobat签名

这可能会使您的任务变得可行：如果您使用Adobe Acrobat将样本签名添加到您之前签署的许多文档中，则可以分析Adobe Acrobat在签名时通常在文档中更改的内容 .

使用这些知识，您可以实现一个类，该类检查是否仅存在这些更改 .

如果不是 - 以编程方式(使用itextsharp)的替代方法是检查PDF文件在生成之后和签名之前是否已更改？

如果没有您应用的第一个签名，情况将变得更加困难，因为用户的PDF签名软件没有理由限制文档中的内部结构更改，只要它们对其外部行为没有影响 . 所以我会尝试使用双重签名 .

或者，您可以尝试将原始文档和用户签名的版本呈现为位图并进行比较 . 应该只在放置用户签名可视化的区域中存在差异 . 这不会验证交互式PDF功能，但至少会验证打印输出的完整性 .

渲染还不是iText的一个特性，但解析框架同时已经发展到足以作为渲染功能的基础 .

应用第一个签名甚至可以帮助防止意外更改：如果您为用户提供空签名字段并自己使用证书签名，则可以将“允许的更改”限制为仅填充该空签名字段，并且通常使用Adobe Acrobat除非另有明确说明，否则应尊重此类限制

有关集成PDF签名的背景，请查看信息安全堆栈交换中的this answer .