Main

November 3, 2009

Straight Talk about PDF & Digital Signatures - ISSE 2009

Jim King, PDF Architect, senior principal scientist at Adobe and one of the key drivers behind the PDF format and its adoption and continuing development by ISO as a standard (ISO 32000), recently delivered a keynote presentation to the ISSE (Information Security Solutions Europe) 2009 Conference in The Hague, Netherlands.  He discussed the evolution of the PDF format and standard, and spent most of his talk introducing the new PAdES signature standard and what it encompasses.

During that conference, Jim sat down with Roger Dean, executive director of eema UK, for a conversation about PDF, the need for digital signatures, challenges of communicating the benefits of digital signatures, and finally a description of the PAdES standard.  This interview is now available below (and here)...enjoy!


September 23, 2009

Eliminating the Pen...One Step at a Time: PAdES PDF Advanced Electronic Signature Standard Released for EU

Building on the delivery of the PDF format to the International Standards Organization (ISO) as ISO 32000-1, Adobe has been collaborating with standards bodies around the world to make it easier for companies, organizations and individuals to leverage the ubiquity of PDF to make business processes quicker, easier and more reliable.  However, the rush to go paperless has often fallen short of its true potential because signing a document oftentimes brings business critical processes crashing to a halt, requiring users to print out the previously electronic document in order to apply their nom de plume with an ancient writing implement.  Electronic signatures are obviously the solution, but there’s still the question of interoperability and the use of electronically signed documents within certain legal frameworks, such as the European Union (EU).  With last week’s announcement of an ETSI open standard for PDF digital signatures, that question can now be answered.

ETSI/ESI Technical Standard (TS) 102 778, better known as PAdES (pronounced with either a long or short a), documents how the digital signature format described in ISO 32000-1 meets the needs of the 1999 EU Signature Directive (see previous blog entry), and then goes on to describe how that format can be expanded to take advantage of certain capabilities such as long-term document validation, where digital signatures placed on documents today can be validated five, ten and even 50 years later.  (The standard can be downloaded free of charge from the ETSI website at http://pda.etsi.org/pda/.)

Continue reading "Eliminating the Pen...One Step at a Time: PAdES PDF Advanced Electronic Signature Standard Released for EU" »

August 27, 2009

Finding your way in the wood: Signature Terminology and Security Resources

If you've been following this blog, you'll know that we toss around lots of terms in each entry, along with references to standards, technologies, products and services.  Even if you haven't read this blog before, you may have struggled trying to understand the difference between electronic and digital signatures, or what a "PKCS#11" is, or, for that matter, a trust anchor.

Well, struggle no more--today we published our latest security terms glossary, which should help to clearly define terms and keep everyone here in line with usage. (Let us know if we don't!)   Over 140 terms are defined, along with spelled out acronyms, so you are no longer in the dark!  

What's more, the glossary is posted on our Security Document Library site, part of the learn.adobe.com wiki area of Adobe's web presence.   The Document Library contains links to the latest security documentation, including an omnibus guide, "Digital Signatures & Rights Management in the Acrobat Family of Products,"  which consolidates many separate documents we've had in the past on signatures, preferences, registry settings, encryption and the like.  In addition, there are links to many useful one page 'keys' on signature validation, icons, signature creation, etc.

Find the glossary here.  If we've missed any terms or some element of documentation, please email John Harris at jbharris(at)adobe.com.

Tags:,,,,

May 28, 2009

“Sign here...” Getting started with electronic signatures in Adobe products

This is the latest entry in our “What is an Electronic Signature, Anyway?” series.  You can find previous entries here.

Recently, I’ve received a number of emails from our users asking questions about electronic signatures, so I thought it would be useful to briefly answer some of these frequently asked questions and also direct you, dear reader, to a variety of resources here at Adobe that can help.

First, I recommend you read the other blog entries in our “What is an Electronic Signature, Anyway? “ series to better understand the terminology and issues surrounding electronic signatures.

Now onto the questions...

I want to electronically sign a PDF—what do I need to do?

There are lots of different ways to electronically ‘sign’ documents, but they vary in terms of reliability, longer-term validity, and application.

Continue reading "“Sign here...” Getting started with electronic signatures in Adobe products" »

March 13, 2009

NIST FDCC Compliance with Adobe Acrobat and Reader

Adobe Acrobat and Adobe Reader have been tested and meet the NIST FDCC compliance guidelines according to the testing process provided in OMB memo m08‐22. Compliance was verified by testing the product using the following procedures:

Continue reading "NIST FDCC Compliance with Adobe Acrobat and Reader" »

February 26, 2009

Primer on Server Base URL

One frequently asked question I get is about the “Base URL” setting within the LiveCycle Rights Management ES server configuration. What is this for? It’s a global setting that is used in several places where the server must identify its location to a remote client. The text is used as a “base” for deriving various types of server URLs. Here is a screenshot of the relevant configuration section of the administrative web console:

Here are two examples of its use in the system:

  • Have you ever wondered how, when somebody opens a RM protected document, the client determines your credentials and decrypts the document? “Baked” into each protected document are two important pieces of unencrypted information: a globally unique identifier (the document GUID), and the server address that the client contacts to receive authorization to decrypt and open the document. The server address is a derivative of the base URL that the administrator configured when setting up the server.
  • When an author or recipient performs a “web-based action” on a particular document, the client will automatically receive a single-sign-on-based redirect to a web age populated with the appropriate information. For example, the client-based request to view the audit history of a document opens a web browser showing which users have viewed, modified, or printed a protected document. The end-user experience is seamless, and the redirect instruction is derived from the base url of the document.

 

The advantage of deriving URLs from this base URL is that it simplifies the end-user experience, as outlined above, and gives flexibility to customers implementing a LiveCycle Rights Management server. This flexibility means that administrators can leverage DNS as a layer of indirection between client and ultimate server(s). DNS, for example, can provide different routes to a server depending on whether a document viewer is located inside or outside of a company’s network. It can also be used in with a load-balanced cluster to ensure that LiveCycle Rights Management runs as a high-availability and high-throughput system.

However, when configuring this URL you need to be careful: by changing settings on the server, you may orphan existing secured documents if you neglect to update DNS to point to the new server. Also, because of the sensitive information communicated between our server and clients (e.g., Adobe Acrobat, Adobe Reader, the LiveCycle Rights Management ES Extensions for Microsoft Office, PTC Pro/ENGINEER, …), we strongly advocate that the URL specified be HTTPS such that the communication is done over SSL. In fact, most of our clients will refuse to talk to a server URL that is not specified as HTTPS. (Specifying a HTTP-based URL will attempt to force the client to communicate over HTTP, however this is likely to fail because our clients generally do not support non-SSL connections.)


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


February 15, 2009

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 "Packaging options for encrypted PDFs" »

December 1, 2008

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 "Acrobat 9 and password encryption" »

November 12, 2008

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.

November 10, 2008

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.

October 15, 2008

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 "Setting Signature Trust in Adobe Reader & Adobe Acrobat – Part Three – “The How – Enterprise Trust Settings”" »

October 13, 2008

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.

August 29, 2008

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 Two – “The How – Manual Trust Settings”" »

August 28, 2008

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 "Setting Signature Trust in Adobe Reader & Adobe Acrobat – Part One – “The Why”" »

May 30, 2008

"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.


May 28, 2008

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

February 29, 2008

"Trust Us!" - Electronic Signatures and Assurance

,,,,,

This entry continues our “What is an Electronic Signature, Anyway?” educational series.

Merriam-Webster defines assurance as “something that inspires confidence” and “freedom from self-doubt or uncertainty.”  When you receive an electronic document, how do you know it’s the document the author intended you to receive?  Likewise, if that document is an electronically-signed contract, how do you know who actually signed it?  How do you know the other party didn’t change the document after you sent it?  Assurance, as you can see, is critical to trusting the work that we store, put or send online.  Electronic signatures can provide a way to enhance your confidence in these documents in a paperless environment.

We can break down the most significant aspects of electronic signature assurance into the following components:

  • Authentication

Authentication deals with how a user verified him or herself to the signing system.  The more complex the type of authentication and the more ‘factors’ of authentication you combine, the higher the level of assurance becomes.  Did they simply click a button or did they first have to enter a username and password?  Authentication to a system is stronger if a user must present both a physical device (token or smart card) and a PIN or password to the system - a combination known as ‘two-factor authentication.’  Handwritten eSignatures inherit some level of assurance from their historical wet ink cousin.  Even biometric technology could be added to the picture, requiring persons to present ‘something they are,’ like a fingerprint or iris, to verify themselves. 

  • Identity Vetting

Identity vetting, or identity verification, answers the question, “How did the system arrive at trust in this signer?”  In other words, how did an organization or system grant a signer her signing credential or access to the signing system?  The intensity of this process can help to define assurance.  Is the signer being asked to appear in person and present multiple forms of government ID, or are they simply required to enter their name and click “OK”?  The more intense the scrutiny, the better the level of assurance.

  • Integrity

Integrity is one of the key capabilities of an electronic signature.  An electronic signature often includes the capability to “fingerprint” or hash a document so that a recipient can verify that a signed document was not changed post-signature.  Integrity can be achieved in a number of ways.  Some methodologies use cryptographic calculations, like a signed hash and digital signature embedded in a document verifiable by the reader of a document, to achieve integrity.  Others systems may offer integrity through secure archiving of original electronic documents and a strong audit trail of events that lead to the signature event itself. 

  • Validity

Validity, or put another way, the legitimacy of the user’s signing credential or access at the time of signature, is another critical aspect of assurance.  The user may be who he says he is, and may have used the proper methods for authentication, but what if they signing credential had been revoked before the time of signing because the user was fired from their organization?  Signing systems offering higher levels of assurance should be able to establish validity at the actual time of signing.

  • Time of signing

The time of signing is the final key element of assurance in electronic signatures.  A PC clock may be modified to fraudulently indicate time of signing, and thus a trusted third party clock can provide more assurance.

Not all electronic signatures are equal, however, when it comes to assurance.  The following diagram shows a stereotypical breakdown of assurance compared with average cost.

You can see that click-through electronic signatures inhabit the low end of the spectrum and multi-factor authenticated digital signatures occupy the high ground.  But not everything is as it seems.  If certain pieces of the assurance puzzle are missing, the arrangement above could be completely scrambled.

For example, you may have a digital signature system that requires the user to possess a device that requires both their fingerprint and a PIN code in order to sign a document.  On its face, this looks pretty secure.  But what if the system used to provide the user with the signing credential (a digital ID) never checked into that user’s identity?  Bob Smith could be signing in the name of Adobe's CEO and no one would be any wiser.

Coming from the other direction, you might imagine a contract workflow that only requires a button click to process a signature.  This seems low assurance at first glance.  But if we add fingerprint authentication, strong identity vetting (in-person proofing), and a secure infrastructure in which the documents are processed and stored, one could argue the assurance of this system surpasses other technologies.

In the end, you will need to educate yourself and ask questions about the assurance capabilities of the electronic signature systems you intend to deploy.  The choice of an electronic signature method comes down to a decision about what you’re trying to protect and provide assurance to.  Simple travel expense reports do not require significant assurance measures, but multimillion dollar contracts definitely would.  Interoffice memos proclaiming a new copier in the mailroom don’t require much assurance, but critical government documents like the US Federal Budget do.

The next in our “What is an Electronic Signature Anyway?” series will focus on the legal admissibility of electronic signatures and the laws that govern their use.


February 21, 2008

“So what is an electronic signature anyway?”

As I reviewed the blog entries here from my fellow Adobe Security Solutions teammates, I realized that with all of the gory technical information, we may have lost some of you, our dear readers.  With this entry, we’ll start a new series of articles that move the conversation up to a high-level, out of the dense fog of acronym warfare, and explain from a business user’s point of view what all this stuff means and how it can be useful for you in your organizations’ daily business processes.

So...electronic signatures.  We’ve variously mentioned digital signatures, eSignatures, electronic signatures, and signature odors.  Ok, well, not the last one, but to start, I’ll suggest that we use electronic signature as a generic term.  Electronic signatures can be defined as any electronic process signifying an approval to terms, and/or a document, presented in electronic format.  Electronic signatures frequently also have the added benefit of ensuring the integrity of the signed document to signify that (1) the document has not been changed since it was signed and (2) the signer cannot ‘repudiate’ or claim that they did not sign the document.

Electronic signatures encompass a broad gamut of technologies and methodologies, ranging from an “I agree” button in a click-thru agreement...

 

 

...to an electronic tablet which accepts a handwritten signature (oftentimes referred to as an eSignature)...

 

 

...to a digital signature cryptographically tied to a digital ID or certificate.

 

 

They can be used for internal approval processes for things as simple as time-off requests, for more formal documentation and acceptance of account opening terms in a branch office of a bank, for signing off on critical infrastructure planning documents, and to protecting the reputation of a country’s electronic documents by certifying authorship and the integrity and status of the document itself.

Organizations choose electronic signatures for many reasons.  Among them:

  • Workflow Efficiency - It’s faster for someone to click a button or enter a password than to route a document to them through interoffice mail or courier.
  • Save Money - By going electronic, you eliminate the cost of paper, printing, and courier services.
  • Document Integrity – Organizations publish vast amounts of material to the internet, but are now becoming increasingly concerned about what happens to those documents in the wild.  It’s critical to reputations and revenue that documents are not modified to create a false or fraudulent impression of the organization.

You’ll notice that many of these reasons mirror those that accompanied the rise of the electronic document and form in the first place.  This is not accidental — electronic signatures are a natural extension of the movement to electronic documents.  Many companies have gone fully electronic only to come to the signature step and require customers to print out documents which are signed in wet ink and then sent via the mail to be re-entered into a system. This is neither efficient, nor timely, nor a good use of resources.  Electronic signatures, at their core, represent a vital way to leverage a company’s assets and increase savings based on key technology investments.

Adobe supports all of the electronic signatures described above via our LiveCycle® ES suite as well as our Adobe® Acrobat® and Adobe Reader® client software packages.  Adobe’s Security Partner Community plays an essential role as well, supplying key components for electronic signature solutions.  Adobe is also a member of the Electronic Signatures and Records Association, a new organization which seeks to expand knowledge on both electronic signature and records and also play an active role in public policy on these topics.

In our next ‘tutorial’ entry, we’ll explore the question of assurance in electronic signatures.

June 5, 2007

How to enable FIPS mode in Acrobat and Reader 8.1

The FIPS 140 standard is applicable to all U.S. Federal agencies that use cryptographic-based security systems to protect sensitive information in computer and telecommunication systems as defined in Section 5131 of the Information Technology Management Reform Act of 1996, Public Law 104-106.

Version 8.1 of Adobe Acrobat and Adobe Reader on Windows provide a FIPS mode to restrict data protection to FIPS 140-2 approved algorithms (RSA/AES/SHA) using the embedded RSA BSAFE Crypto-C 2.1 encryption module.

Note the following restrictions in FIPS mode:

* You can use public key certificates or Adobe LiveCycle Rights Management to secure the document, but you cannot use password encryption to protect the document. You can still open and view documents that are protected with non-FIPS compliant algorithms, but you cannot save any changes to the document using password security.

* In FIPS mode, you cannot create self-signed certificates as local PKCS#12 files.

To Configure FIPS mode on your Windows PC

Create a new DWORD Value called bFIPSMode in the registry key:
HKEY_CURRENT_USER/SOFTWARE/Adobe/Adobe Acrobat/8.0/AVGeneral
With DWORD value set to 1 to enable FIPS mode

For information on deploying customized versions of Acrobat and Reader in your organization, read Solutions for IT professionals

April 3, 2007

Acrobat and Reader Security Docs

If you're looking for more details on how digital signatures, encryption, and other security features work in Adobe Acrobat and Adobe Reader, here are some good resources updated for v8:

Document Security User Guide for Adobe Acrobat and Adobe Reader Version 8 (PDF, 2.2 MB)
This document describes how to configure and use the application user interface, register a digital ID for use in Acrobat, and manage other people's public key certificates within your system.

Digital Signature User Guide for Adobe Acrobat and Adobe Reader Version 8 (PDF, 3 MB)
This guide describes the digital signature features of the Acrobat 8.x family of products both for Adobe Acrobat and Adobe Reader Version 8 users as well as for security administrators.

Adobe Acrobat 8 for Microsoft Windows Group Policy and the Active Directory service (PDF, 378KB)
This document describes using Group Policy to deploy Acrobat 8 or Adobe Reader 8 products on a Windows network.

Sharing Acrobat settings and data with FDF files in Acrobat 8 (PDF, 456 KB)
Learn how to use FDF files to exchange data between the Acrobat family of client and server products.

January 21, 2006

Where to go for more security information?

To address the most popular frequently asked question, "Where do I find out more about security?", here are some links you should know:

* Overview of Adobe information security solutions
--- Adobe LiveCycle Policy Server
--- Adobe LiveCycle Document Security Server
--- Adobe Acrobat
--- Adobe Reader
--- Adobe LiveCycle Reader Extensions

* Technical information on
--- Acrobat and PDF Security
--- LiveCycle Policy Server
--- LiveCycle Document Security Server
--- LiveCycle Reader Extensions

* Adobe's security partner ecosystem

* Adobe product security advisories

* Report security vulnerabilities or incidents in Adobe products or services

* Submit a privacy complaint

* Report suspected software pirates

* Enterprise Developer Program for evaluation of Livecycle software

* RSS feed for this blog
* ATOM feed for this blog