PDF Digital Signatures & Encryption

Are Digital Signatures & Block Encryption Secure?

Discover why digitally signing a PDF does not ensure document integrity (digitally signed content can be altered) and why using block encryption makes a PDF less secure.

PDF Digital Signatures, Encryption & Security

A signed and encrypted PDF may not be what you think.

We mainly know what we are physically signing using pen and ink, but when it comes to applying Digital Signatures to PDF documents it appears that we can be fooled into seeing one thing and signing another. At the time of writing there were several excellent papers published on these web sites:

that analyze methods for avoiding or bypassing PDF Digital Signatures or using them in a manner that allows an attacker to access or add information when an unsuspecting user opens a PDF document. They also cover the security issue of just encrypting parts of a PDF document and how this can compromise document security.

It is fair to note that some of the problems are created as a result of the immense flexibility of the PDF standard and some are as a result of our old friends: poor programming, failing to process errors, and ignoring badly formed structures such as headers or edit history.

The published texts are rather technically inclined but they make a number of highly valid points which we have summarized below.

Digitally signed PDF files – not as secure as you might think

The first point is that objects that are being or have been signed may contain references to elsewhere in the PDF document or to somewhere outside the document where the content has not been digitally signed, or involves edited material that can be made active using an OpenAction that effectively passes control of the document to an attacker, bypassing the effect of document encryption or of what is actually being signed. This is particularly concerning because an important feature of the PDF document structure is the ability to call other documents that are not local and use them as part of the initial document. We are doing something very similar in this document where we are referencing links to internet documents that have not themselves been verified (this is also the basis of hackers being able to fake real sites while connecting to false web sites and to other redirection actions). Fortunately, here we are not setting out to prove the point – just pointing it out.

Encrypting parts of a PDF document – a security weakness

The second point is that objects may be encrypted and held in blocks, with each block covering specific text. This is known as partial encryption. Because the code is not fully protected it is possible to add unencrypted information that is not detected because it is in a valid code structure itself. And it can be used to introduce code that has not been verified or protected, meaning that a signature validation may not protect what is seen by the user. This is not a good thing. Also, it is possible in some systems to define the encryption algorithm as “none” and still get a valid result because no error gets thrown out to warn the document user.

PDF Viewers, application security and error checking

The third point lies with error checking. PDF documents have header and trailer blocks which contain control information used for validating the consistency and integrity of the PDF document. Unfortunately, in the earlier days of making non-Adobe products interoperable with each other and Adobe it was found easier to ignore errors in the headers and trailers because you could still process the PDF encodings alright.

Today Adobe advise that conditions on your computer such as security settings or browser cookies may prevent you from viewing a PDF. They suggest that you have a go with another browser that might be more helpful. Some of the problems identified in the studies could have been avoided if systems were less accommodating (fault tolerant without understanding fully the implications of tolerating faults, or warning the user to let them make a choice). This is the same as when some browsers warn you of unsigned web sites that you should not access. You get to make an informed choice.

PDF Security and standards

Programmers working with PDF (or for that matter HTML or XML) are not normally hired because of their security expertise and knowledge of the greater arcana (better known as Public Key Infrastructure standards) or the more popular OpenPGP standards that keep industry going today even if they seem out of favor with the standardizers. And that is a part of the problem. These encryption technologies are having to be interfaced to many quite different technologies, from static file transfer to streaming digital video. And there is little assistance available to help developers choose the most appropriate implementation to help solve or avoid specific problems.

Some commentators recommend standards developed by ETSI (European Telecommunications Standards Institute) forgetting that ETSI is the EU standardizer and ISO/IEC JTC1/SC27 is the International Standards Organization body for encryption standards. So, while there is a lack of clarity as to who is responsible for guidance among the experts, then what hope have the rest of us?

PDF DRM: what does Locklizard bring to the table?

Locklizard is not a standards body, however much it might sound attractive for marketing purposes. Nor is it in the business of telling its publishers how they should follow this or that standard.

Rather than adding security to a PDF file that can then be opened within Adobe Acrobat and other PDF compatible Readers (and exposing it to an environment which has proven weaknesses), we protect PDF files into a proprietary format (PDC) that can only be viewed using our own secure PDF viewers. This ensures that protected PDF content is opened in a known and secure environment that does not support functionality that could compromise document security (such as allowing plugins, save as functionality, JavaScript, etc.).

The Locklizard approach is to preserve the integrity of the PDF document that the publisher hands over to be protected. We make no comment on what a publisher wants to distribute and how it is intended by them to perform. We do not try to tell them whether this approach or that internal technical structure or approach would be more or less secure – whatever that might mean. What we do set out to do is prevent any change to the document that was protected when it is distributed by a publisher to their users. If a protected document is altered in any way then it will fail to load in the secure Viewer so document integrity is always guaranteed. So internal and external references are just as the publisher intended.

What we set out to do is prevent an attacker from being able to alter the document without being detected and then mislead subsequent users as to the authenticity of what they are seeing/signing. And this is achieved by encrypting the whole document with integrity controls. So the attacker is forced to try to break the encryption of the file itself without being able to use normal PDF tools (such as PDF password recovery tools) to break in. This is not the same problem as scanning a print-out of the file to PDF as the coding is not revealed in that process so the decrypted document must be written again from scratch and then re-encrypted using the Locklizard proprietary PDF encrypted format before it can be re-distributed as an ‘authentic’ copy.

HTML5 and PDF Web based Viewers

Many PDF DRM Viewers have gone down the browser route, enabling protected PDF documents to be viewed in a browser. Content protected in this manner can only be displayed using a proprietary system where a user logs into a dashboard and can then view protected PDFs in their browser. So is this method more secure than a plugin to Adobe Acrobat to control PDF use and ensure document integrity?

The problem with browser-based environments is that there is no software installed on the client to provide additional security (i.e. a dedicated viewer app). So that means manufacturers must rely on other means of protection such as JavaScript to control document use. The JavaScript however has to be loaded into the browser for it to execute and there lies the issue – anything in a browser can be manipulated. In fact, all browsers offer a development mode to enable you to do just that. So, if you are thinking of relying on a browser-based PDF security system for document protection and integrity then you might want to think again. Those ‘secure’ deal room systems are not quite as secure as they would like you to believe.

The future of PDF Security

It has been well known for a long time that the PDF standard was produced for interoperability purposes (the ability to consistently display content over a wide range of operating systems and devices) and not for security. And as features have been bolted on to allow security controls to be applied, little thought has gone into how easily they could be bypassed. The PDF format would therefore have to be significantly overhauled from the ground up with security at its base, or Publishers of PDF documents will have to continue to rely on third party PDF security systems that provide secure viewer environments to preserve document integrity and control PDF access and use.