[
https://issues.apache.org/jira/browse/PDFBOX-5249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17414135#comment-17414135
]
Christian Appl edited comment on PDFBOX-5249 at 9/13/21, 10:52 AM:
-------------------------------------------------------------------
As promised, the updated patch (for the PDFBox trunk):
[^Encrypt_with_exposed_metadata_(09-13-2021).zip]
*Caveat:*
When trying to apply the original patch I encountered an issue with the test
certificate and keystore - for whatever reason those where destroyed by
inclusion in a patch file and where not even recognizable as a keystore
anymore. I don't know why that is, but I included the files in the given ZIP
archive, should it have happened again.
Neither the keystore, nor the private key are password secured, so you should
be able to access them and the tests should work fine using those.
*Also:*
I tried to create a PDFBox profile according to
[https://pdfbox.apache.org/codingconventions.html], should I have missed
something, please tell me.
*Also:*
The currently included tests check whether the "encryptMetadata" flag has been
set for different encryption methods. Those tests are not sufficient. Some day
I should provide tests, which try to directly extract the exposed metadata from
an encrypted document (without decrypting it).
Also - tests for the interoperability of all those features are currently
missing and should be added - when I find the time to do that.
was (Author: capsvd):
As promised, the updated patch (for the PDFBox trunk):
[^Encrypt_with_exposed_metadata_(09-13-2021).zip]
*Caveat:*
When trying to apply the original patch I encountered an issue with the test
certificate and keystore - for whatever reason those where destroyed by
inclusion in a patch file and where not even recognizable as a keystore
anymore. I don't know why that is, but I included the files in the given ZIP
archive, should it have happened again.
Neither the keystore, nor the private key are password secured, so you should
be able to access them and the tests should work fine using those.
*Also:*
I tried to create a PDFBox profile according to
[https://pdfbox.apache.org/codingconventions.html], should I have missed
something, please tell me.
*Also:*
The currently included tests check whether the "encryptMetadata" flag has been
set for different encryption methods. Those tests are not sufficient. Some day
I should provide tests, which try to directly extract the exposed metadata from
an encrypted document (without decrypting it).
Also - tests for the interoperability of all those features are currently
missing and should be added - when I find the time to do that.
> 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,
> Encrypt_with_exposed_metadata_(09-13-2021).zip,
> Exposing_metadata_during_document_encryption_.zip, exposedmeta.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, image-2021-08-03-10-17-14-965.png,
> image-2021-09-10-15-19-27-942.png, screenshot-1.png, screenshot-2.png,
> unencrypted.pdf
>
>
> *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]
