替换PDF中的签名内容 [英] Replace signature content in a PDF

问题描述

如何在iText中完成？我有一张带有客户签名的PDF。我需要为无符号属性添加一个ocsp响应。

我知道如何使用

$ b <$ p更改签名本身$ p> org.bouncycastle.cms.CMSSignedData.replaceSigners（...）。getEncoded（）


但我不知道如何使用替换PDF中的 PdfName.CONTENTS new PdfString（newSignature）.setHexWriting（true ）。如果我使用此代码：

  PdfDictionary other = new PdfDictionary（）; 
 other.put（PdfName.CONTENTS，new PdfString（newSignature）.setHexWriting（true））; 
 dicSignature.merge（其他）; 
  

其中 dicSignature 是包含签名，然后签名（在Adobe Reader中打开文档时）已损坏。

解决方案

当iText使用a处理文档时 PdfStamper 在正常模式下，它可以（并且经常）重新排列现有的PDF对象。这显然打破了任何现有集成签名的哈希值。此外，必须签名的字节范围也会发生变化。这很可能是你的问题。

当iText在附加模式下使用 PdfStamper 操作文档时，它会离开PDF按原样附加并附加其添加和更改。虽然这通常是保持集成签名不被破坏的方法，但是您不能以这种方式更改签名的内容，因为有一些关于嵌入签名的规则比一般的PDF更严格。因此，切换到追加模式不会解决您的问题。

因此，iText有一个显式方法来执行签名插入，而不会更改PDF：

  MakeSignature.signDeferred（PdfReader reader，
 String fieldName，
 OutputStream outs，
 ExternalSignatureContainer externalSignatureContainer）
抛出DocumentException，IOException，GeneralSecurityException 
  

它的名称是由于此方法最初用于延迟签名的用例，即首先准备PDF以进行签名（即添加所有字典和散列字节范围所需的其他必要结构，包括留下最终应注入签名容器的间隙），计算哈希值，并在本地存储准备好的PDF时将其发送到其他服务。一旦其他服务返回签名，就会找到准备好的PDF，并使用此方法将检索到的签名插入其中。

您的用例的唯一区别是差距中已有签名。但是，当使用 signDeferred 时，该签名将被您更新的签名覆盖。

说完这一切之后，你如果您希望在向无符号属性添加ocsp响应后， Adob​​e Reader使用这些信息进行验证，则可能会出乎意料。在根据 ISO-的集成PDF签名的上下文中32000-1 ，第12.8.3.3节 PKCS＃7 ISO 32000中使用的签名，

PKCS＃7对象应包含作为签名属性的撤销信息（PDF 1.6）：此属性可能包含对签名者进行撤销检查所需的所有撤销信息证书及其颁发者证书。由于吊销信息是签名属性，因此必须在计算数字签名之前获取。这意味着签名者使用的软件必须能够构建证书路径和相关的吊销信息。如果无法获得其中一个元素（例如，无法连接），则无法使用具有此属性的签名。

How can this be done in iText? I have a PDF with a signature from a client. I need to add an ocsp response to unsigned attributes.

I know how to change the signature itself using

org.bouncycastle.cms.CMSSignedData.replaceSigners(...).getEncoded()

but I don't know how to replace PdfName.CONTENTS in the PDF using new PdfString(newSignature).setHexWriting(true). If I use this code:

PdfDictionary other = new PdfDictionary();
other.put(PdfName.CONTENTS, new PdfString(newSignature).setHexWriting(true));
dicSignature.merge(other);

where dicSignature is the dictionary which contains the signature, then the signature (when the document is opened in Adobe Reader) is broken.

解决方案

When iText manipulates a document using aPdfStamperin normal mode, it can (and often does) re-arrange the existing PDF objects. This obviously breaks the hash value of any existing integrated signature. Furthermore the byte ranges which would have to be signed, change. This most likely is your problem.

When iText manipulates a document using aPdfStamperin append mode, it leaves the PDF as is and only appends its additions and changes. While this in general is the way to go to keep integrated signatures from breaking, you cannot change the content of a signature this way because there are stricter rules concerning embedding signatures than for PDFs in general. Switching to append mode, therefore, would not fix your problem.

Thus, iText has an explicit method doing a signature insertion without otherwise changing the PDF:

MakeSignature.signDeferred(PdfReader reader,
    String fieldName,
    OutputStream outs,
    ExternalSignatureContainer externalSignatureContainer)
throws DocumentException, IOException, GeneralSecurityException

Its name is due to the fact that this method originally is intended for the use case of deferred signing, i.e. first preparing the PDF for signing (i.e. adding all dictionaries and other necessary structures required to hash the byte ranges, including leaving a gap into which a signature container eventually shall be injected), calculating the hash value, and sending it to some other service while storing the prepared PDF locally. As soon as that other service returns the signature, the prepared PDF is located and the retrieved signature is inserted into it using this method.

The only difference to your use case is that there already is a signature in the gap. That signature, though, will be overwritten by your updated one when using signDeferred.

Having said all this, you may be in for a surprise if you expect that after you add an ocsp response to unsigned attributes, Adobe Reader uses these information for verification. In the context of integrated PDF signatures according to ISO-32000-1, section 12.8.3.3 PKCS#7 Signatures as used in ISO 32000,

the PKCS#7 object should contain [...] Revocation information as an signed attribute (PDF 1.6): This attribute may include all the revocation information that is necessary to carry out revocation checks for the signer's certificate and its issuer certificates. Since revocation information is a signed attribute, it must be obtained before the computation of the digital signature. This means that the software used by the signer must be able to construct the certification path and the associated revocation information. If one of the elements cannot be obtained (e.g. no connection is possible), a signature with this attribute will not be possible.

这篇关于替换PDF中的签名内容的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！