There is a confusion about what features of Acrobat and PDFs in general offer by way of securing documents. I would like to do a very cursory overview of the items that I have so far seen users consider “security.”
To be clear, by “security” I mean the ability or inability to access the contents of the PDF, thus safeguarding information from entering the wrong hands.
1) Not Security-Oriented
Unlike on your Dollar, Euro or Pound notes (etc), the watermark is NOT a guarantee of integrity, veracity or anything at all.
In the PDF world, a visible watermark only exists as a notification mechanism. If a watermark says “Confidential,” it is only warning the viewer that the content is confidential, but will not otherwise try to make itself indelible.
It is meant to be a very visible mark on the page, with the added property of not completely obfuscation the items underneath (allowing readability to be maintained)
A Certified PDF carries a digital signature certifying that certain things can and cannot be done with it. Namely:
-A PDF certified to run privileged scripts can run scripts requiring special privileges, such as writing to the hard drive.
-A PDF certified to be unmodified means that so long as the PDF has been modified withing given parameters (fields filled in for example), then the certification will hold. If a visual aspect of the PDF changes though, the certification will be broken, and Acrobat will report an error.
Certification covers a number of other use cases as well, but I hope the above illustrates sufficiently why this is a not a security-related item, rather a usability concern.
c) Reader Extensions Usage Rights
Acrobat and LiveCycle can extend the usability of PDFs to Adobe Reader, the free PDF viewing application. By extending usability features, you can allow Reader users to fill in forms and save that content, add comment annotation, and other functionality.
However, if the same extended form is opened in Acrobat, the user can do to the PDF pretty much anything that Acrobat has at its disposition.
REUR adds functionality to Reader. Any extra functionality it does not add is a restriction that Reader already had.
a) Password Protection
Using password protection, you can encrypt the PDF so it can only be opened by a person who has the password. You can also prevent the PDF from being used in certain ways, such as modifying the pages.
You cannot however track who has opened the PDF, when and at what IP. That is the domain of Rights Management.
b) LiveCycle Rights Management (aka Policy Server)
LiveCycle 7 introduced Policy Server, later renamed to LiveCycle Rights Management. Adobe LiveCycle/ADEP Rights Management protects your documents from being accessed by parties you have not authorized to do so.
This allows the document publisher to:
-protect with a user ID/password combination
-force the identification to go to a remote server
-restrict usage rights depending on the user’s group
With this is mind, you must be aware that ONLY persons that are trusted should be granted a login to the document. If, on a document that you want to protect, you have granted access to a person you do not Trust Entirely, you have opened the door to having your information stolen – be it via sreen grab, or simply photographing the screen with a camera.
It’s like having the best vault to protect your secrets and giving the secretary the passcode for safekeep. If the secretary is honest, they will leave your items well alone. But if you did not trust them in the first place, the vault, for all its technology and mechanisms, cannot protect your secrets – because you’ve willingly given the key to the intruder.
3) A note on Rights Management and SSL
To use Adobe LiveCycle Rights Management, you need to setup the server to be able to server SSL connections, and configure the callback URL appropriately in the LiveCycle/ADEP Rights Management service configuration.
Note that if the server’s SSL certificate specifies external CRLs, you must be able to grant the client application free network access to the CRL’s URL – otherwise the connection will fail.
I hope that this article has allowed you to understand the subtle difference between the perceived security tools and actual security features – and most importantly, the fact that if you suspect a user may likely try to do Bad Things with your information, you should not give them the keys to the vault.
My own Rule Number One of security is: “don’t trust anyone, not even those you trust.” Then add exceptions, based on well-founded assumptions.