Posts in Category "FAQ"

Packaging options for encrypted PDFs

Since Acrobat 2.0 in 1994, encryption has been available to protect a PDF document – restricting who can open it and what they can subsequently do with it. Today, there are a number of packaging options for distributing one or more protected PDF files.

Continue reading…

Acrobat 9 and password encryption

Based on some recent online discussion of Acrobat 9 and password encryption, we’re posting to provide a quick summary on what has changed, how it impacts the overall security of PDF documents, and Adobe’s commitment to providing high-assurance document security implementations.

Continue reading…

Update: FIPS 140 Validation Certificates for Acrobat, Reader, and LiveCycle

Version 9.0 of Adobe Acrobat and Adobe Reader include the RSA BSAFE Crypto-C ME 2.1.0.3 encryption module with FIPS 140-2 validation certificate #828. Instructions here will also enable FIPS mode in Acrobat and Reader 9.0 to restrict document encryption and digital signatures to FIPS approved algorithms (AES/RSA/SHA) in this library.

Adobe LiveCycle ES still includes the RSA BSAFE Crypto-J 3.5.04 encryption module with FIPS 140-2 validation certificate #590. FIPS mode is configured in the product installer.

LiveCycle Digital Signatures: Three Common Use Cases

With Adobe LiveCycle Digital Signatures, a solution component of the LiveCycle Enterprise Suite, you can easily automate digital signature processes, enabling your organization to bring more paper-based processes online. By facilitating a 100% electronic workflow, with no paper-out for handwritten signatures or special document authenticity seals, you can reduce costs, improve compliance, increase user satisfaction, and accelerate business processes. This article highlights three common uses cases of this J2EE server component for digital signatures.

1. Automated Certified Document Publishing

Since version 6.0 of Acrobat and Reader, certified documents have provided documents recipients with added assurances that the document was published by the named author and has not been modified. This is indicated by a blue ribbon:

When a certified document is opened with Acrobat or Reader, the Document Message Bar across the top of the document indicates the author’s name, email, organization, and verifying third party.  Adobe published it’s Q3 2008 10Q as a certified document, like this:

Certifying digital signatures can automatically validate in Acrobat and Reader – without any additional software installation or configuration, by using the Certified Document Services program

Certified documents can be created manually using Adobe Acrobat on the desktop via File -> Save as Certified Document.  If you have a lot of documents to certify, or want to otherwise automate the certification process, LiveCycle Digital Signatures is the solution. The signing credential can either be stored in software on the server, or be more securely stored in a hardware security module (HSM) from one of Adobe’s Security Partners.  Then a process is designed within LiveCycle to specify the file input, signature properties, and resulting output. Some examples include webservices, drop folders/network shares, content management systems like LiveCycle Content Services  powered by Alfresco or Documentum, Sharepoint, FileNet, etc.

If you are also looking to automate document generation with certified documents, LiveCycle Digital Signatures can be integrated with LiveCycle PDF Generator and LiveCycle PDF Generator 3D to convert native documents to PDF and certify them in a single automated server process.

Certified documents are applicable not only for static documents, but also for interactive forms.  When coupled with LiveCycle Forms and LiveCycle Process Management, the automated certification can apply to the form template being delivered to a participant.  For example, if you are offering a loan of 30yr fixed at 6%, and want to have added assurances that what you sent out to a user is the same thing you get back (and not 60yrs at 3%!) – the certifying signature can be automatically applied to forms as they are generated and routed to participants in a workflow.  If certified form template data is modified or a fraudulent form is introduced into the process, LiveCycle can generate an exception when a document is returned with the certifying signature missing or invalid.

To see more certified documents in action, visit the US Government Printing Office website where they used LiveCycle Digital Signatures to digitally sign the FY2009 Federal Budget. University registrars, such as Penn State, University of Colorado, and University of Southern California, are also certifying official transcripts and delivering them faster, cheaper, and more secure than paper – by using certified PDF documents.

2. Workflow Validation

In a paper world, someone needs to manually examine every document to determine if all handwritten signatures have been applied by the right people in the right places.  Fortunately in the digital world, LiveCycle Digital Signatures provides a signature validation engine for automating the receipt of digitally signed PDF documents. If you are sending out forms and contracts to be digitally signed by Acrobat or Reader users on the desktop, LiveCycle can subsequently receive those signed documents and check the signatures as part of an automated process.

The server side validation engine is configured using root PKI certificates as trust anchors to validate the certificate chain of each signature.  The server is also capable of doing CRL and OCSP checks to verify that the signing credentials are not revoked. Those capabilities are coupled with the document integrity checks to verify that the current document and its signature have the same cryptographic fingerprint using hashing algorithms such as MD5, SHA1, SHA256, etc. If any of the signatures on a document are not valid, exceptions are generated in the business process. Otherwise, a document with valid signatures can more quickly proceed through the process without user intervention.

In the first use case described above, certified documents were recommended as a way to have added assurances that what is sent out, is the same as what’s being received. LiveCycle can take a form template, such as one with loan terms, and certify it. It can then be delivered and reviewed by a recipient, digitally signed, and returned back to the server. LiveCycle’s digital signature validation engine first checks that the certifying signature on the form template is still valid (eg the loan terms). Then LiveCycle can validate that the recipient has applied their own digital signature on top of and data they supplied and the underlying form template. If the document needs multiple approvals, it can continue validating multiple signatures on the document.  When the signature validation process is complete, LiveCycle is able to extract the form data from the signed document, process in other enterprise applications and then store a copy of the signed document in a content management system for archival.

3. Counter-signatures

Many paper processes are not complete until they have an official "RECEIVED on DATE" stamp applied, like this:

In an electronic business process, LIveCycle Digital Signatures can also apply the equivalent of the received stamp as part of an automated workflow.  After all of the document’s signatures have been validated any any additional field validation is performed on the supplied data – a final role-based signature can be applied in the server process, which can look something like this:

It’s also possible to create custom signature appearances so the digital signature actually looks like a paper-based received stamp.

There are many benefits to applying this final "received signature" as part of an automated server process. The received signature can provide a cryptographic based timestamp (RFC3161) to the document to show what exactly was received and when – important for time sensitive processes.  The signature can also indicate that at the time the document was received, all of the form data was valid and all of the digital signatures applied by any participants were also valid.

Setting Signature Trust in Adobe Reader & Adobe Acrobat – Part Three – “The How – Enterprise Trust Settings”

In August, we started to look at how one can set trust for signatures in Adobe Acrobat and Reader.  The first methods we focused on were user-based.  The challenge with these methods is that they require the user to have some background in digital certificate technology or, at the very least, be technically savvy.  The truth is, in most organizations, these methods could be confusing and administrators (and the legal or compliance departments) are not going to necessarily want users manually setting trust on certificates from outside parties.  Also, setting trust in the wrong certificate could lead to business risks when documents are received.  Enterprise-wide methods, on the other hand, can automate to a large degree what the user could do individually and also help to set standards for all users within an organization. 

 

Continue reading…

Live Webcast: Information Assurance – Keeping Your Documents Secure

Join us for this LIVE Event on:
Wednesday, October 29, 2008
12:00 PM PT / 3:00 PM ET

The need to keep your organization’s business critical information confidential by restricting distribution and preventing unauthorized disclosure of this information is imperative. Discover how Adobe Acrobat 9 can help protect your organization’s sensitive information by helping provide document control and security, addressing issues such as encryption, document authenticity, passwords, redaction, and sanitization/metadata removal. Join John Landwehr as he covers best practices on Security and Information Assurance.

More information and registration is available here.

Setting Signature Trust in Adobe Reader & Adobe Acrobat – Part Two – “The How – Manual Trust Settings”

In part one of this series, I discussed the three essential questions that Adobe products ask in regards to electronic signatures: (1) is the signature credential in good standing; (2) has the document changed since it was signed, and (3) has the relying party trusted the signer.  This third question is the one that is oftentimes left to the user or organization to answer, due to the unique circumstances of any particular situation.  Today we’ll discuss how users can set up that trust and provide the third leg of the tripod in the intrinsic valdiity of an electronic signature.

Signature credentials are trusted in Adobe products through the establishment and installation of trust anchors and trusted identities.  Trust anchors are typically root certificates—certificates at the top of the hierarchy from which other certificates are derived.  Trusted identities can be any certificate, even an end-entity, or user, certificate.  In any case, in order to pass validation, the signing certificate must either be a trust anchor (root) or be chained to (derived from) that root.

We’ll cover in this post the 3 ways an individual user can set trust in Adobe products.

Continue reading…

Setting Signature Trust in Adobe Reader & Adobe Acrobat – Part One – “The Why”

A few months ago, I wrote about the nature of assurance in electronic signatures and how aspects like authentication, audit, and integrity add to the trust you place in a signature.

When we consider electronic signatures, recognize that there are typically two parties to the transaction: the author / signer and the recipient, or relying party.  The signer’s role is obvious.  The relying party, on the other hand, is the one who is in the position to accept the signature and therefore the signer’s approval of the terms or nature of the signed document.  When faced with an electronic signature, the relying party must be aware (or have resources he/she can turn to, such as a lawyer) of three intersecting zones of validity—legal, contractual, and intrinsic—and how Adobe products can assist. 

Continue reading…

"This is legal, right?" – Electronic Signatures & The Law

,,,,,,

This entry is the third in our “What is an Electronic Signature, Anyway?” (Part One / Part Two) educational series.

First, a disclaimer.  This blog entry is not intended to provide legal advice.  You should discuss issues relating to the use of electronic signatures in your business with your own legal counsel and compliance officers.

With that out of the way, welcome back to our series on electronic signatures.  Up to now we’ve covered what can be defined as an electronic signature, and how one can provide assurance as to the validity of an electronic signature.  However, our clients and customers are mainly concerned with one thing:  are electronic signatures legality and admissible in a court of law?  Will my contract be null and void if use this electronic signature pad?  Will my account documents be tossed out because they’ve been digitally signed?  Can I accept electronic signatures on my contracts?

Only your legal counsel can answer these specifically, but, in this lengthy entry, we can offer some very high-level information on the applicable laws, what is meant by legal effect versus admissibility, the availability of case law, and where you can go to find out more information.

 

Laws

In 2000, President Clinton digitally signed into law the Electronic Signatures in Global and National Commerce Act (E-SIGN Act).  This public law provides that:

a signature, contract, or other record relating to such transaction may not be denied legal effect, validity, or enforceability solely because it is in electronic form; and (2) a contract relating to such transaction may not be denied legal effect, validity, or enforceability solely because an electronic signature or electronic record was used in its formation.

At the state level, the Uniform Electronic Transactions Act (UETA), passed by 48 US States, provides much the same protections to electronic signatures and records. (The remaining 2 states have other legislation covering electronic signatures.)

Note that neither piece of legislation specifies a particular electronic signature technology.  In fact, the E-Sign Act states that:

The term ‘‘electronic signature’’ means an electronic sound, symbol, or process, attached to or logically associated with a contract or other record and executed or adopted by a person with the intent to sign the record.

By keeping the legislation technology-agnostic, the law doesn’t create a bias and also does not have to be changed as technology changes.  It therefore has the added benefit of allowing for a wide spectrum of electronic signature technologies (click-thru, signature pad, biometrics, digital signatures, etc), as long as the systems provide a signature that is “attached” to the electronic document needing to be signed, and provide evidence to the fact that the signatory actually signed the electronic document, showing an “intent to sign.”  The laws do prohibit the use of electronic signatures on certain legal documents such as wills and adoption papers, though.

Other US laws and regulations provide guidance in specific industries.  For instance, 21 CFR Part 11 covers the use of digital signatures in communications with the Food and Drug Administration.  This is a good time to mention that laws are not the only things to be concerned about when it comes to electronic signatures.  You also have to be aware of any regulatory standards or recommendations that may be in place for your industry. 

Using the pharmaceutical industry again as an example, the SAFE-BioPharma Association ( Signatures and Authentication for Everyone), interested in promoting the use of electronic documents and reducing costs, created a technical, legal & business model around the use of electronic signatures among pharmaceutical manufacturers, clinical investigators and regulators.    In fact, SAFE requires the use of digital signatures, and has certified (and recently re-certified) PDF-based digital signatures in Adobe Reader®, Acrobat®, and LiveCycle® Digital Signatures within the SAFE standard.

Outside of the US, most countries have electronic signature laws in place, as well, though they vary in complexity.  For the 27 member states of the European Union, Directive 1999/93/EC on a Community Framework for Electronic Signatures (EU Signature Directive) provides an in-depth legal framework for electronic signatures and their validity inside and between EU countries.  It creates several categories of electronic signatures, with so-called “Qualified” signatures required to be legally accepted and valid in all EU member states.  The high assurance requirements around Qualified Electronic Signatures (QES) do point to digital signature technology, with a requirement for a ‘Secure Signature Creation Device’ and best practices around key generation, storage, and certification of the providers of the signing credentials themselves.

Adding to the fun, EU member states are required to individually transpose EU Directives into their own legislation.  Certain countries decided to tweak the text on the way to implementation, and in so doing, created another layer of complexity that makes working with cross-border electronic signatures quite a challenge!

Note that electronic signatures applied in the US may not be provided legal admissibility in the European Union, especially on documents like electronic, or e-, invoices.

 

Legal Effect vs. Admissibility

We’ve tossed these terms around in this entry, so it’s probably time to clarify the difference between the two.  While lawyers around the globe may cringe at my over-simplification, here we go…

“Legal effect” pretty much means that, yes, the court will accept that an “electronic signature” is a “signature” as already defined by precedent and law.  So, in other words, an electronic signature and a wet ink signature are equivalent in most respects, and they can be brought into trial.

However, just like their wet ink counterparts, each document intended to be entered into evidence in a trial will need to be assessed for its “admissibility,” whether it’s signed with ink or a digital certificate.  Does it represent the intent of the signatory?  Has the document been altered?  Who had the right to sign this document?  How was the signature derived, and what controlled access to the document for its signature?  These questions come into play no matter the type of signature.

However, wet ink signatures have been in use for quite a long time and have established a certain amount of credibility.  Electronic signatures, on the other hand, are a newer phenomenon, and thus may be more subject to the critical eye of the court.  This is where the concept of assurance, as described in the previous entry in this series, can come into play.  Higher assurance signature methods that authenticate the signer, use document fingerprinting (‘hashing’) to provide integrity, and store signature keys (and thus, the “pen”) in a secure manner, are more likely in the long run to be provided with the benefit of the doubt than those signature technologies which provide lesser assurance.

So, in the end, your electronic signature may be a legal signature, but it could be tossed out of court if the judge feels that the signature process did not provide the appropriate level of assurance.

 

Case Law 

Well, we’d love to point you to a particular case which ruled this or that technology admissible or signatures captured on these types of documents were OK, but there are none.  In the United States, there are likely hundreds of cases that cover subjects related to the use of electronic documents and e-discovery, but none that specifically cover challenges to electronic signatures.  While this could mean that cases are being handled in arbitration (outside the courts), or that challenges have not been filed, it is all the more likely that the courts have been holding electronic signatures as accessible.  

What the future holds, no one is certain.  The EU Signature Directive provides a clear sign that assurance does play a role in admissibility.  Will the ideas of the Directive take hold in other countries around the world?  How will US and state case law react to increasing numbers of electronic signatures?  We’ll keep watching…and we’ll keep you informed!

The good thing is that with Adobe products like Acrobat and LiveCycle you are gaining the ability to sign electronic documents (PDF) with a spectrum of electronic signatures, whether they’re electronically captured on a tablet PC, created with digital certificates, or even required to be compliant with the EU Signature Directive.  You can rely on Adobe’s global expertise in the field and years of collaboration with our Security Partner Community to meet your electronic signature needs, no matter the requirements.

 

Links

Here are some links to continue your reading.  Again, be sure to confer with your legal counsel on these topics.

  • ABA Digital Signature Guidelines Tutorial – A great starting point for understanding digital signatures from the American Bar Association.
  • The Sedona Conference® – Though focused primarily on electronic records, this educational non-profit organizations provides substantial coverage of related case law and issues that may come into play.
  • Electronic Signatures & Records Association (ESRA) – This association brings together vendors and business owners in its efforts to extol the benefits of electronic signatures and documents.  Adobe is a board member of the Association.

 

Next in our “What is an Electronic Signature, Anyway?” series will be an exploration of real world examples of electronic signatures in action around the world today and what the implications are for the businesses implementing them and the customers using them.

Flexibility in identifying and authenticating users – Part One

Rights management is used to manage usage rights to protect sensitive documents, ensuring that only authorized users have access to protected information. At its core, this is dynamic protection based upon user identities. To facilitate this, the system must know which individual users should have access to secured content.

Flexibility in identifying and authenticating users ensures that protection can be transparently integrated into preexisting infrastructure, and is central to effective deployment. The benefits should be clear: fast deployment, easy administration, and quick to achieve a return on investment.

LiveCycle Rights Management ES provides four fundamental types of authentication to the end-user: anonymous authentication, username/password authentication, Kerberos SSO authentication, and Smartcard/Certificate authentication. These enable out-of-the-box deployment into a variety of authentication infrastructure, along with allowing for substantial mechanisms for customization and integration.

In today’s topic, let me explain some of the possibilities and benefits associated with the first three authentication type:

Anonymous authentication

This type of authentication completely skips identifying the end-user! By granting “guest-level” access to content, end-users need not authenticate prior to being authorized to open content. This allows several workflows:

  1. Authors can distribute content and still control them through the “yank and replace” revocation mechanism. For example, an author can distribute a price sheet or a data capture form, and make sure that only the latest version of content can be viewed.
  2. Even though individual end-user identity is unknown, authorization can be controlled based upon IP address or the number of times content has been viewed. Further, detailed (though anonymous) audit records can keep track of how frequently documents are opened.

Username/password authentication

This is typically the most familiar authentication dialog within LiveCycle Rights Management ES:

RMLogin.jpg

This dialog is the gateway to the powerful “username/password” authentication; it provides out-of-the-box functionality to authenticate users against a variety of directory systems, as well as create a custom integration with other credential providers.

For example, you can authenticate users against supported LDAP directories (e.g., Microsoft Active Directory, Sun Directory Server, IBM Domino LDAP, Novell eDirectory, etc.) that you already have deployed. But there’s no need to limit yourself to LDAP users. We provide two out-of-the-box mechanisms for managing user accounts for customers without existing directory infrastructure: “invited users” and “local users”. Think of these accounts as being stored “locally” within our own built-in directory. Administrators can manage these accounts using our built-in APIs and GUI, and the facility exists for end-users to quickly and easily provision their own accounts.

In all these cases, the end user simply enters his username and password upon opening a document and the server automatically queries the relevant system to verify credentials and further authorize the user. If the administrator chooses to allow it, the end user can also instruct the client to remember his credentials, which will securely cache credentials and not bother him to authenticate for subsequent documents. For many customers, this can enable an inexpensive form of “Single Sign-On” (SSO), since end users would see an authentication dialog at most once, and likely forget they are opening protected content.

This authentication type, however, is much more flexible than basic username/password integration with directory services. We can enable integration with any credential system that traffics in two user-inputted strings. This is because LiveCycle Rights Management ES can dynamically customize this authentication dialog, and because a customer can develop a custom authentication provider integration via the server-based “SPIs”.

For example, some of our financial industry customers have leveraged their existing account management infrastructure, allowing their customers to authenticate via their existing account number and PIN to their policy-protected banking statements. Others have used these SPIs to integrate with one-time password (OTP) systems to enable multi-factor authentication.

Kerberos SSO authentication

Those customers who want the ultimate “transparent integration” with existing authentication infrastructure can choose to enable Kerberos-based single sign-on (SSO). This is an outstanding option for those who feel that “clicks ‘R’ bad”, and never want to be impacted with an authentication dialog.

Because end users never see an authentication dialog when opening a protected document, and frequently forget are accessing protected content, they often think of this authentication type as “magic.”

Based upon technology built into Microsoft Windows clients and Microsoft Active Directory on the server, Kerberos SSO allows LiveCycle Rights Management ES clients to securely use the credentials entered the end-user used when logging into his machine to authenticate directly with the Rights Management server.

Next time: A deep dive on smartcard/certificate authentication and the benefits to customers.


Need more information on how your organization can effectively manage and protect your intellectual property? Further information can be obtained at http://www.adobe.com/go/rm or by contacting Adobe