Encrypting XODs and implementing a custom DRM on top of WebViewer

[Support]

Q:

 

For our application, it’s really important that we can prevent end users from copying the content of our PDF files (or downloading the .xod files and converting them back to PDF or using them outside the browser).  In the WebViewer benefits section, you list “secure: support AES, custom encryption and DRM extensions” as a benefit.  But I can’t find any documentation on how you would implement DRM with WebViewer.  Can you help give some more information on this?

 

------------

 

A:  There are multiple ways the security layer could be implemented and WebViewer includes interface that could be used to implement custom security.

 

A potential solution that does not involve the use of any server side component would be to encrypt all files using ZIP AES 256 encryption (http://www.winzip.com/aes_info.htm).

 

AES provides strong encryption and has been selected by NIST as a Federal Information Processing Standard in November 2001 (FIPS-197), and in June

2003 the U.S. Government (NSA) announced that AES is secure enough to protect classified information up to the TOP SECRET level .

 

You could use one of many free utilities, libraries (http://code.google.com/p/winzipaes/), or if you would like we could also add extra option in PDFNet/docpub to automatically encrypt the file for you.

 

This way downloading the XOD would not help since the file is encrypted (and it would be very difficult to crack proprietary AES data with a good secret key). After your files are encrypted you could upload them to any server. If a user captures the data stream it would not be helpful since it would be encrypted.

 

Perhaps the simplest way to illustrate this would be via a sample.  The following is a modified sample viewer that works on encrypted XODs:

 

http://www.pdftron.com/pdfnet/webviewer/encrypt_sample/ReaderControl.html?d=/xod/newsletter-4Bnew.xod&v=html5

 

In this sample document (http://www.pdftron.com/xod/newsletter-4Bnew.xod) each document part byte has been XOR-ed with the value 0x4B. In the file ReaderControl.js a part retriever(line: 982) is created and a custom function(line:956 "decrypt")  is passed, which does the actual decryption of the document parts. The document is viewable only after passing this function.