The Many Faces of PDF Security

Sample of the Week:

Adobe Acrobat as well as most other desktop products that create PDF files allow the user to add security to their files but there are two types of security the users can apply; Password Security and Certificate Security. If you have an Adobe LiveCycle Rights Management server, you can apply policy-based security as well. Additionally, by leveraging the Acrobat SDK to create new security handlers, a developer can create just about any type of security they want provided that they distribute a plug-in that knows how to decrypt the secured files created by that plug-in. PDF Security has many faces and many names.

And then there’s the type of security that shall remain nameless.

One of my favorite dialog boxes in the Adobe Reader (and Acrobat) is the Security tab in the Document Properties dialog. When you open a file that has been Reader Extended, it proclaims that “This document’s Security Method restricts what can be done to the document.” and then right below it… right below it… the Security Method is listed as “No Security.” The remainder of the dialog goes on to list what you can and cannot do to the document. What exactly is this nameless Security Method?

On the surface this dialog seems to contradict itself, but actually… it doesn’t. When a form developer creates a PDF form for distribution and needs to secure the file to be sure that and calculated fields and other scripts are protected from tampering, they’ll add password security to the form. If the developer also wants users of earlier versions of Adobe Reader to be able to fill and sign the form, they may also want to Reader Extend the file. In these cases, the dialog box that I mention above will show that the Security Method is “Password Security.” There are times, however, when an author only needs to Reader Extend their document; commenting workflows for example. In this case, the extra step of securing the file is unnecessary but they find that editing the document is still restricted in some way. PDF Security and Reader Extensions are not mutually exclusive however, even though Reader Extension is not considered a form of security, the use of either will add some restrictions to your document when viewed in Acrobat or Reader.

This is because the act of saving a PDF document with Reader Extensions adds a special  certificate to the PDF that tells the Adobe Reader that this particular file should be treated differently and should allow the kinds of editing that the author selected. If a document was distributed to allow for commenting in earlier versions of Reader but not form filling, you couldn’t fill in the form with Adobe Reader… period.

That explains why the Adobe Reader can’t modify a Reader Extended document in ways that are not permitted by the author… but Acrobat can do everything. Why are there still restrictions when the file is opened in Acrobat? The answer is surprisingly simple; Reader Extensions is based on the same technology as digital signatures and a digital signature becomes invalid if the document changes in ways that it isn’t expecting. The restrictions in Acrobat prevent the user from making changes that would invalidate the digital signature applied by Reader Extensions.

For more information on how digital signatures work, see Digital Signatures in a PDF on Adobe’s web site.

This is also true when a document has a certifying signature applied to it. Acrobat prevents the user from making changes that might invalidate the certification… but the document is still not considered to have a security method.

All of these editing restrictions is dependent on Acrobat and Reader obeying the permissions set in the document. But ideally, server-based applications would respect the same permissions in the same way… and the Datalogics PDF Java Toolkit does exactly that.

The PermissionsQuerySample in the Datalogics PDF Java Toolkit shows developers how to use the PermissionsManager and the ObjectOperations class to to query a document’s permissions.
Code Snippet:

PermissionsManager mgr = PermissionsManager.newInstance(pdfDocument);
boolean bAllowed =  mgr.isPermitted(ObjectOperations.FORM_DELETE);

When the document is secured, the encryption prevents the toolkit from making changes to the PDF document but when the document is only Reader Extended or Certified, it is unencrypted and the toolkit will be able to modify it just like any other PDF file. By using the PermissionsManager, the Java developer can understand what document operations or modifications would be permitted by Acrobat or Reader without knowing anything about either product and preventing their code from making changes that might break the certificate applied by the document author. Examining the permissions is particularly important when the developer may be using PDF inputs from sources that they don’t have direct control over, government forms or evidentiary documents for example.

View and download the PermissionsQuerySample  sample or get all the samples and documentation by requesting an evaluation of the Datalogics PDF Java Toolkit.

Share this post with your friends

Get instant access to the latest PDF news, tips and tricks!

Do you want monthly updates on the latest document technology trends?

By submitting the form, you agree to receive marketing emails from Datalogics. You may unsubscribe at any time. 

Like what you're reading?

Get Datalogics blogs sent right to your inbox!

By submitting the form, you agree to receive marketing emails from Datalogics. You may unsubscribe at any time.