Protecting Form Internals

Recently I was involved in a discussion around protecting the contents of a form.  The request was to be able to protect the form logic and parts of the form data from tools that could extract this information from the PDF.  There are various reasons behind this request, including:

  1. Some of the form data is "office use only".  The data is not bound to any form fields, but it is used in some of the form logic/calculations.  This data could be sensitive.
  2. Script embedded in the form represents intellectual property that the form author does not want to share.
  3. Having access to the form definition makes it easy to create a spoofed version of the form for a phishing attack

I have sympathy for all these reasons.   But the bottom line is that there are many different methods and tools you can use to extract the contents of a PDF.  I’ve distributed samples on this blog to do just that.  The latest example is the lint checking tool that extracts all the script from your form and highlights coding issues.

There are lots of great workflows that are enabled because the contents of the PDF are shareable.  It’s one of the strengths of the solution.  But on the other hand, we don’t always want to share everything.  And we want to offer protection to our clients.  There are some strategies to help you along:

Document Encryption

You can encrypt the contents of your form.  Users then need a digital id or password to open the file.  The contents of the PDF are hidden from anyone who does not have the necessary credentials.  Everything is hidden behind the encryption — including the form definition and the data.  However, encryption doesn’t satisfy all needs:

  • Those who have credentials have full access to the form definition and data.  It’s not possible to hide selected parts of the form contents.
  • It is not viable to require credentials to access forms distributed to the general public.

Edit Password

You can specify a password on your PDF to restrict editing of the form.  This prevents users from bringing the form into Designer and making modifications to the form.  However it does not prevent users from using various tools to extract the contents of the form and making an editable copy.  The edit password sends a message to your friendly users to ‘keep their hands off’, but it is not a deterrent to a hacker.

Document Certification

Certification is the best defence against a phishing attack.  Your form definition can always be forged.  Even if we prevent access to the form definition, the attacker can always imitate the appearance and behaviour of your form from scratch.  But while someone might be able to make a copy of your form, the attacker cannot spoof certification.  Train your users to download their forms from your website and train them to expect valid certification on these forms.  With certification they can be certain that the form they’re using has been authored by you.

Secure Submit

We worry about the safety of user data during submission.  To protect user data, make sure the connection you provide for submission is secure.  Use https for submissions and the data will be encrypted during transmission.

XML Signatures

Any discussion about secure data is not complete without also mentioning XML Signatures.  XML Signatures allow the end-user to sign the data that they submit.  Signing data has two primary benefits:

  1. Establishes the identity of the person who signed the data
  2. Confirms that the data has not been tampered en-route

Server-side Processing

Sensitive form processing can be delegated to the server.  When the logic runs on the server, the execution details can be hidden.  There are several strategies to accomplish this:

  • Mark calculations to run-at server.  When using LiveCycle Forms, this will round-trip the form data to the host to allow a calculation to run in the context of the server. 
  • Use a web service.  Send a SOAP request to the server and get data back.
  • Communicate to a server-side process directly using a http submit or using formcalc put/post/get methods.

Of course, the disadvantages of relying on the server are:

  • It means that parts of your form logic will work only when the user is online
  • Frequent server interaction may limit the scalability of the solution
  • Server-based solutions are expensive


Script Logic

Some of us have a natural ability to obfuscate our JavaScript code by writing cryptic, comment-free code :-).  But there are more methodical things you can do.  For starters, you can use a JavaScript obfuscator to make your code very difficult to read. 

Script logic can be stored in byte code format — or more specifically — in an embedded SWF file.  Today this is an option only for static XFA forms that run on the client. It’s not possible for dynamic forms or for forms that need their logic to run on the server.


It’s pretty hard to hide your data, especially given that Acrobat users can extract it using the menu command: Forms/Manage Form Data/Export Data…  But there are some things you can do to prevent easy access:

  • Put the sensitive parts of your data somewhere other than <xfa:datasets/>.  e.g. You can put it in a generic packet under the <xdp/> element.  To process it at runtime, load it into an E4X object.  Storing in a different location will hide it from the average user who knows how to export data.
  • Sensitive data can be disguised.  Look at how you tag your data.  If your element is called <ManagerSalary/> then the meaning is pretty clear.  However, if it’s tagged as <value37/> then more context is needed to figure out what the data holds. 
  • You can apply basic encoding on the contents of the data.  e.g. You could take a fragment of your data and store it as a base64-encoded blob.  Your form would then need to include logic to decode and process this data.  This will not fool the determined hacker.  They will figure out that the script to decode the data lives inside the form.  But it will hide the data from the casual observer.

Ultimately, obfuscation does not provide complete protection, it is merely a deterrent.  We should always assume that obfuscated contents can be reverse-engineered into something meaningful.

8 Responses to Protecting Form Internals

  1. Scott says:

    Very interesting article. I wish there was way to encrypt the scripting and editing of the layout of the PDF. A password is the only way currently provided, but unfortunately that’s easy to get past. I get this question a lot on how to protect the livecycle editing. Im hoping a future version of liveCycle will address this.

    On a related note, I have a form which simply has to be digitally signed and routed, but it requires the user to save the form after signing the form. Is there a way to allow a user to sign a form, then submit a form with as few clicks as possible. Because currently, they have to sign it, save it, click the submit button, then when they close the form, it prompts to save the form again.
    Ideally if they could sign it and click submit with no saving, that would be ideal. Because if you don’t have a digital signature field, you can just fill out a field and click submit without saving which is nice.
    I guess I dont understand why signature fields require a save

    • RE: Encrypting XFA form logic: With Acrobat/Reader/Designer 10.0, you can encrypt XFA form logic using XML encryption. Only somebody/something with a credential capable of decrypting the form logic can obtain the cleartext form logic.

      RE: Signing an XFA form without save prompts: One way to accomplish this would be to use XML signatures. You can submit XML signed content in a single operation without any save prompts.

      As for PDF signatures, the save after close may be caused by the form logic or it may have been a bug in a prior implementations. With current product, if I submit an XFA form with a PDF signature, and then close the XFA form, I see NO save prompts. The save DURING signing cannot be avoided: PDF signatures require this save. However, if you can use the field.signatureSign javascript method, you can automate the save so the user does not have to be involved. Using this approach, you could also combine the signing and submission into a single operation if you so desired.

      A good place to learn about XML encryption and XML signatures is the Designer 10.0 help. To learn about the field.signatureSign javascript method, a good place to start is the Acrobat Javascript Scripting Reference.

  2. scott says:

    This will be so helpful. For the XML encryption, where can I read about this? and I don’t think I understand what is being encrypted and when. That is, if I’m delivering a PDF to a client to use, where and when am I performing this encryption?

  3. Scott sheck says:

    Thanks. I was looking for a way to encrypt the scripts and/or the PDF so that no one can open the PDF in designer and modify the form. For instance, Sone clients dont want to reveal their algorithms in their PDF, or resell their PDF, etc.

    So I was hoping the next version of livecycle designer could make a PDF more secure than just a password.

    • John Brinkman says:

      If your goal is to hide your form scripts, I don’t think that XML encryption will be any better than PDF encryption. Really, this is not a problem that we can solve for you. It’s the same issue that html authors face. If you want javascript to run at the client, it will be visible to the consumer. The best you can do is obfuscate your script, or have your script run at the server.

  4. scott says:

    Hi john,

    I’m creating a generic routing/review workflow module for my PDFs that allows a user to add approvers/reviewers to a dynamic table and then the program will allow the user route the PDF to the various persons.

    The issue I’ve run up against is that Livecycle doesn’t allow digital signature fields to be placed in a dynamic table. Why is this? I’m hoping there’s a way i can have a variable number of digital signatures.

  5. Scott:
    You’ve encountered a design limitation. The underlying reason for not allowing repeating signatures is that the signature widget (and related objects) cannot be created dynamically. We need to create all instances of them when the PDF is first generated. So your form designs will need to work with a fixed number of signatures.