You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by "Christian Appl (Jira)" <ji...@apache.org> on 2021/09/10 13:20:00 UTC
[jira] [Updated] (PDFBOX-5249) AES128 PK decryption failure for
documents with exposed metadata.
[ https://issues.apache.org/jira/browse/PDFBOX-5249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christian Appl updated PDFBOX-5249:
-----------------------------------
Attachment: image-2021-09-10-15-19-27-942.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, 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: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org