PDF security - a brief history of development

PDF security - a brief history of development Background Adobe was the first organization that set out to try and provide security controls for PDF based documents, and had their own particular views as to what users might (or might not) want in order to control the access to and use of information in PDF format. Information security (in the sense of access controls, and continuing use controls) was not provided in earliest versions of PDF documents, simply because the most important feature of Adobe PDF was to ensure that what was shown on-screen or on a printed copy was the same, regardless of operating system, or printing device, being used. PDF Password access controls When Adobe first introduced PDF access control security, the controls the publisher selected were enforced by using passwords. Passwords were the commonest access control mechanism in use at the time, because, in fact, there was nothing else that was viable. But the way it was implemented was not a good idea, because it left it up to human beings to 'decide' what the passwords should be - and they inevitably chose passwords that were short and easy to cope with (and therefore easy for password crackers to attack) as against long, complex, and difficult to type in, because it was more important not to annoy your recipient than to worry about if what you were doing was realistically secure. Unfortunately, using passwords as controls also allowed any recipient of a password protected document to pass it, and the associated password(s) to anyone they chose, and nobody was any the wiser. No mechanisms were created that could check that the person using the password was authorized to do that. But even when the use of passwords was strengthened by implementing cryptography to prevent trivial access to the underlying document by simply decoding the PDF formatting, some fundamental weaknesses inherent in the use of passwords remained. PDF 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 Writer/Viewer combination you happen to be using, but 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, and so your own requirements may not be exactly mirrored by the different Adobe products 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)
© LockLizard Ltd 2008 PDF security - a brief history of development Page 1 of 7 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 tho... [download for more]