EPUB Lightweight Content Protection: Request for Proposals


Prepared for IDPF by Bill Rosenblatt, GiantSteps Media Technology Strategies
Publication Date: July 20, 2012


The International Digital Publishing Forum (“IDPF”) is the global trade and standards organization dedicated to the development and promotion of electronic publishing and content consumption. The IDPF develops and maintains the EPUB® content publication standard that enables the creation and transport of reflowable digital books and other types of content as digital publications that are interoperable between disparate EPUB-compliant reading devices and applications.

The IDPF contemplates development of standard standardized interoperable content protection technology for EPUB, called EPUB Lightweight Content Protection (“EPUB LCP").  This Request for Proposals (“RFP”) solicits organizations to propose concrete solutions that meet or exceed the requirements detailed herein. Interested parties are invited to review the document and provide an initial response to IDPF by August 31, 2012 (per “Proposal Requirements” and “Schedule” below).

Note that this RFP does not imply any commitment from IDPF to proceed with this activity. A primary goal of this RFP is to gain more information so that IDPF management and its Board can better assess factors such as development cost and likely adoption.


EPUB’s success as a standard format for digital publications may be held back by a combination of publishers’ requirements for content protection technology and the lack of an interoperable standard for it.  Indeed, there are more than half a dozen DRM technologies in active use in the e-publishing market today, including several that work with the EPUB format.  .  

A number of crucial points weigh in favor of standardizing an interoperable “lightweight” DRM for EPUB now:

1.     A standard method of protecting eBook content that becomes broadly adopted would materially increase interoperability, ameliorate some of the ease-of-use limitations in current DRMs, and may promote broader adoption of digital reading, while continuing to address content rights holders’ concerns about content security.

2.     A DRM scheme that is designed with the objectives of easy adoption across multiple platforms as well as low cost of integration and operation is more likely to be adopted by a wide range of retailers and e-reader makers.

3.     As explained below, it is possible to define a DRM that eases usage restrictions beyond interoperability, such as allowing a reasonable level of sharing.

4.     DRM is more widely agreed to be useful in non-retail business models, such as library e-lending; it would be useful to have a standard DRM to use in these scenarios for reasons stated in #1 above.

5.     A lightweight encryption similar to PDF’s (which is not necessarily considered “DRM”) would promote content authors’ ability to protect EPUB content against unauthorized uses, easing the transition from PDF to EPUB in some ad hoc / enterprise document distribution scenarios.

What Is “Lightweight Content Protection”?

Three inter-related criteria combine to form our definition of “lightweight”:

1.     Implementation costs: lightweight DRMs are low in implementation cost.  Factors that contribute to implementation cost include:

a.      Client footprint: memory, processor power, hardware “trust anchors.”

b.     Complexity of client-server interactions (“phoning home”).

c.      Cost and complexity of integrating server software (and/or cloud services) with content distributors’ infrastructures.

d.     Cost and complexity of administrative facilities such as root-of-trust and device registration, if required.

e.      Level of tech support required.

f.       Technology licensing.

2.     User Experience: lightweight DRMs are simpler to use and cause less end-user confusion.  The FairPlay DRM for Apple iTunes (while not “lightweight” in the specific sense of this RFP)  is often cited as a good example of a DRM with a decent user experience.  Elements of good user experience include:

a.      Does not get in the way of users’ expected interactions with the content.

b.     Works seamlessly in the absence of a network connection – including permanent absence if the distributor ceases operations.

3.     Intrusion: Lightweight DRMs should be minimally intrusive to users.  Intrusiveness generally falls into one or more of these categories:

a.      Imposes excessive restrictions on user behavior, such as prohibiting uses that could well be permissible under copyright law. 

b.     Impinges on users’ privacy, e.g. through excessive “phoning home” without an opt-out provision or even proper notification.  An egregious example of this was SunnComm’s copy protection for audio CDs, which phoned home even when the user opted out.

c.      Jeopardizes the security or integrity of the user’s device.  An example of this was First4Internet’s CDMax copy protection technology for audio CDs, which was known to make changes in users’ PCs that rendered them susceptible to viruses.

We recognize that in defining a “lightweight” DRM, we may be compromising support for certain business models and security features found in modern DRMs, such as:

1.     Security enhancements: technologies that strengthen the DRM’s security, crack resistance, and crack recoverability:

a.      Execution monitoring: the ability to monitor behavior on the client device or app for suspicious activity, such as the presence of cracker-installed code that steals keys or the use of debugging tools to reverse-engineer client functionality.

b.     Revocation and recoverability: the ability to recover from or limit the impact of cracks once they are detected.  This includes capabilities such as key revocation and field-upgradable protection.  With key revocation, the server will publish a list of revoked keys to all clients on a periodic basis.  Clients must check keys against these lists before letting them be used.  Field-upgradable protection is an example of recoverability; it is the ability to change the DRM client code on the fly from the server, perhaps by changing variables in a code diversity scheme so that it works differently and a crack no longer applies.

2.     Business model enablers: technologies that enable content business models which are not possible with lightweight DRM (by itself).  Examples include:

a.      Domain authentication: Allowing a single user account to apply to multiple devices.  Technologies that allow this include Adobe Content Server and UltraViolet.  This requires complex technology, including maintaining databases of user-device relationships, enforcing limits on number of devices per user account, and requiring a server to communicate with devices continuously.

b.     License chaining: enabling licenses to be grouped together for purposes such as subscription models.

c.      Master-slave schemes: downloading protected content onto one device (the “master”) and transferring it to other devices (“slaves”). This is one way to achieve interoperability, particularly with devices that do not have network connections.  Microsoft’s Windows Media DRM 10/11 (a/k/a PlaysForSure) is an example of this.

d.     Forward-and-delete: enabling “First Sale” a/k/a “Exhaustion” rights such as the right to lend, sell, or give to another user, after/during which the first user does not have access to the content.  A limited version of this feature is present in Barnes & Noble’s publication DRM, which allows a 14-day lending period for some titles.  The IEEE P1817 standard (Consumer Ownable Digital Personal Property) specifies a key management system that implements forward-and-delete.

We should note that technologies proposed for EPUB LCP should not necessarily exclude the above capabilities and technologies; EPUB LCP is preferably designed so that these capabilities can be added in specific implementations where appropriate. For example, there may well be an enhancement of EPUB LCP with stronger security for use in Higher Ed publishing, one that supports license chaining for subscription download services in professional or STM publishing, or one that supports domain authentication for UltraViolet-style “family accounts.”  Respondents should feel free to propose technologies that include the above features but be able to demonstrate how they can be left out and/or that they do not compromise ease and low cost of implementation and operation, as explained below.

We should also note that EPUB LCP is intended to be complementary to “watermarking,” i.e., the insertion of data such as users’ names, email addresses, etc., into EPUB files before they are encrypted.  In fact, as mentioned below, we intend to provide a mechanism whereby the EPUB LCP encryption key can be used as a watermark payload if desired.


EPUB LCP Requirements

Here are requirements for minimal EPUB LCP functionality.  These are expressed in terms that should be familiar to DRM technology vendors:

1.     Authentication:

a.      Authentication is based on files, as opposed to user or device authentication, although the technology should be open to adding other modes of authentication (see below). 

b.     Each file has a password associated with it (stored in the file itself or separately).  The password is set at the time the user acquires the publication.  It is normally necessary for the user to enter the password the first time he opens a file on a device, but not thereafter except if otherwise configured (see Use Cases above). 

c.      To read the publication on another device, the user must simply enter the password once on the other device (though see below for exceptions).  To share the publication with another user (on another device), the password must be communicated to the other user; otherwise sharing with another user is exactly the same as the same user reading the publication on another device; see the Use Cases below.

d.     Names of password field(s) must be included in each publication as metadata (e.g. “User ID,” “Password,” “Kennwort,” “암호,” “Library card number,” etc.)

e.      Password semantics are not defined EPUB LCP but should be configurable by the distributor as appropriate, for example:

i.     User settable on a per-file basis

ii.     User settable, single password for all files

iii.     User settable with minimum password strength requirements (e.g. at least N characters, one or more non-letters or non-alphanumerics, etc.)

iv.     Re-entry required for every file open (or not)

v.     Distributor settable (e.g. to user’s email address, user ID, or credit card number)

f.       Passwords must be stored in obfuscated and unrecoverable form, such as via a one-way hash function.  In other words, any password-stealing hacks must be forced to grab the password between when the user types it in and when it is obfuscated.

2.     Configurable limitations on usage:

a.      Printing, expressed in amount of text that can be printed at a time and/or total content per title.

b.     Copy to clipboard, expressed in amount of text that can be copied at a time and/or total content per title.

c.      Editing (on/off).

d.     Configurable usage start and end dates (e.g. for library lending), with time granularity down to the minute or smaller (to accommodate research libraries with lending periods measured in hours).

e.      Optional separate passwords for some of the above operations, such as edit password or copy/print password.

f.       Other functions that do not relate to the content per se, such as annotations and bookmarking, need not have limitations on usage.

3.     Content protection:

a.      The algorithm used for content encryption must be AES, at least 128-bit strength, operational mode up to the implementer; alternatively, an algorithm of at least the equivalent in both strength and code library availability would be acceptable. Symmetric keys can either be the obfuscated passwords (as described above) or be derived from them.

b.     At least one level of encryption is required: symmetric keys for encrypting content. Additional means may need to be specified to support all use cases, such as asymmetric keys for protecting content keys in transit and on clients.

c.      The algorithm used for content key protection must be a standard public/private key algorithm that is efficient and inexpensive to implement, such as RSA-1024 or ECC-NIST-256

d.     Key hiding methods are left up to the implementer.  See below on cost-robustness tradeoffs.

e.      Key revocation and code renewability are not supported as they require phoning home (see above).

f.       If the file is to be encrypted in a secure server facility, then the solution should provide an interface (such as an API call) that makes the obfuscated password available without (or before) actually encrypting the content.  The intended use case for this is a watermarking utility that embeds the obfuscated password into the content as a watermark payload before the content is encrypted.

4.     Client-server interactions:

a.      Clients can interact with servers at content fulfillment times.

b.     The solution may require one-time client (device or app) registration if it does not compromise ease of interoperability, operational cost, or complexity of content distributor integration. 

c.      Otherwise, the solution should be operable without additional phoning home.

5.     Format support:

a.      The expectation is that EPUB LCP will build on the EPUB Open Container Format (OCF) definition of encryption.xml, rights.xml, etc. it is not anticipated that EPUB LCP will be directly applicable to formats other than EPUB.

6.     Code library:

a.      Client

i.     Maximally portable

ii.     Well-documented client APIs for integration into e-reader apps and devices

iii.     Callable through a wide variety of programming languages

iv.     Reference implementation on a popular platform of the implementer’s choice (e.g. Android, iOS, Windows, Mac OS).

b.     Server

i.     RESTful web service interface

ii.     Reference implementation on Windows or Linux and/or cloud service offering

7.     Cost elements: we expect to address specifics of financials, licensing, and related issues later in this process. For now, we ask that proposers keep the following criteria in mind:

a.      Integration with distributors’ server infrastructures should be as easy and inexpensive as possible.  Proposers should identify resources (whether theirs or third parties) that can assist in performing integration work.

b.     Root-of-trust facilities should be as simple and inexpensive to operate as possible.

c.      Implementation on a wide variety of client platforms should be as easy and inexpensive as possible.  Client hardware requirements should be kept to a bare minimum.

d.     We recognize that there are tradeoffs between the robustness of the solution and its costs, both for client implementations and regarding root-of-trust facilities.  Proposers should address this tradeoff in their responses and explain how their solution provides an adequate level of robustness at minimal cost to e-reader makers and content distributors.

e.      Technology licensing costs should be minimal, preferably zero.  This includes all associated IP licensing. 

f.       Proposers should also address issues of IP overhang and how their solution minimizes associated risks.

Use Cases

Here are the most basic use cases for EPUB LCP, which should make some of its design goals clear.

1.     Purchase

a.      Initial download and read on Device D1 (“Fulfillment”)

i.     Download File F1 onto Device D1

ii.     Set password P1 for File F1 (user sets it or commerce software pre-assigns it)[1]

iii.     Read file on Device D1 using Reading System

b.     Subsequent read on Device D1

i.     Just open File F1 in Reading System 

ii.     This can be configured to require re-entry of the password or not.

c.      Transfer the file to Device D2 (using any method: email, USB drive, cyberlocker, etc.)

i.     Open file on Device D2 with Password P1

ii.     Read file on Device D2 using Reading System

d.     Subsequent read on Device D2

i.     Open the file in Reading System

ii.     This can be configured to require re-entry of the password or not.

e.      Share with a Friend

i.     Send file to User U2 (using any method)

ii.     User U2 loads file onto Device D3

iii.     Send Password P1 to User U2 (using any method – IM, email, text, etc.)

iv.     User U2 opens File F1 with P1 on D3 using Reading System

2.     Library Lend

a.      Download and read on Device D1

i.     Download the file onto Device D1

ii.     Password P1 for File F1 is pre-assigned by library (e.g. library card number)

iii.     Read file on Device D1 using Reading System

b.     Subsequent read on Device D1

i.     Open the file in Reading System

c.      Transfer the file to Device D2 (using any method: email, USB drive, cyberlocker, etc.)

i.     Authenticate User U1 on Device D2 with Password P1

ii.     Read file on Device D2 using Reading System

d.     Expiry

i.     Lending period elapses

ii.     File no longer readable

e.      Share with a Friend – same as 1.e. above.

Proposal Requirements

The IDPF is seeking preliminary proposals from organizations interested in contributing a a concrete solution to the above requirements (or supersets thereof) which would enable the above use cases for the EPUB standard.  This can be existing technology, adaptation of existing technology, or newly-created technology.  We expect to be able to license technology to eBook distributors and vendors of reading systems (devices and apps) as part of EPUB 3 under a scheme that is to be defined but will conform to accepted principles of open, pro-competitive standards.  

Requested Information

Proposals should include the following information:

1.     Name of organization, name and contact information for point person on the response.

2.     Description and background of the proposing organization.

3.     Description of the solution being proposed; submission of existing white papers or other documents is fine.

4.     Descriptions of how the proposed solution meets the requirements; references to points in the above documentation are fine.

5.     Description of existing implementation(s) of the proposed solution:

a.      Technical aspects. e.g. programming language, operating system dependencies, etc.\

b.     Example deployments (current or historical) with approximate maximum installed bases.

6.     Descriptions of functionality above and beyond the requirements, with explanations of how such functionality can be added/removed and identification of any such functionality that cannot be removed.

7.     We will consider submissions of solutions whose functionalities do not meet the requirements given here; for such technologies, we require:

a.      Description of differences in functionality between the proposed technology and the requirements stated here (requirements not met)

b.     Descriptions of reasons for each of those differences, with emphasis on how the differing functionalities will help IDPF better achieve its goals with this initiative.

8.     Background of the proposed solution, where applicable, including:

a.      History of development

b.     List of existing services, devices, and software applications that use or have used the proposed technology, along with geographies and estimates of installed bases (current or historical)

9.     Where applicable, a description of development effort necessary to adapt existing technology or develop new technology to meet requirements stated here.

10.   Description of requirements for facilities and services such as root-of-trust and client registration, including:

a.      Who operates them (proposer, content distributors, third party/ies)

b.     Ways in which content distributors must integrate and interact with them

11.   A list of patents believed by the proposing organization to read on the proposed technology, including whether or not those patents are assigned to the proposing organization.

12.   Description of technology licensing expectations, such as royalty schemes if applicable (just descriptions of the desired structure for now; financial discussions will come later in the process).

Please send proposals by email to Bill McCoy, IDPF Executive Director, at bmccoy@idpf.org.


●      Deadline for proposals is August 31, 2012. 

●      Proposers should anticipate receiving a response from IDPF by September 15, 2012.

●      Between September 15 and October 15 2012, proposers should be prepared to engage in further discussion with IDPF about next steps, including potentially the scheduling of a detailed follow-up presentation.

[1]“Password” is used here in a generic fashion to mean “shared secret” in the cryptographic sense.  Implementations could present shared secrets as, for example, combinations of user IDs and passwords, and use a user’s ID in an e-commerce or library lending system as part of the shared secret.

Secondary menu