Preventing "Save As" in Adobe PDF

Question

We have a requirement to prevent saving additional copies of PDFs that exist out on a network drive. Currently, we have "locked down" the PDFs as much as the format will allow - which means prevently copy/paste, editing, and printing. However, the client requires that no one be able to create an additional copy of the PDF once they have it open.

Using native PDF, this is not possible, because firstly, they can always click the link in the browser and "Save As..." to their desktop. Also, they can click "Save As..." inside of the Acrobat Reader and there's no way (short of hacking) to turn that off. Also, even if we hacked the Acrobat Viewer, there's always a chance that they might view and re-save the PDF in another 3rd party viewer.

There are a couple of initial alternatives that come to mind:

1. Use a DRM provider to lock down the access to the files - this is not an option due to the expense

2. Create a web service that converts the files to TIFF and then encrytps them with a "secret" key and serves them up as ".abc" files. Create a special viewer for ".abc" files that only runs internal to the client's network and opens this file and decrypts it. Without the custom viewer they can't view the files. They could make copies of them, but if the viewer is locked down to their individual machine or must run within the corporate network (checks for secret key from web service before launching, for instance), any copies they make won't be open-able.

3. Create a Flash or Silverlight viewer that essentially does the same thing as above, but never actually saves the file to the PC - just shows it within the browser.

Does anyone have any other alternatives that might be simpler? The goal isn't to have 100% bomb-proof security, just to prevent employees from easily making copies, emailing those copies to competitors, friends, or other folks who shouldn't have access to these sensitive files.

Answer 1

You can disable the Print Screen key using a script or Group Policy.

An example has been copied out below from here.

Windows Shell Script

# =============================================================================# 
#* THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF          *# 
#* ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED           *# 
#* TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A          *# 
#* PARTICULAR PURPOSE.                                                        *# 
# =============================================================================# 
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout] 
"Scancode Map"=hex:00,00,00,00,00,00,00,00,04,00,00,00,2a,e0,37,e0,00,00,37,e0,00,00,54,00,00,00,00,00 
# ****************************************************************************** 
# The sample scripts are not supported under any Microsoft 
# standard support program or service. The sample scripts 
# are provided AS IS without warranty of any kind. Microsoft 
# further disclaims all implied warranties including, without 
# limitation, any implied warranties of merchantability or of 
# fitness for a particular purpose. The entire risk arising out 
# of the use or performance of the sample scripts and documentation 
# remains with you. In no event shall Microsoft, its authors, or  
# anyone else involved in the creation, production, or delivery of  
# the scripts be liable for any damages whatsoever (including, without 
# limitation, damages for loss of business profits, business  
# interruption, loss of business information, or other pecuniary loss) 
# arising out of the use of or inability to use the sample scripts or 
# documentation, even if Microsoft has been advised of the possibility 
# of such damages. 
# ****************************************************************************** 

Answer 2

There is no way to be completely secure given your constraints. If the data is valuable enough people will find ways. The most primitive is to manually copy it, a step above that is to take a photo (cellphone) of each page, a step above that would be a print screen, a step above that is some print-screen macro which saves all the pages to a folder, a step above that is to read it from memory.

Still if your goal is merely "good enough" security (understanding it can be defeated but most users will not be willing to do so) would be a "customer reader". It could be done via flash or silverlight. It could even be done via a standalone winform application.

There are libraries for displaying pdf. You could simply "wrap" the pdf file in an encryption layer, give it a unique extension (pdx) and have your "custom player" decrypt and display the pdf. Given you are implementing a pdf library you could control exactly what options are available. You should also look into techniques to make print-screen more difficult as you will simply move the attack vector to print-screen next.

Answer 3

The only option you've mentioned that has any chance of working (and not being way too costly to implement) is the custom reader.

The reader application should not ever have any 'secret' information (such as the keys) stored in it, and it should only be able to be used internally, by accessing both key and image data via a private web service. You've already noted that.

It should also not store files at all; but simply load the key and data into memory, decrypt the image, then provide viewing for it.

The 'difficult' part would be converting the data, really. The rest is fairly basic stuff, for the most part.

The caveat here is that it would still be easy for a user to print screen and save the image.

Ultimately, the only truly secure method to let them see the documents but not save them is to totally prevent them from viewing the documents on a system to which they have any physical or general network access.

Answer 4

Well, wouldn't they be able to still get the information using print screen? And in the end, the user can always just rewrite it by hand. Security is really only about raising the bar, making it too tedious or too time-consuming to steal the information.

I would say that method 2 is very elaborate and will consume a lot of your time, while still vulnerable to printing the screen. I would do number 3, where you can reuse lots of existing code, and get a similar level of security.