Adobe Acrobat PDF Security & PDF Security Development

Adobe Acrobat Security and backwards compatibility

The first thing to be aware of is that the security applied to a PDF document is not simply a function of which version of the Adobe Acrobat Writer/Reader combination you happen to be using. For backwards compatibility reasons, the features that were implemented in earlier versions have been carried forward to the very latest releases so as not to upset a large client base. As a result, your own requirements may not be exactly mirrored by the different Adobe products such as Acrobat Reader/Writer software still in use.

For instance, if you go back to the security provisions of Adobe 5 (still highly popular, much implemented – especially by hackers because it had very weak controls as compared with Adobe 7 and later – but still able to process much of the files that Adobe 6,7, and 8 produced) you had two passwords, one (optional) to be able to open the document, and the other (optional) to allow you to change the permissions (or limitations) that were applied to a document, and the presence of passwords.

The permissions that you could authorize, and therefore control, in Adobe 5 were:

• changing the document content
• content copying or extraction
• authoring comments and form fields
• form fields fill-in or signing
• content accessibility (using screen readers)
• document assembly
• encryption level
• printing (forbidden, low quality, high quality).

That was with the ‘high’ 128 bit encryption algorithm.  Things were a little simpler if you used a weaker algorithm simply because you had fewer controls.  But we are going to ignore this possibility.

The first thing to notice about the controls on offer is that they are unusual if you are trying to prevent uncontrolled circulation of a PDF formatted document.  There is no concept of licensing, start and stop dates, control of numbers of views and prints, or identifying the licensed user.

Controlling the use of forms seems rather curious, if the purpose of a form is to have it filled in, and separating document assembly from content copying/extraction (where you could presumably do the same thing) does not seem immediately logical.

It is difficult, therefore, to reconcile the controls that were provided with what typical IPR owners normally want to control, when they provide their information to other people, especially when those people are not on their internal computer network and cannot be managed by controls other than those pertaining specifically to the document.

What controls do information sellers expect to have available?

Study has shown that the controls that publishers and corporate bodies actually want are much closer to the Digital Rights Management (DRM) controls that the music and film industries have been trying to implement, that would allow them to:

• prevent simple copying and redistribution of PDF documents
• prevent simple Print Screen and screen capture programs
• stop access to documents outside of a licensed period
• limit the number of times a document can be viewed/printed (pay per view)
• if prints are made, be able to find who is distributing them by dynamically adding watermarks to screen images and printed pages
• cease access to sensitive material as and when necessary, with confidence that the access will be ceased effectively.

These controls did not really align with the Adobe developed PDF controls, and, as a result, other PDF security providers began to emerge (see later).  However, Adobe continued to control this space as the dominant supplier, even if they were not providing the DRM controls that publishers would have expected.

Later Adobe Acrobat security developments

By Adobe 7 things were different, in that Adobe had provided some slightly different options that provided the following controls:

• inserting, deleting and rotating pages
• filling in form fields and signing existing signature fields
• commenting, filling in form fields and signing existing signature fields
• any except extracting pages
• enabling copying of text, images and other content
• printing (forbidden, low quality, high quality).

But these were also still being reconciled back into the permissions that Adobe 5 had provided because of the need for backwards compatibility.

The biggest change, apart from the update to the 128 bit AES algorithm (which made little practical difference because the biggest weakness of their implementation was actually an attack against the passwords protecting documents rather than an attack against the cryptography, which is far more difficult), was the addition of something called ‘Encrypt for certain identities using digital certificates’.

It is necessary to discuss the concepts and realities of ‘digital certificates’ in order to understand what they are, and why they turned out to be useless as a PDF control mechanism.

Digital certificates and the great PKI fiasco

In the late 1990’s and early 2000’s the IT security industry developed a concept usually referred to as Public Key Infrastructure (PKI). The idea was that private companies would sell people ‘digital identities’ or ‘digital certificates’ that would uniquely identify them on the Internet and could make them personally liable for their activities (purchasing goods, paying bills, making government returns and so on).

The vast majority of normal people had never heard of such things as ‘digital certificates’, and most certainly did not have them.  And given the (lack of) security about the Internet, there was actually every possible reason for people to make sure that they could not be claimed to be accountable, especially when they had no idea of how to protect themselves from things like identity theft.

It might seem strange to some, but consumers actually figured out that it is not a good plan to pay actual money to people in order to become personally liable for making payments, obtaining web site access, or anything else, when they can use credit cards which they can get for free and for which have little if any personal liability at all if anything goes wrong.

So as a result of this no-brainer the PKI industry imploded. People did not buy ‘digital certificates’ and so the IT industry could not use them as a means of applying controls.

Unfortunately Adobe had invested in the next range of PDF security by building upon the concept of ‘digital certificates’ and equally unfortunately that didn’t happen, and so neither did the controls that were expected to be able to limit the use of controlled documents to defined people.

Lifecycle management

Another big concept being invested in at the same time was ‘lifecycle management’. This concept came from the document management industries, who were interested in controlling the way in which documents were created, authorised, circulated and finally killed off.

Document management companies were very focused upon what happens inside of an enterprise, and how to control that, but had little or no focus upon what happened once documents went outside of enterprise control.

So whilst the Adobe type controls played well into internal document management, in the longer term they were less focused upon PDF controls in the broader market.

By now Adobe had published their document structures as standards through the Internet Engineering Task Force (IETF) and so any number of companies (including Microsoft) could readily convert their document formats to PDF at any stage. The practical effect of this was to separate the need for internal controls from the need to have external controls.

For Adobe this meant that although their publishing format provided a consistency across platforms and printers, it was less important to have internal controls for the PDF format because internal controls could be readily applied over other formats before converting to PDF for transmission to the final recipient. And, as has already been observed, Adobe based PDF controls were not aligned to market expectations.

Third party systems for protecting and revealing PDF information

Following the Adobe developments, a number of third party suppliers developed into this space. There were three broad groupings:

1. those continuing to support the Adobe controls but providing their own answer to replace the Adobe password access controls;
2. those providing DRM class controls, either inside the Adobe viewer or outside it;
3. those providing systems to break the Adobe controls by either revealing the control passwords or by providing plug-in components to the viewer that bypassed the Adobe security rules.

There are a large number of companies who have created a number of alternative approaches to hiding passwords from becoming visible (and therefore being able to make them longer and more resistant to password crackers). These can be supplemented by an Administration or permissions server which can register the use of a secret password and prevent its re-use.

However, all suppliers using these type of Adobe replacement access controls are likely to be exposed to the same weaknesses as Adobe itself (see later).

Suppliers providing their own DRM class controls are basically in two groups, those providing additional security whilst operating as a plug-in to the Adobe solution, and those who provide separately enforced controls.

Here there is a basic security trade between being able to guarantee to be 100% compatibility with any Adobe release (and the requirements for each release may differ and cause plug-in implementation problems) and being exposed to security weaknesses in Adobe implementations.

Those suppliers working as plug-ins are exposed to Adobe weaknesses and cannot remedy them, so all the attacks listed below may potentially be used against them.

Suppliers providing their own controls cannot be attacked through the Adobe weaknesses, and can be much more innovative about the granularity of DRM they can support than following the Adobe led model.

Additional controls such as dynamic revocation of access rights, the ability to control start and end dates for time limited material, the ability to allow identical access to groups of documents, are just a small number of examples of how PDF controls have been broadened in the developing market.

At the same time it is important to note that some companies have developed products that allow access to be regained to Adobe protected PDF documents.

Probably the most important of these was revealed through a ‘classical’ attack on the Adobe security mechanism carried out by the Russian company Elcomsoft.  They attacked the mechanism that secured the passwords (granting uncontrolled access to PDF), allowing them to be revealed (their program was sold on the basis that it allowed document owners to recover passwords that they had forgotten, and that was obviously perfectly obvious and reasonable).  The product was so good that the President of Elcomsoft was persuaded to visit the USA, and then arrested for prosecution under the Digital Millennium Copyright Act, which forbids anyone from investigating or circumventing security mechanisms! However, in the end he was not prosecuted.

The second was actually far more serious indeed. Adobe published statements to the effect that their controls, and those provided by their third party suppliers (using plug-ins), had been implemented on an ‘honour system’ – that they required that everyone who produced plug-ins to their product to obey the conventions of their security mechanisms, and not to defeat them.

Unfortunately, since piracy seems to be rampant, any reasonable analysis suggests that the ‘honour system’ cannot to be relied upon.  And that is a fundamental flaw when it comes to security mechanisms.  If you are going to have security, then you simply can’ t rely on human beings to implement it.  Passwords are weak because they can always be passed on, and all too often are chose by humans, and so can be ‘guessed’ by password crackers even if a mechanism as subtle as the password revealer of Elcomsoft is not available.

And where there is an honour system you will also find people who are without honour.

Adobe Acrobat security & PDF security going forwards

In 2006 Adobe announced that they would be ceasing their own DRM type security offerings and also announced a new document format, based upon the Macromedia flash technology, following the bringing together of the two businesses.

However, the general publishing market (public and private) market is still very heavily reliant upon the PDF format for document publishing, and in many cases, not ready to use the flash technology because it is yet to be well established as a medium that can be relied upon to give the form and format that the publisher requires – not everyone wants their material presenting in the form of an eBook where it looks like a novel and the pages turn like a paperback. Magazines are presented in a different way from Witness statements to a Court, or to corporate press releases.

The PDF format is very well established, and it will be many years before it shows signs of waning, but the protection of PDF seems to have moved away from Adobe and into the newer companies providing their own controls.