Open Radar

 
After saving changes to an encrypted PDF, the PDF can no longer be opened. Similar reports: https://apple.stackexchange.com/q/436596/45340.

The root cause analysis is detailed below. See the Impact section at the bottom to see why fixing this issue should be a high priority.

# Background

In order to generate an encrypted PDF, the document creator specifies an “owner password” and a “user password”. The user password restricts who can view the document. The owner password restricts who can change the passwords themselves or modify the set of permissions (e.g. is the document printable, can text be copied, etc.).

The encryption key is derived from the user password and several document attributes such as the document ID. One of those document attributes is a Boolean indicating whether the document-level metadata stream is encrypted, stored in the `Encrypt` dictionary under the `EncryptMetadata` key. We will focus on this attribute in the below Problem section.

See the Encryption section of the PDF specification for more details: https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/PDF32000_2008.pdf.

# Problem

The `EncryptMetadata` key is optional. If not present, its default value is `true`.

Here is the problematic scenario:
1. We have an encrypted PDF where the `EncryptMetadata` key is absent, meaning the value is `true`.
2. We open the PDF in Preview and make a change (e.g. add an annotation).
3. Upon saving changes, Preview erroneously adds the `EncryptMetadata` key with a value of `false`.

The bug is that Preview changed the value for the `EncryptMetadata` key from `true` (the default value) to `false`.

Why does this bug matter? As noted in the above Background section, the value for the `EncryptMetadata` key is used in the algorithm to derive the encryption key. Since Preview changed the value, the original encryption key can no longer be derived, so the PDF can no longer be decrypted.

# Reproduction Steps

1. Open the `5006-r-fill-23e.pdf` attached file in Preview. The PDF is encrypted but still viewable and modifiable. This feature is detailed in the below Impact section.
2. Fill in the “First name” form field, save, and close the document.
3. Open the document. Preview now prompts for a password even though it did not previously. No password will succeed.

# Impact

PDF encryption may seem like a niche feature; however, it is actually quite mainstream as explained below.

The user password may be set to the empty string. In this case, the PDF is still encrypted but the encryption key can be trivially accessed by providing the empty string as the user password. Most PDF reader apps try the empty string before prompting the user for a password.

In theory, this allows the user to view the PDF but still allows the owner to use the permission system to restrict the set of actions that the user can perform. In practice, this security scheme is a little silly because it leaves the enforcement of the permissions to the PDF reader app, which may or may not decide to enforce the permissions. Nevertheless, some document creators (e.g. government institutions) still use this feature to provide some semblance of security.

All this to say that encrypted PDFs are being used in mainstream use cases. For example, here are some important encrypted PDFs:
- Canada Revenue Agency’s income tax return form: https://www.canada.ca/content/dam/cra-arc/formspubs/pbg/5006-r/5006-r-fill-23e.pdf
- Services Australia’s Medicare enrolment form: https://www.servicesaustralia.gov.au/sites/default/files/2024-03/ms004-2403en-f.pdf
- Swedish Social Insurance Agency’s information form: https://www.forsakringskassan.se/download/18.5317bde9174dd94ff58e9c/1691742877988/5456-registration-information-required-to-obtain-social-insurance-cover.pdf

Hopefully, that helps to illustrate the urgency of fixing the Preview bug.