• Article

November 2009

Volume 24 Number 11

Digital Signatures - Application Guidelines on Digital Signature Practices for Common Criteria Security

By Jack Davis | November 2009

The transition from paper documents with hand-written signatures to electronic files with digital signatures is moving at a rapid pace. To meet user needs and certification requirements, electronic documents with digital signatures need to provide the same functionality and security that manually signed paper documents offer. This article describes how you, as a software developer, can do just that: design applications that have built-in digital signature functionality that meets the requirements for ISO/IEC 15408 Common Criteria security.

In the realm of documents and data files, digital signatures provide two key features:

  • Identify the originator (the signer) of the document or file content
  • Verify that the signed information hasn’t been altered after the signature was applied

Beyond the basic principle of “What You See Is What You Sign” (WYSIWYS), you and your UI designers need to be aware of several additional security and user considerations when building applications that support digital signatures. You also need to understand the security issues that can affect your products in meeting certification requirements. Certifications, such as those for ISO/IEC 15408 Common Criteria security, provide organizations and users a reliable way of identifying products that have been tested to meet usability and security standards. Increasingly, independent security certification is becoming a prerequisite in purchase decisions.

By the end of this article, you’ll better understand the range of issues associated with digital signatures and the inherent need for clear, accurate and open disclosure to users.

ISO/IEC 15408 Common Criteria Security Certification

Supported by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC), Common Criteria is a suite of methodologies designed to assess and certify the security capabilities of information technology products. Common Criteria security techniques are published in ISO/IEC standards 15408 and 18045.

As of the publication date of this article, the Common Criteria security standard has been approved and adopted by 26 countries. You can find a list of Common Criteria members at commoncriteriaportal.org/members.html.

Office Open XML and Open Packaging Conventions

In 2008, ISO/IEC approved and adopted Office Open XML (OOXML) as an open international standard. The Open Packaging Conventions (OPC) component of OOXML provides an industry standard container-file technology. OPC combines the use of ZIP and XML to enable applications to define file formats that are open and easily accessible. OPC also defines functionality to support digital signatures, metadata properties and content relationships. Access to both application data and OPC elements is provided through a common set of APIs.

Microsoft Word (.docx), Excel (.xlsx) and PowerPoint (.pptx) and the XML Paper Specification (.xps) are examples of OPC-based file formats, and each employs its own unique content organization (schema) that is associated with a specific application. Each OPC file format can also define its own signing policy for digital signatures. A file format signing policy specifies what content items must be signed, what items can optionally be signed and what items shouldn’t be signed as part of the digital signature signing or validation process.

In this article, you’ll learn more about how to validate and display signature information stored with digitally signed electronic documents. These design considerations are based on the digital signature functionality provided by the OPC component of the ISO/IEC 29500 and ECMA 376 Office Open XML standards. Keep in mind that the digital signature signing policies of specific OPC-based file formats might employ only a subset of the signing options described in this article.

Digital Signatures

OPC file formats, such as those described in OOXML, use X.509 certificates and XML Digital Signature (W3C, 2008) technologies to provide two elements of security:

  • Identity repudiation securely identifies the individual or group originating a signature.
  • Content validation securely ensures that all signed content is present and hasn’t been modified in any way after it was signed.

An alteration to any part of a digital signature or to any content signed by the signature will be detected during signature validation, and the user will be notified through an error message that the signature is broken.

Some of the figures in this article are sample notification or status messages for the user. Whether they confirm success or failure of a signature validation or highlight special features that the user should be aware of, they represent the kind of clear and specific wording you should use. Your application defines when and where the user sees these digital signature status messages. 
Digital signature validation is sometimes scheduled to perform automatically whenever a signed document is opened. In this case, the message would be displayed when a user opens the document. If the user is required to perform the digital signature validation manually through a menu selection, you might want to present the signature status in a pop-up dialog box. You and your UI designer have some leeway in the timing and placement of these user messages—just remember to make them as intuitive and easy to understand as possible. 

Signing Categories

Getting your application to report success or failure when verifying the integrity of the signature and the signed content is only the first step in writing a digitally secure program. You also need to consider the various types of content your application will encounter.

In the simplest form of signing, called comprehensive signing, a user applies his or her signature to all the content in a single document. The digital signature and signed content are later verified and then reported as either valid or invalid. Figure 1 is an example of the kind of digital signature status message a user would see.

Figure 1 Sample User Message for Comprehensive Signing

Document elements in four additional categories also need to be considered to avoid confusion or mistaken trust assumptions:

  • Unsigned content
  • Signed content groups
  • Externally referenced content
  • Dynamic content

Comprehensive Signing

Most people are very familiar with signing paper documents and contracts. Individuals initial each page or sign at the end of a document to identify themselves and acknowledge their review, approval and acceptance.

As mentioned earlier, the simplest and most straightforward signing case in a digital document is comprehensive signing. To be classified as this type of signature, all content associated with the document file must meet the following four criteria:

  • All content items are located in a single document package.
  • All content items are static.
  • There are no links or references to external content.
  • All content items in the document package are signed.

For a document to be fully static, content elements can’t contain any dynamically alterable items such as text created through macros or input from external sources. When all content elements in a static document file are signed, both the digital signature and the signed content can be verified with a summary result reporting the signature and associated signed content as either valid or invalid.

In Figure 2, Signature 1 signs document parts r, s and t. A later validation performed on the signature will verify that Signature 1 is still intact and valid, and that each of its associated signed parts (r, s and t) hasn’t been altered after being signed.


Figure 2 Single-Signature Signed Content

Figure 3 illustrates a variation in signing, in which two (or more) signatures are applied to a document. Multiple signatures commonly occur in a review and approval cycle that requires individuals to indicate their approval and acceptance of a document after reviewing it. In this form, each signature can be verified independently along with the associated signed document parts.


Figure 3 Multiple-Signature Signed Content

You can use the following method and property to verify signatures and identify each signer in a signature and signed content validation scenario.

Unsigned Content

Unsigned content is a potential risk to the implied trust association. With paper documents, people commonly sign or initial pages to identify themselves and acknowledge their review and approval. Any pages left unsigned (or added later as unsigned pages) have no formal association or legal weight with the signer.

In digital documents, the validation of a digital signature and its related content verifies that the user can trust both the signature and the associated signed content. Unfortunately, many nontechnical users don’t have the expertise to differentiate between digital signatures, signed content, unsigned content and the container in which the document components are packaged. If only a positive validation of a digital signature and its signed content is displayed, users might incorrectly assume that the validation extends to the entire package, which could include unsigned content that shouldn’t be associated with a trusted signature. Unsigned content has no identifiable source, and it can be added after other components are signed or modified within the document package.

Signature trust associations need to be clear to all users. Users should be made aware of  unsigned content included within any package and provided with a means to clearly distinguish it from trusted signed content. Figure 4 shows the kind of message users should receive to alert them to unsigned content within a valid digitally signed document.

Figure 4 Sample User Message for Unsigned Content

In Figure 5, document parts m and n are signed and can be validated with Signature 1. The same document package also contains unsigned parts x and y that can’t be validated. Parts x and y are independent and not associated, even implicitly, with Signature 1.


Figure 5 Signed Document That Includes Unsigned Parts

You can use the following properties, method and pseudocode to identify packages that contain unsigned parts:

The following pseudocode determines whether any parts in a document package aren’t signed:

PackageDigitalSignatureManager dsm = new PackageDigitalSignatureManager(package);
PackagePartCollection partCollection = Package.GetParts();
foreach (PackagePart part in partCollection)
    foreach (PackageDigitalSignature signature in dsm.Signatures)
    {
        // Search if "part" is included in signature.SignedParts.
        // If "part" is included in signature.SignedParts
        //     then it is a signed part
        //     else it is an unsigned part
    }

Signed Content Groups

A document with multiple signed content groups is another risk for implied trust by association. With paper documents, one individual can sign pages in one section and a second person can sign pages in a separate section. The signature and pages the first individual signs have no formal association with the pages the second individual signs. Likewise, the signature and pages the second individual signs have no formal association with the pages the first individual signs. Only pages cosigned by both individuals represent a joint association. An example of signed content groups is a document in which the body is written and signed by one individual and appendix sections added for reference are written and signed by other individuals.

In some file formats, different content elements could be signed by different individuals. Users need to know that when signatures relate to different content groups they are independent of one another and that each signature and content group must be validated separately. Figure 6 shows a user message that could accompany a document with signed content groups.

Figure 6 Sample User Message for Signed Content Groups

In Figure 7, document parts r, s and t are signed and validated with Signature 1, and document parts x, y and z are signed and validated with Signature 2. The two signatures and their related content groups are independent and not associated with each other even though they are contained in the same document.


Figure 7 Two Signed Groups

In a variation of Figure 7, Figure 8 illustrates a situation in which one or more document parts are cosigned with two or more signatures. While Signature 1 and Signature 2 jointly sign one or more common items (Group C), the signature relationship for Signature 1 with Group A and Signature 2 with Group B remains independent and unassociated with the other. In describing signature information to users, you must explicitly and clearly explain the signature associations of independent and jointly signed content.


Figure 8 Signed and Cosigned Groups

The following properties and pseudocode identify packages that contain multiple signed content groups:

The following pseudocode creates a list of the signed content groups contained in a package:

PackageDigitalSignatureManager dsm = 
   new PackageDigitalSignatureManager(package);
foreach (PackageDigitalSignature signature in dsm.Signatures)
{
    // Add to list(signature.SignaturePart, signature.Signer);
}
// Upon completion the list will contain one entry for each signature
// along with the X.509 certificate that identifies the signer.
// If the list contains more than one entry and different signers,
// the package contains multiple signed content groups.

Securing Against Multiple Signed Content Groups

Multiple signed content groups add complexity to a file format signing policy given that they increase the possibility that someone could add fraudulently signed content to a document with the intent to create a misleading association to an existing signature and content. To secure your application against this threat, you can require a user’s signature to sign the package’s signature-origin-relationships part. (The signature-origin-relationships part is a special file in the package with the name \package\services\digital-signatures\_rels\origin.psdor.rels.) When both the content and the signature-origin-relationships part are signed, any signatures added later will modify the signature-origin-
relationships part, causing the original signature to fail and report the package as invalid.

Externally Referenced Content

Externally referenced content is another potentially improper trust by association scenario. Items within a signed document can contain references to separate, external documents. Unless these other documents are also signed, external references are considered informational and have no formal association with the signed document.

Content accessed through external links and references outside of the document package can change at any time. Ideally, the content being signed shouldn’t contain any links or references to materials outside the document package. Users must be able to clearly identify and understand situations that could involve signing and validating content that includes links and references to external materials. Figure 9 is a sample message indicating externally referenced content within a document.

Figure 9 Sample User Message for Externally Referenced Content

When validating signed content that includes links to external materials, use the following guidelines:

  • Alert users to the presence of references and links to external materials. The notification should clarify that external materials are unsigned and not associated with any signature or signature trust.
  • Provide users with the means to clearly distinguish between signed static content and unsigned external material. For example, when users are validating and viewing signed content, only internal links to other signed content should be shown—external links and references to external content should be hidden.

In Figure 10, document parts r, s and t are signed and can be validated with Signature 1. Document part s, however, contains a link to an internal signed reference for Part t and links to two external references for unsigned Content x and Content y. When validating and describing signature information to users, your application should explicitly and clearly notify the user that links x and y refer to unsigned content that isn’t associated with Signature 1 and is unrelated to other validated content elements (parts r, s and t).


Figure 10 Externally Referenced Content

Identifying  items that refer to external content is dependent on the schema of the specific OPC file format. In the material that accompanies this article, you can find methods, properties and pseudocode that you can use to identify externally referenced content in Microsoft Office file formats for Word (.docx), Excel (.xlsx) and PowerPoint (.pptx).

Dynamic Content

Dynamic unsigned content is also a potential improper trust by association situation. Dynamic alterable content has no analogy in paper documents. Changes or alterations made to a paper document after it is signed legally invalidate the signature. To bear legal weight, modifications to a signed paper document must be reviewed, acknowledged and re-signed by the original signators.

From a signature-trust standpoint, content that can be dynamically added, removed or altered is by its very nature unsignable. Dynamic content, such as text created through the execution of functions and macros, can violate the fundamental principle of WYSIWYS. Dynamic content is commonly produced from functions that insert text for variables such as “today’s date” and “last saved date,” formulas such as Sum, Reference fields or other content created when custom macros are executed.

Dynamic content created as a result of running custom macros can be used maliciously, and it presents a security vulnerability. Executable operations add complexity that makes dynamic content difficult for users to clearly understand. To enforce the WYSIWYS principle, documents that need to be signed shouldn’t include dynamic content and should instead use static content only.

Situations that involve signing and validating documents that contain dynamic content must be openly, clearly and accurately represented to users. When signing a document that contains dynamic content is unavoidable, adhere to the following guidelines:

  • Alert users to the presence of dynamic content. The notification should clarify that the dynamic content is unsigned and unrelated to any signature, and can’t be associated with any level of signature trust.
  • Provide users with the means to clearly identify and distinguish between signed static content and unsigned dynamic content. For example, when validating and viewing signed content, dynamic content should be hidden; the signer should see only the static content originally displayed.

Figure 11 shows a message that warns the user of dynamically computed content.

Figure 11 Sample User Message for Dynamic Content

In Figure 12, document parts r and s are signed and can be validated with Signature 1. However, the document package also contains a piece of dynamic content, Part z, that can’t be signed or validated. Part z is independent and not associated, even implicitly, with Signature 1.


Figure 12 Dynamic Content

Identifying items that contain dynamic content is dependent on the schema of the specific OPC file format. In the online material that accompanies this article, you can find methods, properties and pseudocode that you can use to identify dynamic content in Microsoft Office file formats for Word (.docx), Excel (.xlsx) and PowerPoint (.pptx).

Maintaining Transparency

I’ll say it again: In building applications that support digital signatures, you need to ensure that users are given the same functionality and transparency they would have with a hand-written signature. In addition to being aware of the basic operations of validating signature certificates (X.509) and signed content (cryptographic hashes), you and your UI designers need to be watchful for any situations that might not be intuitively clear to the user.

To summarize, potential issues could arise from the following culprits:

  • Presence and identification of unsigned content
  • Associations between signers of multiple content groups
  • Presence and identification of unsigned externally referenced material.
  • Presence and identification of unsigned dynamic content.

If you don’t exclude such types of content from your application by design, you must openly and accurately present them to the user. Again, the clear and accurate disclosure of digital signature information is a fundamental user need and a requirement for ISO/IEC 15408 Common Criteria security certification.

In the shift to electronic documents, security-conscious groups and individuals will increasingly rely on independent certifications, such as ISO/IEC 15408 Common Criteria. To ensure that your product is positioned to succeed in today’s market, take the time to write a software application that meets the user and security certification standards.

For more information on and links to various standards, see the online material that accompanies this article. You’ll also find an overview of how to identify dynamic and externally referenced content in Microsoft Office documents.

Jack Davis is program manager for the Windows OPC “Packaging” team. Davis is a prior contributor to MSDN Magazine (“OPC: A New Standard for Packaging Your Data,” August 2007) and blogs on the Microsoft Packaging team’s Web site at blogs.msdn.com/opc. He can be reached at jack.davis@microsoft.com.

Web Content for “Application Guidelines on

Digital Signature Practices for Common Criteria Security”

The following links provide information you’ll need to ensure that your applications follow accepted practices for using digital signatures.

Web addresses can change, so you might be unable to connect to the Web sites mentioned here.

Identifying Dynamic and Externally Referenced Content in Office Documents

Identifying elements of dynamic content or externally referenced content is dependent on the schema of the specific OPC file format. This section provides an overview of how to identify dynamic and externally referenced content in Office Open XML (OOXML) file formats for Word (.docx), Excel (.xlsx) and PowerPoint (.pptx). This overview is not all-inclusive – for additional details, refer to ISO/IEC 29500-3 Part 3: Markup Compatibility and Extensibility of the OOXML file format standard.

Office Document Structure

OOXML file formats for Word, Excel and PowerPoint documents employ a common structure for storing content.

  • /[Content_Types].xml file
  • /_rels/ folder
  • /docProps/ folder
  • /documentType/ folder, where /documentType/ is:
    • /word/ for Word documents (.docx)
    • /xl/ for Excel documents (.xlsx)
    • /ppt/ for PowerPoint documents (.pptx)

The [Content-Types].xml part contains the Multipurpose Internet Mail Extension (MIME) types for all parts contained in the package. Two element types can be defined in the content type markup:

  • Default Extension elements define default associations between a part (filename) extension and a specified MIME content type. For example,
<Default Extension="png" ContentType="image/png" />
  • Override PartName elements define associations for specific parts and a specified MIME content type. For example,
<Override PartName="/word/footnotes.xml"
           ContentType="application/vnd.openxmlformats-
                       officedocument.wordprocessingml.footnotes+xml" />

You can use the ContentType attribute for the elements contained in the [Content-Types].xml part to identify the types of items stored in the package ( e.g., Visual Basic project files used in macros).

For additional information on OOXML file format markup, see ISO/IEC 29500 Part 1: Fundamentals and Markup Language Reference.

Word Documents

Fields

Word documents can include fields. Fields can define various objects, such as time, date, document properties, links, references to external content, form fields and so on. Fields used in this manner can provide dynamic content. There are two types of fields: simple and complex.  

The following pseudo-code (p-code) shows how to identify simple-field elements.

Package pkg = Package.open(filepath);
PackagePartCollection parts = pkg.GetParts();
foreach(PackagePart part in parts)
    Stream str = part.GetStream();  // Returns a Stream containing the part content
    if str contains (‘<w:fldSimple *> * </w:fldSimple>’)
    then
       a simple-field exists

Complex fields are described in multiples lines that contain a starting statement, a field description and an ending statement. The following p-code shows how to identify complex-field elements.

Package pkg = Package.open(filepath);
PackagePartCollection parts = pkg.GetParts();
foreach(PackagePart part in parts)
    Stream str = part.GetStream();   // Returns a Stream containing the part content
    if str contains (‘<w:fldChar fldCharType="begin" * />’)
    then
       a complex-field exists

Macros

Macros are another mechanism that can provide dynamic content. Macros are stored in Word documents as Visual Basic files. In Word documents that use macros, the document /[Content_Types].xml file contains a MIME content type reference for a Visual Basic project. The following p-code shows how to identify the use of macros.

Package pkg = Package.open(filepath);
PackagePartCollection parts = pkg.GetParts();
foreach(PackagePart part in parts)
    Stream str = part.GetStream();  // Returns a Stream containing the part content
    if str contains (‘*vbaProject’)
    then
       a macro exists

External References

Word documents can define external references through the use of hyperlinks, subdocuments, OLE objects or mail-merge elements. The following p-code outlines one way to identify if a document uses external references.

Package pkg = Package.open(filepath);
PackagePartCollection parts = pkg.GetParts();
foreach(PackagePart part in parts)
    Stream str = part.GetStream();  // Returns a Stream containing the part content
    if str contains (‘href’ or ‘Hyperlink’ or ‘External’)
    then
       an external reference exists

Excel Documents

Calculated Fields

Within an Excel document, dynamic content is stored in calculated fields whose value is calculated from a function. The following p-code shows how to identify the use of calculated cells in an Excel document.

Package pkg = Package.open(filepath);
PackagePartCollection parts = pkg.GetParts();
foreach(PackagePart part in parts)
    Stream str = part.GetStream();  // Returns a Stream containing the part content
    if str contains (‘<f *> * </f>’)
    then
       a calculated field exists

Date and Time

Date and time information, such as in headers and footers, can be defined to be automatically updated (such as when printing). Dynamic date and time information is defined in the sheet description file \xl\worksheets\sheetX.xml, where X represents the sheet number. The sheet description file can contain header and the footer elements (headerFooter) that define the associated content. Content values &C, &D and &T serve as placeholders for dynamic date and time values. Within the XML markup, &C stands for Current, &D stands for Date and &T stands for Time. &C will always appear before &D and &T, and it’s possible to concatenate both of them building strings like &C&D&T or &C&T&D.

Macros

Similar to Word documents, macros are stored in Excel documents as Visual Basic files. For documents that use macros, the /[Content_Types].xml file will contain a MIME content type reference for a Visual Basic project. The p-code to detect the use of macros in Excel is similar to that for Word. You can use the p-code in the “Macros” part of the preceding “Word Documents” section to detect the use of macros in Excel as well.

External References

External references in Excel are implemented in the same way as in Word. Refer to the “External References” part of the preceding “Word Documents” section for further information on identifying external references in Excel.

Data from Databases and External Data Sources

Excel additionally allows documents to get data dynamically from databases and other external data sources. External data sources are referenced through a connection definition to the external source. Connection definitions are specified in a /xl/connections.xml part that is stored in the package. Here are some possible data source connection types:

  • ODBC-based source
  • DAO-based source
  • File-based source
  • Web query
  • OLE DB-based source
  • Text-based source
  • ADO record set
  • Data set provider (DSP)

For additional information about data sources, see ISO/IEC 29500-1 Fundamentals and Markup Language Reference, section 12.3.4 Connections Part. The following p-code shows how to identify external data connections in an Excel document.

Package pkg = Package.open(filepath);
PackagePart connPart= pkg.GetPart("/xl/connections.xml");
if connPart is not null   // file "/xl/connections.xml" exists
then
   an external data source exists

Volatile Data

Volatile data is an additional way for Excel to connect to an external data source. Volatile dependencies operate by means of a data cache supported through real -time data (RTD). An RTD connection uses a COM object installed on the local machine to provide the desired data to the Excel document. For additional information about volatile data, see ISO/IEC 29500-1 Fundamentals and Markup Language Reference, section 18.15 Volatile Dependencies. The following p-code shows how to identify RTD connections in an Excel document.

Package pkg = Package.open(filepath);
PackagePartCollection parts = pkg.GetParts();
foreach(PackagePart part in parts)
    Stream str = part.GetStream();  // Returns a Stream containing the part content
    if str contains (‘<volTypes *>’)
    then
       volatile data exists

PowerPoint Documents

Date and Time

Slides within a PowerPoint presentation can also contain dynamic date and time elements. Dynamic date and time information can be defined in each slide’s description file \ppt\slides\slideX.xml, where X is the slide number. Slides that contain dynamic date and time content have a date element with its type attribute set to the value datetime. The following p-code shows how to identify the presence of dynamic date and time elements in a PowerPoint document.

Package pkg = Package.open(filepath);
PackagePartCollection parts = pkg.GetParts();
foreach(PackagePart part in parts)
    Stream str = part.GetStream();  // Returns a Stream containing the part content
    if str contains (‘datetime’)
    then
       a date-time element exists

Macros

Similar to Word and Excel documents, macros are stored in PowerPoint documents as Visual Basic files. For documents that use macros, the /[Content_Types].xml file will contain a MIME content type reference for a Visual Basic project. The p-code to detect the use of macros in PowerPoint is the same as that for Word and Excel documents.

External  References

External references in PowerPoint are implemented as they are in Word and Excel.