iText的signatureCoversWholeDocument（）与Acrobat Reader有多可靠？ [英] How reliable is iText's signatureCoversWholeDocument() vs Acrobat Reader?

问题描述

我想仔细检查iText的 signatureCoversWholeDocument（）的可靠性。

I'd like to double check how reliable is iText's signatureCoversWholeDocument().

我有一份文件使用一个签名，为 signatureCoversWholeDocument（）返回 false ，但Adobe Acrobat Reader不报告任何错误文件。

I have a document with one signature, which returns false for signatureCoversWholeDocument(), but Adobe Acrobat Reader doesn't report anything wrong with the document.

iText的方法似乎是总结它在 getSignatureNames（）中获得的字节范围：

iText's method seems to be to sum up the byte range it gets in getSignatureNames():

public ArrayList<String> getSignatureNames() {

    .....

    PdfArray ro = v.getAsArray(PdfName.BYTERANGE);
    if (ro == null)
        continue;
    int rangeSize = ro.size();
    if (rangeSize < 2)
        continue;
    int length = ro.getAsNumber(rangeSize - 1).intValue() + ro.getAsNumber(rangeSize - 2).intValue();

...然后将其与文档长度进行比较：

...and then compare it to the document's length:

public boolean signatureCoversWholeDocument(String name) {
    getSignatureNames();
    name = getTranslatedFieldName(name);
    if (!sigNames.containsKey(name))
        return false;
    return sigNames.get(name)[0] == reader.getFileLength();
}        

在我的情况下，签名字节范围是 [0 ，190,33282,382800] 总计 382800 + 33282 = 416082 ，但文件大小 665186

In my case the signature byte range is [0, 190, 33282, 382800] which sums up to 382800 + 33282 = 416082, but the document size is 665186

如果我用文本编辑器打开PDF，我也会在 [0,190,33282,382800] 中看到相同的签名字节范围。如果我查看具有完全符合文件大小的字节范围的PDF，那么通过iText验证的那些没有问题。

If I open the PDF with a text editor I also see the same signature byte range inside [0, 190, 33282, 382800]. If I look at PDFs that have byte ranges that add up perfectly to the file size, those get validated with iText no problem.

我看到的另一个区别是iText的

Another difference I see is that iText's

(AcroFields) fields.getTotalRevisions() = 2

但在Acrobat Reader中我只看到一个版本。

But inside Acrobat Reader I only see one revision.

我们的客户非常确信他们的文件是否正确签名，所以我我很困惑......

Our client is pretty convinced that their documents are signed properly, so I'm quite confused...

基本上我的问题是

• 是iText使用这种方法（总结字节范围）100％可靠吗？


• Acrobat Reader使用什么方法来验证整个文档是否已签名？


• 如果签名未涵盖整个文档，Acrobat Reader是否显示错误？

推荐答案

不幸的是，OP没有分享PDF样本来说明他的观点。一般来说，但是：

Unfortunately the OP didn't share a sample PDF to illustrate his point. In general, though:

我有一个带有一个签名的文件，它返回 false 对于 signatureCoversWholeDocument（），但Adobe Acrobat Reader不会报告文档有任何问题。

I have a document with one signature, which returns false for signatureCoversWholeDocument(), but Adobe Acrobat Reader doesn't report anything wrong with the document.

这并不一定意味着什么都不对。请参阅信息安全堆栈交换中的此答案，了解单个PDF中多个签名的工作原理：第一个签名仅涵盖第一次修订，第二次修改，第二次修改等等......第一次签名不是覆盖整个文档是完全自然的。

This does not necessarily mean that anything is wrong. See in this answer on Information Security Stack Exchange how multiple signatures in a single PDF work: The first signature covers only the first revision, the second one the first two revisions, etc... It is completely natural for the first signature not to cover the whole document.

此外，签名PDF的添加本身不需要签名。即您可能有一个PDF，其中第一个修订版已签名，然后一些添加为增量更新。在这种情况下，签名不会覆盖整个文档也是完全自然的。

Furthermore, additions to a signed PDF do not themselves need to be signed. I.e. you might have a PDF in which the first revision is signed and then some additions as incremental update. In this case it is also completely natural for the signature not to cover the whole document.

Adob​​e Reader是否应该将此作为问题显示？不一定：允许对签名文档进行某些更改！阅读有关堆栈溢出的此答案。

Should Adobe Reader show this as an issue? Not necessarily: Certain changes to a signed document are allowed! Read this answer on stack overflow.

因此，我会假设您有一个签名表格，其中已提交参赛作品;或者添加了其他注释的签名任意PDF。

Thus, I would assume you have a signed form into which entries have been filed in; or a signed arbitrary PDF to which other annotations were added.

这也可以解释修订计数的差异。 Adobe仅在其修订版计数中计算每个签名修订版，而iText也将最终的未签名增量更新计为单独版本。

That would also explain differences in revision counts. Adobe only counts each signed revision in its revision count while iText also counts a final, unsigned incremental update as a separate revision.

因此，

• 这是iText使用的方法（总结字节范围） ）100％可靠吗？

总结后两个数字以确定签名修订版的大小完全没问题。可能会有额外的数据附加为允许更改的增量更新。

Summing up the latter two numbers to determine the size of the signed revision is completely ok. There simply may be additional data appended as an incremental update with allowed changes.

（但是有一个不同的问题：字节范围的差距必须与为签名容器保留的空间。据我所知，iText没有严格执行此。）

(There is a different issue, though: The gap in the byte ranges has to coincide with the space reserved for the signature container. As far as I remember iText does not strictly enforce this.)

• 什么方法是否使用Acrobat Reader来验证整个文档是否已签名？

Adob​​e Reader检查签名就像iText一样。但是，它会检查是否有任何添加是允许的更改，如上面引用的文档中所述。如果文档最后一次签名后的增量更新仅包含此类允许的更改，Adobe Reader会认为该签名对整个文档有效。

Adobe Reader checks the signatures just like iText does. In addition, though, it checks whether any additions are "allowed changes" as described in the documentation referenced above. If an incremental update after the last signature of a document contains only such allowed changes, Adobe Reader considers the signature valid in respect of the whole document.

（请注意： Adobe Reader用于确定是否允许更改的算法，部分仅允许进行更改，因为Adobe Reader本身已完成更改并且部分无法识别不允许的更改。）

(Beware, though: The algorithms Adobe Reader uses to determine whether changes are allowed, partially only allow changes done as Adobe Reader would have done them itself and partially don't recognize disallowed changes.)

• 如果签名未涵盖整个文档，Acrobat Reader是否显示错误？

不一定，只有额外内容中有不允许的更改。

Not necessarily, only if there are disallowed changes in the extra content.

这篇关于iText的signatureCoversWholeDocument（）与Acrobat Reader有多可靠？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！