10 Questions to Ask Any Vendor of Digital Rights Management/Security
Software for PDF
10 Questions to Ask Any Vendor of Digital Rights Management/Security
Software for PDF
1. Does the software provide Standard Security or DRM?
3. Are the secured files native PDF?
4. Does the vendor hold the Integration Key License Agreement
(IKLA) with Adobe Systems?
5. Does the software support multiple client platforms?
6. Will the secured PDFs display in Internet Explorer or
other Web browsers?
7. Does it work with past and future versions of Adobe Reader?
8. Does the vendor respect the principles of copyright and
privacy?
9. Is the software architected for Interoperability?
10. Has the product been proven in the marketplace?
PDF (109KB, 7pp)
"Standard
Security" refers to the basic level of password security offered by the
Adobe Acrobat product. Standard Security allows you to place an open/change
password on an individual PDF document and control basic access controls such
as whether or not a document can be printed. There are many third-party tools
available that allow you to place Standard Security on batches of PDFs via your
server. But the security provided by these tools is still the password-based
Standard Security, with all the limitations posed by that system, primarily
that passwords are easily transferred from authorized users to non-authorized
users.
DRM (Digital
Rights Management) in the context of PDF means the ability to control whether
or not the Adobe Reader will open or print a PDF depending on the permissions
granted to the end-user by the publisher. Adobe Systems has set forth a framework
for third parties to provide DRM tools for Adobe Reader via their "Security
Handler" plug-in architecture. Security Handler plug-ins are small files
that need to be installed only once (in the case of the FileOpen plug-in, with
no user interaction necessary), and from then on manage the opening, viewing,
and printing of PDFs encrypted with the DRM vendor's product. Because a Security
Handler plug-in effectively controls the actions of the Adobe Reader, Adobe
Systems does not let just anybody sell them (see Question no. 4).
So, the
two means to secure PDF files that will open in Adobe Reader are passwords and
Security Handler plug-ins. Any vendor who tells you that their product does
not use passwords or plug-ins is either displaying PDFs in a third-party viewer,
or controlling Adobe Reader from outside of the plug-in architecture ("plug-outs"),
which places their product outside of Adobe's sanctioned framework. While the
PDF file format itself is an open standard and anyone can write a third-party
viewer for it, Adobe Reader is a copyrighted, proprietary viewer controlled
by Adobe Systems. "Plug-outs," in addition to being inherently insecure
(see Question no. 3), may violate the Adobe Reader End-User License Agreement
and find their actions blocked by future versions of Adobe Reader. Indeed it
should be assumed that all such programs will be disabled at the level of the
operating system, as OS vendors implement code-signing to ensure the integrity
of applications and prevent hijacking by malicious programs.
No software can offer absolute security, only a greater or lesser degree of vulnerability. The old saying that "the only secure computer is one that is in a locked room and switched off" illustrates the challenge: the more secure the system, the less useful it must be.
So what is the right level of security for a DRM system? We believe that it's a combination of strong encryption, publisher-defined keys stored separately from documents, the transfer of those keys over a secure protocol, and a communicating client plug-in which can respond to changes in permission after the PDF has been delivered. Balanced with the need for broad compatibility with the diversity of Adobe Reader versions and operating system configurations, this approach has been successfully implemented in publishing applications as well as corporate implementations in which the security requirement is paramount.
The FileOpen
WebPublisher3 system, of which our Publisher3 product is a turnkey implementation,
is composed of an Encryptor module that produces security PDFs according to the Adobe
PDF specification, and a Client, which
is a Security Handler plug-in to the free Adobe Reader (as well as the paid
versions of Adobe Acrobat).
Encryption
Key Lengths and Compatibility
WebPublisher3
employs RC4 encryption as dictated by the PDF specification. Publishers have
a choice of encryption key length depending on which versions of Adobe Reader
they wish to support, 128-bit or 40-bit. 128-bit encryption was not supported
in Adobe Reader 4 or earlier, when 40-bit encryption was the maximum level exportable
under the law. Adobe has recently introduced support for 256 bit keys; however
use of these keys restricts backward compatibility still further, requiring
that the users have Adobe Reader 7. At present our customers have told us that
they prefer backward compatibility to longer key-lengths, but we may add support
for 256 and
Publisher-Defined
Keys and Secure Transmission
Importantly,
the actual keys used by FileOpen’s Encryptor are generated by the publisher,
i.e. the document owner. This is significant because it means that only that
publisher knows the decryption key, and neither FileOpen Systems nor a third
party has a “backdoor” way of opening files encrypted using our software.
The keys
to encrypted files are stored by, and known only to, the publisher’s PermissionServer,
which is also entirely under the control of the publisher. The client/server
communication for key transmission is typically routed over SSL, though http
can be used if the publisher prefers. If offline permission is granted, the
client stores keys in a local file encrypted using RC4 with a 128-bit key.
Communicating
Client
Once the
key has been delivered to the end-user's machine, the FileOpen Client plug-in
passes that key to Adobe Reader in order to permit display of the file. The
PDF remains under the control of the FileOpen plug-in running inside of Adobe
Reader, and can be set to be viewable only as long as a valid session is open
with the publisher's server. The Client plug-in is able to communicate with
the server to check permission status every time the end-user attempts to open
a PDF and view or print a particular page. These communications occur in the
background and no difference is apparent to the end-user in their experience
of using the PDF. In the event that a user encounters a limitation in their
permissions or a revocation of permissions, the Client plug-in will display
a message that is completely customizable by the Publisher and can be localized
in the language of their choice (for example, to invite the user to return to
the publisher web site to renew their subscription).
Of course, many publishers wish to grant some of their users offline access to a secured document, so that it may be viewed on an airplane, etc. Using WebPublisher, the publisher may grant offline permission to a document, with the option to set an expiration period on offline access after which the user must return to the publisher's site for renewed permission.
All vendors
of security software have a target on their backs from the hacker community.
Any vendor who claims that their product is "unbreakable" is hastening
the day that a hacker will prove them wrong. The best a vendor can do is to
follow the example of Adobe and Microsoft, in releasing patches quickly and
reducing vulnerabilities in future versions.
FileOpen
Systems makes available fully-functional evaluation versions of our products
available for publishers to put through rigorous testing before they license
the software.
Look carefully
at the filename extension of a document secured with a vendor's security software.
If it doesn't end in .pdf, the files are no longer native PDF
and will not open in Adobe Reader. They will require the end-user to download
and install either a third-party viewer or un-wrapper program in order to open
your secured PDF.
Why does
it matter if the secured documents require a proprietary viewer to display?
It depends on your goals for distributing your documents. If you are trying
to control your documents in a corporate setting, it means installing this new
viewer on every end-user machine, probably requiring administrator privileges
to do so. If you are trying to perform this installation over the Internet,
this will inevitably result in frustrated calls to your tech support line. Otherwise
you will have to ask your end-user to get their IT department to physically
install the viewer on their machine. On the other hand, you'd be hard pressed
to find a computer in any corporate environment that does not have the Adobe
Reader pre-installed, or a corporate employee who is not familiar with opening
normal PDFs.
If you're in the publishing business, it's hard to imagine why you would eschew the installed base of millions (billions?) of Adobe Readers around the world. Adobe System has put over ten years and untold dollars into establishing PDF as a standard and Reader as its default viewer. It's free, it's trusted, and everyone has it already.
The intermediate
approach of creating an application that wraps around the Adobe viewer, adding
security from the outside, has been tried by several third-party vendors over
the years. This approach suffers from severe limitations.
First, while
it is possible to re-encrypt a PDF file with some cipher and/or key length that
is stronger than the ones chosen by Adobe, this provides an advantage only while
the file is in transit or being stored. Once the file is opened In Acrobat,
it is necessarily subject to all the risks of a PDF file in Adobe Acrobat.
Some vendors have attempted to enhance the security of the Adobe applications by running an external program ("plug-out"); to protect Acrobat, as it were, from its own limitations. Besides being extremely questionable from a legal and ethical standpoint and burdensome to end-users, this approach has been demonstrated to be insecure.
The method
depends upon the parasite (the plug-out) not being detached from the host (Adobe
Reader). Such systems work by having the external program decrypt the outer
layer of the file and passing the resulting PDF (now protected only with Standard
Security or no security whatsoever) to Adobe Reader for display. The problem
is that the external program must now oversee the Reader to prevent malfeasance
and also must also prevent itself from being closed and the Reader left running,
as this would leave the PDF file exposed in the now-unprotected Adobe Reader.
It should
also be apparent that no application vendor would condone this approach, which
amounts to ceding control over that vendor's own program and user interface
to an untrusted third party. As noted above, this technique closely resembles
ones employed by the writers of trojans and cracking software, so can be expected
to be outlawed by future operating systems.
The wrapper
approach also degrades the seamlessness of the user experience, by adding another
layer of software during the opening and usage of files. This typically
disables some of the more attractive features of the PDF experience - for example:
browser integration, Fast Web View and fill-in forms.
Any vendor
of a DRM/Security plug-in for Adobe Reader must hold an Integration Key License
Agreement (IKLA) with Adobe Systems. This agreement sets forth strict guidelines
for which actions a security plug-in to Adobe Reader can and cannot perform.
The prohibitions include:
The IKLA
carries with it a substantial annual fee which signifies the commitment on the
part of the vendor to the Adobe Reader platform.
As mentioned
above, any vendor of a PDF DRM product who does not hold the IKLA either has
their own PDF viewer, or is controlling the Adobe Reader from the outside as
a "plug-out." Such vendors have not agreed to the restrictions of
the IKLA listed above, which set the standard for the actions of DRM client
software for PDF.
Cross-platform
operability is PDF's very reason for existence. But if a Security Handler's
client plug-in only works on Windows, only end-users on Windows will be able
to open the PDF, regardless of whether or not they have permission. This problem
is particularly important to the publishing market, for whom Macintosh and Linux
users make up a significant portion of end-users.
One of the
most appealing features of PDF is Adobe's integration of the viewer with other
applications, principally web browsers. PDF files delivered over the internet
will open in the main window of most common browsers, and by now most end users
are familiar with this experience.
DRM systems
that re-encode PDF files typically break this interaction, forcing files to
be opened outside the browser. And even when they permit opening in the browser
they cannot support the rapid-download feature, known as "Fast Web View,"
which makes large PDF files appear to load instantaneously.
Acrobat and Reader also work in other environments, e.g. with e-mail, from CD-ROM or within Groupware programs, and any DRM system that doesn't operate within the Adobe applications is unlikely to work seamlessly in all these places.
Lack of backward compatibility is a drawback of many security and DRM offerings, and there is an inverse correlation between backward compatibility and encryption key length. To the consternation of Adobe partners everywhere, old versions of Adobe Reader occupy the majority of end-user desktops and persist even in corporate environments. Security vendors must take advantage of the security improvements of each new release of Adobe Reader, while continuing to work in older versions, all in the same client plug-in. As the publisher, you may have to make a compromise between the level of security you desire and how far back you wish to go in Reader compatibility. For example, 128-bit encryption was not supported in Adobe Reader 4 or earlier. FileOpen WebPublisher and Publisher products give you a choice between 128-bit (requiring Reader 5 or later) and 40-bit encryption (supporting Reader 4 or earlier).
Whether or not a DRM vendor's client software will function in future versions of Adobe Reader should be of great concern to publishers. Neither security vendors or publishers have any control over whether or when an end-user will upgrade their version of Adobe Reader. An end-user will continue to attempt to open the secure PDFs you have delivered to them after they upgrade their Acrobat Reader. Forward compatibility depends on a number of factors--are the PDFs produced by the DRM software native PDF according to the PDF specification? Does the DRM software conform to Adobe's IKLA? Does the vendor have a positive relationship with Adobe Systems such that future versions of Adobe Reader will not explicitly block the actions of their client software?
DRM is about
protecting the intellectual property of publishers, corporations, and individuals.
As the owner of your content, you should choose your DRM vendor carefully--after
all, their product will literally have a "lock" on your content in
the marketplace. Vendors of DRM products should "walk the walk" of
copyright protection in their business practices. Do they respect the rules
set forth by Adobe Systems governing how DRM tools should interact with Adobe
Reader? Or do they ally themselves with the hackers who seek to undermine PDF
security?
Security
and DRM software vendors must also be good citizens on the desktop of the end-user.
This means respecting the privacy of the end-user (not relaying information
to the publisher or themselves about anything other than their use of the secured
file), and not seizing control of important processes of the operating system
in the name of better security.
DRM is only
one part of a publishing or document management system--in order to create a
viable solution, the DRM subsystem must be integrated with databases, web servers,
browsers, other desktop software, etc. The FileOpen offering is designed to
be as open and interoperable as it is possible to be while still providing DRM
functionality.
The interoperability
of FileOpen WebPublisher enables publishers to use it as an additional layer
of security on top of existing firewalls, extending the same business logic
in use on their Web servers to their PDF documents out in the field with minimal
programming. WebPublisher is also designed to interface seamlessly with any
e-commerce system, playing the critical role of making sure that only users
who have paid for documents can open, view, or print them.
To succeed
on the Web, or in the corporate environment, software must be designed from
the ground-up for interoperability. We know that Acrobat itself is a "good
citizen" in the Web ecosystem, and that PDF has become one of the foundation
technologies of online publishing because it embodies the perfect mix of openness
and managed development. And while it may seem contradictory to speak of openness
and DRM in the same sentence, the same guiding principles that apply to Acrobat
and other web applications must also apply to DRM systems--a software package
designed to operate as a closed system will always present unacceptable choices
to integrators and developers.
As a publisher,
the last thing you want is to have your legitimate end-users unable to open
your secured documents. Any DRM tool has to place software on the end-user's
machine, whether it's a plug-in, wrapper, or proprietary viewer. And any DRM
vendor who has been around for more than a year or so will tell you from experience
that it takes time and testing and constant fixing to develop client software
that will work smoothly on the majority of end-user desktops. There's no substitute
for years of experience in the real world of PDF users--not millions in venture
capital, or the strongest encryption in the world.
FileOpen
Systems has been developing DRM software for PDF since 1997, and the FileOpen
WebPublisher plug-in has been distributed to millions of desktops around the
world since its release in 2002. Our customers benefit from the peace of mind
of knowing that our software has withstood the test of time, and that as a licensed
Adobe Security Partner, will continue to innovate and meet the challenges of
the future.
Copyright
2005, FileOpen Systems Inc.