[
https://issues.apache.org/jira/browse/PDFBOX-5249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17390361#comment-17390361
]
Christian Appl commented on PDFBOX-5249:
----------------------------------------
Should have started there - sorry.
The ZIP [^AdobeDCCertAES128exposedMetadata.zip] contains everything required to
reproduce the intial issue.
*Document source:*
Some test document is encrypted via Adobe DC "Certificate Security" using the
contained "test.p12" Keystore, using the following additional settings:
!image-2021-07-30-09-21-37-707.png!
*Claim: The following Test method leads to an exception using the given files
and should not lead to an exception.*
{code:java}
@Test
public void testDCDocFailure() {
File parentDirectory = new File("someParentDirectory");
File docFile = new File(parentDirectory,
"AdobeDC-Cert-AES128-exposedMetadata.pdf");
File keyStore = new File(parentDirectory, "test.p12");
try {
PDDocument document;
InputStream keyStoreStream = new FileInputStream(keyStore);
try {
document = PDDocument.load(docFile, "", keyStoreStream, "test");
} finally {
keyStoreStream.close();
}
try {
assertEquals(3, document.getNumberOfPages());
} finally {
document.close();
}
} catch (Exception ex) {
ex.printStackTrace();
}
}{code}
Claim 2: Which does succeed, when the given patch is applied.
*Claim 3: Otherwise resulting in the following parsing exceptions (indicating
usage of an erroneous document decryption key):*
!image-2021-07-30-09-13-49-394.png!
> AES128 PK decryption failure for documents with exposed metadata.
> -----------------------------------------------------------------
>
> Key: PDFBOX-5249
> URL: https://issues.apache.org/jira/browse/PDFBOX-5249
> Project: PDFBox
> Issue Type: Improvement
> Components: Parsing, Writing
> Affects Versions: 2.0.24
> Reporter: Christian Appl
> Priority: Major
> Attachments: AdobeDCCertAES128exposedMetadata.zip,
> Exposing_metadata_during_document_encryption_.zip,
> image-2021-07-29-15-28-15-341.png, image-2021-07-29-15-30-35-928.png,
> image-2021-07-29-15-31-14-097.png, image-2021-07-30-09-13-49-394.png,
> image-2021-07-30-09-21-37-707.png
>
>
> *TL;DR:*
> I attempted to decrypt a AES128-PK secured document with exposed metadata
> and encountered an Exception, even though the decryption should have worked.
> I tried to fix the cause and tried to implement an improved handling for
> "EncryptMetadata" during AES en-/decryption on the way.
> *Initial Issue:*
> When creating a PDF document (for example using Adobe Document Creator) and
> selecting AES128 Public Key ("Certificate Security") encryption, one can
> select to expose the metadata by excluding it from encryption.
> (Via setting the encryption dictionary "EncryptMetadata" to false and so
> forth.)
> If it is attempted to decrypt such a document using PDFBox, an error is
> encountered - indicating the failure to use the given Material (Private
> Key/Certificate) to identify a recipient of that document. This exception is
> encountered even if the material is verifably usable to decrypt the document
> in other tools.
> *Debugging:*
> The AES128 (V4) encryption leads to changes to the actual encryption key,
> when metadata is exposed. As is documented in PDF 7 reference manual "7.6.4.3
> Public-Key Encryption Algorithm" such a encryption key shall contain 4bytes
> with content 0xFF, that shall indicate the exposed metadata. (Which is then
> included in the SHA-1 message digest and truncated to a given key length.)
> As far as I could see in class
> PublicKeySecurityHandler#prepareForDecryption() those bytes were not included
> in the message digest.
> Therefore I had to assume, that the given decryption material was failing for
> that reason - as the document's strings and streams would most likely be
> encrypted with a key, that was including those bytes.
> Hence I altered the method as follows:
> !image-2021-07-29-15-30-35-928.png!
> Also: The PDFBox implementation claims (rightly so and according to
> specification), that the document's encryption dictionary shall hold a field
> "EncryptMetadata", that shall easily identify whether metadata is exposed in
> a given document.
> But the document I produced, instead contained said Field as part of the
> "DefaultCryptFilter":
> !image-2021-07-29-15-28-15-341.png!
> I was unable to find this behaviour documented in the reference manual, but
> decided that I would prefer if it was supported anyway. Resulting in further
> changes:
> !image-2021-07-29-15-31-14-097.png!
> **I succeeded - The document could now be decrypted using the given Material.
> *Follow-up Questions:*
> While examining the classes "StandardSecurityHandler" and the
> "PublicKeySecurityHandler" I found comments mentioning or solving some issues
> concerning the "EncryptMetadata" flag and it's consequences for other
> structures.
> The question was, whether I could implement that feature for V4 and V5
> encryption - and so I did, resulting in the patch you will find in the
> attachments.
> *Caveat:*
> I'm aware that some of the changes hereby made could be problematic for some
> reason, that I can not see yet. (especially those made to "COSBase"(!) and
> "PDCryptFilterDictionary") Those changes are naive and are made under the
> premise to reach the given goal most directly and as fast as possible.
> I would assume, that this patch is rather a mere suggestion, than something
> that can or should be merged directly and without inspection.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
