Getting Started with XML Security

Executive Summary

Meeting security requirements for privacy, confidentiality and integrity is essential in order to move business online. With the growing acceptance of XML technologies for documents and protocols, it is logical that security should be integrated with XML solutions. The XML Security standards define XML vocabularies and processing rules in order to meet security requirements. These standards use legacy cryptographic and security technologies, as well as emerging XML technologies, to provide a flexible, extensible and practical solution toward meeting security requirements.

The XML Security standards include XML Digital Signature for integrity and signing solutions, XML Encryption for confidentiality, XML Key Management (XKMS) for public key registration, location and validation, Security Assertion Markup Language (SAML) for conveying authentication, authorization and attribute assertions, XML Access Control Markup Language (XACML) for defining access control rules, and Platform for Privacy Preferences (P3P) for defining privacy policies and preferences. Major use cases include securing Web Services (WS-Security) and Digital Rights Management (eXtensible Rights Markup Language 2.0 – XrML).

Introduction

Security has always been vitally important in the business world to ensure the integrity of content and transactions, to maintain privacy and confidentiality, and to make sure information is used appropriately. However, in today’s web-based business environment, the means for providing that security have changed. Using physical security no longer works as well as it did in the past when all the computing resources were locked in a central computing room with all jobs submitted locally.

Efforts to create a single pervasive security infrastructure do not scale effectively to the Internet, due to the heterogeneous nature of hardware and software systems and to conflicting administrative, application and security requirements. There is too much to administer, too many applications, too many variations, and too rapid a pace of technology change to design a single infrastructure to meet all requirements effectively. Extensible standards are required that can adapt to changing requirements, that can incorporate new technologies while continuing to work with legacy technologies, and that can be deployed modularly as needed without requiring use of unnecessary portions. These standards should work well together, not replicate functionality, and should fit with new technologies to enable open distributed systems, application integration and content management.

An essential requirement of new security standards is that they work naturally with content created using eXtensible Markup Language (XML). XML is being adopted widely for a growing variety of applications and types of content. It is also forming the basis for distributed system protocols to integrate applications across the Internet, such as Web Services protocols. XML languages are text based and designed to be extended and combined. It should be natural to provide integrity, confidentiality and other security benefits to entire XML documents or portions of these documents in a way that does not prevent further processing by standard XML tools [ XMLRef ]. XML Security therefore must be integrated with XML in such a way as to maintain the advantages and capabilities of XML while adding necessary security capabilities. This is especially important in XML-based protocols, such as XML Protocol (XMLProt, Simple Object Access Protocol, SOAP), that are explicitly designed to allow intermediary processing and modification of messages.

Older security technologies provide a set of core security algorithms and technologies that can be used in XML Security, but the actual formats used to implement security requirements are inappropriate for most XML Security applications. One reason is that these standards use binary formats that require specialized software for interpretation and use, even for extracting portions of the security information. A second reason is that these standards are not designed for use with XML and do not support common XML technical approaches for managing content, such as specifying content with uniform resource identifier strings (URIs) or using other XML standard definitions for locating portions of XML content (like XPath [ XPath ]). In addition, some existing security technologies assume that security-specific software will be integrated with applications to enable security. In practice, this is not always the case due to the details of custom integration.

XML Security addresses these issues by defining a common framework and processing rules that can be shared across applications using common tools, avoiding the need for extensive customization of applications to add security. XML Security reuses the concepts, algorithms and core technologies of legacy security systems while introducing changes necessary to support extensible integration with XML. This allows interoperability with a wide range of existing infrastructures and across deployments.

XML Security reduces barriers to adoption by defining the minimum modular mechanisms to obtain powerful results. By employing existing technologies and enabling use of XML paradigms and tools, XML Security minimizes the need to modify applications to meet security requirements.

This document summarizes the key XML Security technologies and provides an overview of how they fit together and with XML. It should serve as a roadmap and basis for further exploration of the related specifications. Most of the specifications are early in the definition process and are currently undergoing rapid change, so the interested reader is encouraged to turn to the specifications himself to learn the latest details.

This article assumes a basic understanding of XML and security concepts, but in order to provide a starting point, it presents a very brief introduction to those two subjects. This is followed by an overview of the following core XML Security standards:

• Integrity and signatures – XML Digital Signature
• Confidentiality – XML Encryption
• Key Management – XML Key Management Specification (XKMS)
• Authentication and Authorization Assertions – Security Assertion Markup Language (SAML)
• Authorization Rules – XML Access Control Markup Language (XACML)

as well as major XML Security applications:

• Web Services Security – Roadmap and WS-Security
• Privacy – Platform for Privacy Preferences (P3P)
• Digital Rights Management – eXtensible Rights Markup Language 2.0 (XrML)

XML

The XML specification [ XML ] defines a syntax and rules for using tags to structure information. Anyone can define a vocabulary of element tags and attributes to structure information of interest. By following the rules defined in the XML specification, they may create “well-formed” XML, XML that may be processed by common XML tools. They may also explicitly define the structure of the documents they have defined, by creating an XML Schema or Document Type Definition (DTD). This allows documents to be validated.

XML languages created by different people may be combined. If you define a language for expressing addresses, for example, and I define one for purchase orders, I may reuse your address language within my purchase order language. To associate elements with the appropriate schemas and to avoid conflicting elements, XML namespaces may be used. XML namespaces associate tags with unique identifiers (URIs) and may be used to avoid ambiguity [ Namespaces ]. A well-formed XML document may be processed using general XML-aware tools, including parsers that understand the general rules of XML syntax and processing. An advantage is that use of these tools does not depend on the specific vocabulary defined in a particular document. This means that once general tools have been created they may be used for many applications of XML. This allows reuse of tools and training, another advantage of XML.

Many XML languages have already been defined, including XHTML for creating web pages, DocBook for creating technical documentation, RSS for content distribution (syndication), RDF for representing information, MathML for mathematics markup, BRML for business reports, and many others.

The following example shows a language for managing office medical records, including XML elements like <PatientRecord>, <Name> and <Diagnosis>. It also shows the use of an XML Namespace associated with a lab, to allow a <lab:Diagnosis> element that does not conflict with the office <Diagnosis> element.

<PatientRecord  

  xmlns="http://www.medical.org/"  

  xmlns:lab="http://www.lab.org/">  

     <Name>John Doe</Name>  

     <Account>123456</Account>  

     <Visit date="10pm March 10, 2002">  

          <Diagnosis>Broken second metacarpal</Diagnosis>  

          <lab:Diagnosis>  

            <lab:Xray>encoded xray image</lab:Xray>  

          </lab:Diagnosis>  

     </Visit>  

</PatientRecord>

Example 1 – Sample XML Document With XML Namespaces

Security

Security is vital to online business. Technologies designed to meet security requirements have evolved, but the requirements have remained relatively constant. These requirements include Authentication, Authorization, Integrity, Signature, Confidentiality, Privacy and Digital Rights Management and are briefly summarized below:

Authentication – Who is it?

Determine the identity or role of a party attempting to perform some action such as accessing a resource or participating in a transaction. A role may be appropriate to many parties, for example “Human Resources Person”.

Authorization – What can they do?

Determine whether some party is allowed to perform a requested action, such as viewing a web page, changing a password, or committing an organization to a 10 million dollar transaction.

Integrity – Ensure that information is intact

Ensure that information is not changed, either due to malicious intent or by accident. This may be information transmitted over a network, such as from a web browser to a web server, information stored in a database or file system, or information passed in a web services message and processed by intermediaries, to give a few examples.

Signature – Create and verify electronic signatures analogous to handwritten signatures

Produce or verify an electronic signature intended to be the equivalent of a handwritten signature. Such a signature may be used for different purposes such as approval, confirmation of receipt, acceptance or agreement.

Confidentiality – Make content unreadable by unauthorized parties

Ensure that content may only be viewed by legitimate parties, even if other access control mechanisms are bypassed. Confidentiality is generally associated with encryption technologies, although other approaches such as steganography (information hiding) might serve a similar purpose.

Privacy – Limit access and use of individually identifiable information

Personally identifiable information is required by individuals and companies in order to perform services for the individual. An example is a Doctor’s office that requires medical records to track a patient’s health. Privacy relates to control over what is done with this information and whether it is redistributed to others without the individual’s knowledge or consent. Privacy may be managed by a combination of technical and legal means. Confidentiality technology may be used to protect privacy, but cannot prevent inappropriate sharing of information.

Digital Rights Management – Limit use and sharing of content according to license agreements

Ensure that content is used according to license agreements. Generally access rules are incorporated with the content, and enforcement controls are integrated with the clients needed to use the content.

Traditionally, security technologies have required applications to be security or Public Key Infrastructure (PKI) “enabled”. This often involves integrating specialized security code with the application in order to meet security requirements. This created a slow, cumbersome and inflexible customization process. An alternative is to create generic XML tools and generic XML Security and then allow them to be used with a variety of XML applications. This allows generic XML Security filters to be applied to arbitrary content without requiring extensive customization for each application, reducing costs and delay.

XML Security

XML Security standards provide a set of technical standards to meet security requirements. These standards are designed to conform to common XML paradigms. The XML Security standards leverage existing XML standards and also enhance XML standards as follows:

1. The XML Security standards define XML vocabularies for representing security information, using XML technologies, such as XML Schema, for definition. An example is the <KeyInfo> element defined in the XML Digital Signature recommendation for carrying signing or encryption key information. This definition is used in a number of the specifications. The specifications define a shared meaning for the XML vocabularies.

The XML Security standards use other existing XML standards where possible to leverage current XML efforts. For example, XML Digital Signature allows XPath expressions to extract portions of XML for processing (Defined in [ XMLDigSig ] and extended in [ XPathFilter ]).

The XML Security standards are designed to offer the flexibility and extensibility aspects of XML. They allow security to be applied to XML documents, to XML elements and element content, as well as to arbitrary binary documents. They support extending the XML vocabularies through the use of XML namespaces and extensible XML Schema definitions.

XML Security technologies may be applied to end-end security, which is especially important when XML messages are routed through a number of processing intermediaries. Persistent security is associated with the content, rather than with a transport pipe. The security remains with the content. XML Security technologies may be used in conjunction with transport security technologies, such as SSL/TLS, as well.

XML Security technologies reuse existing cryptographic and security technologies whenever possible, without reinventing the wheel. For example, X.509 V3 certificates [ X509Cert ] are used without redefinition when needed – they are simply encoded in a text format. Existing algorithms, such as the SHA1 digest algorithm, are also brought into the XML Security standards world by associating unique URI identifiers with them and defining how they may be used in the XML Security processing models.

The following sections present an overview of the core XML Security standards that are designed to provide XML-compatible technology to meet security requirements. This is followed by some important XML security standards for applying this technology to areas like Web Services and Digital Rights Management.

Core XML Security Standards

The core XML Security standards are:

1. XML Digital Signature for integrity and signatures,


2. XML Encryption for confidentiality,


3. XML Key Management (XKMS) for key management,


4. Security Assertion Markup Language (SAML) for making authentication and authorization assertions, and


5. XML Access Control Markup Language (XACML) for stating authorization rules.

The XML Digital Signature recommendation is particularly important; since, as the first XML Security recommendation, it established an approach as well as some vocabulary shared by the other standards. (The <KeyInfo> element defined in the XML Digital Signature recommendation is an element used by other standards, for example.) Signature functionality is also critical for content integrity, so XML Digital Signatures are also incorporated in the other security standards.

Each standard defines the XML vocabulary necessary for describing the security information required for that aspect of security, as well as the processing rules necessary to understand how to apply the standard.

Integrity & Signatures: XML Digital Signature (XML DigSig)

Purpose and Benefits

Digital signatures are useful for two purposes:

1. To provide persistent content integrity, and


2. To create and verify portable electronic signatures

Persistent integrity enables the user of content to detect unexpected changes to the content, whether malicious or accidental. Unlike a simple checksum, a digital signature associates a digest of the content with the signer of the content using a cryptographic technique. A digest is a digital “fingerprint”, a short fixed-length value that is unique to the content and impractical to determine without the content. Using a cryptographic technique with the digest makes it hard for anyone other than the original signer to change the content without detection. Persistent integrity offers the benefit that content is not only protected in transit, but also when stored and processed.

Electronic signatures offer the digital equivalent of handwritten signatures and may be used for a variety of purposes such as content approval, receipt confirmation, and contract agreement. Using digital signatures makes it possible to move business workflows online, without requiring manual approval steps. This can reduce the delays, costs and inconveniences caused by geographic separation and time zone differences. Digital signatures use cryptographic techniques to construct signatures that are stronger and more portable than other techniques for creating “electronic signatures”.

Features

The XML Digital signature recommendation defines mechanisms to support the full range of digital signature creation and verification, including the ability to sign and verify:

1. Entire XML documents as well as element and element content portions of XML documents,


2. Arbitrary documents, including binary documents,


3. Compound documents including multiple documents and/or XML elements and element contents,


4. Properties to be included with a signature,


5. Counter-signatures (signatures that include other signatures)

In addition, the XML Signature recommendation supports the application of multiple XML Signatures to an XML document or to different sections of a document, supporting a variety of use cases. The XML Digital Signature specification and related specifications (XML Canonicalization) also define techniques so that signature verification can be robust even with variations allowed in XML, such as whitespace. The reason for the concern is that cryptographic algorithms are concerned with exact text, yet XML allows some flexibility. Canonicalization is used to reduce variations so that all XML Security applications can interoperate.

An XML <Signature> element may be handled in different ways, based on the desired application. It may be placed in a document apart from what is signed. This is known as a “detached” signature, and is used when signing non-XML content. When XML content is signed, the <Signature> element may be added to the XML. This is convenient, since signatures may then be bundled within the content and remain embedded with it, making it easy to keep track of them. When placed in an XML document, the <Signature> element may be added to the document being signed under the document element (an “enveloped” signature). In some cases, it is useful to place the content being signed within the <Signature> element, an example being a signature property (an “enveloping” signature).

If a signature is added to the <PatientRecord> as an enveloped signature, for example, the <Signature> element would be a child of the <PatientRecord> as follows:

<PatientRecord xmlns="http://www.medical.org/">   

    <Name>John Doe</Name>   

    <Account> 123456 </Account>   

    <Visit date="10pm March 10, 2002">   

        <Diagnosis> Broken second metacarpal </Diagnosis>   

    </Visit>   

    <Signature xmlns='https://www.w3.org/2000/09/xmldsig#'>   

        ...    

    </Signature>   

</PatientRecord>

Example 2 -  Enveloped Signature

When a signature is added to a document as part of the document, it changes the document. To verify the signature, it is necessary to compare the original document without the signature. The XML Digital Signature recommendation defines a mechanism for removing the <Signature> as part of the verification process. 

Another possibility is to create a new XML document with a <Signature> document element and to place the signed element as a child of the <Signature> element. This is usually reserved for information associated with a signature, such as the purpose of the signature, for example: 

<Signature xmlns='https://www.w3.org/2000/09/xmldsig#'>   

    <SignedInfo> ... </SignedInfo>   

    <SignatureValue> ... </SignatureValue>   

    <Object>   

        <SignatureProperties>   

            <p:Purpose xmlns:p="http://www.myexample.com/schemas">   

              Approval   

            </p:Purpose>   

        </SignatureProperties>   

    </Object>   

</Signature>

Example 3 - Enveloping Signature



Key Concepts

The following concepts are central to understanding XML digital signatures:


	
A signature is only valid if the signed content has not changed. This content is represented using a short, fixed-length digest, designed to change if the content changes. Thus a signature will only be valid if a digest used to create a signature is the same as a digest used to verify it later. A verifier can create a digest to see if it is the same. 

	

An XML <Signature> element is an XML structure that contains a cryptographic signature value in a <SignatureValue> element as well as an XML structure that has been signed, the <SignedInfo> structure. This means that the contents of the <SignedInfo> structure should not change for the signature to be valid.

The signer creates a <Reference> for each item to be included in a signature. Each <Reference> includes a digest of the item and a unique identifier (URI) for the item. It also identifies how to recreate the digest, specifying the algorithm and other necessary information. Each Reference is part of the <SignedInfo> structure.

To verify a signature, a recipient must validate each <Reference> by independently generating the same digest for the item. The verifier may use the URI to aid locating the item, and the algorithm information to know how to generate the digest. If the item has not changed, the digest should be the same.

A reference may refer to anything using a URI, including non-XML content such as image and text files. It is not required to obtain the item using the URI, but it is often useful. A special form of URI may be used to refer to XML elements within the same document as the signature, allowing signatures to be transferred along with XML content to be signed.

A <Reference> may specify one or more transforms to be applied to an item before creating the digest. One use is to sign parts of an XML document that are known not to change – such as boilerplate for example. This may be done by defining transform to extract the portion of the document to be signed, using standard XML XPath expressions for example.

Digest algorithms require content to be exactly the same to produce the same digest. Even a minor change that does not change the meaning, such as adding an extra space, will invalidate the digest. XML, on the other hand, allows some variation in the syntax of the XML text without changing the document. In other words, two XML documents may be considered the same even if they do not have the exact same text. For example, one XML document may use single quotes for an attribute and another double quotes. These are the same to an XML parser, but very different to a digest algorithm. There is an entire list of such potential issues for digests. To get around this problem, a Canonicalization transform may be used, one that converts any XML document to a form using a single set of rules, such as always using a certain type of quote for attributes.

Examples

Once created, an XML Digital Signature may be stored separately from the signed content (a detached signature) or embedded within the XML content that was signed (enveloped signature). In fact, signed content may also be placed within a signature itself (enveloping signature). To continue with the earlier PatientRecord example, suppose that the entire PatientRecord is to be signed by the Doctors office, and the signature is to be maintained as part of the PatientRecord. This would produce the following result, showing the layout of an XML Signature:

<PatientRecord xmlns="http://www.medical.org/">    

  <Name>John Doe</Name>    

  <account id="acct">123456</Account>    

  <Visit date="10pm March 10, 2002">    

    <Diagnosis>Broken second metacarpal</Diagnosis>    

    <lab:Diagnosis>    

      <lab:Xray>xhzhez</lab:Xray>    

    </lab:Diagnosis>    

  </Visit>    

  <Signature xmlns='https://www.w3.org/2000/09/xmldsig#'>    

        

    <!-- the SignedInfo element and all it contains    

         is what is signed -->    

    <SignedInfo>    

          

      <!-- Canonicalization is used to ensure    

           that XML is handled consistently    

           by different XML processors    

           in light of white space and other    

           variations. -->    

      <CanonicalizationMethod algorithm="URI for algorithm" />    

          

      <!-- the SignatureMethod is protected    

           by the signature, avoiding substitution    

           attacks and defines how the signature    

           is created  -->    

      <SignatureMethod    

Algorithm="https://www.w3.org/2000/07/xmldsig#rsa-sha1" />    

          

      <!-- each item to be signed, XML document,    

           portion of XML document or arbitrary    

           content is represented using a    

           Reference. Each Reference contains    

           a digest of the item, a URI to    

           refer to the item, and possibly     

           transforms to apply to the item    

           before creating the digest  -->    

      <Reference URI="">    

        <Transforms    

Algorithm="https://www.w3.org/TR/2000/WD-xml-c14n-20000710" />    

        <DigestMethod    

Algorithm="https://www.w3.org/2000/07/xmldsig#sha1" />    

        <DigestValue>    

          Short, fixed-length "fingerprint" of referenced item     

        </DigestValue>    

      </Reference>    

    </SignedInfo>    

    <SignatureValue>    

      encoded output of signature algorithm    

    </SignatureValue>    

        

    <!-- Optional KeyInfo used to convey key    

         information needed to verify    

         signature -->    

    <KeyInfo>    

      <KeyName>Sally Smith's Integrity Key</KeyName>    

    </KeyInfo>    

        

    <!-- optional Object to allow additional    

         information to be associated with    

         signature, such as meta information    

         for example (time and purpose of    

         signing) -->    

    <Object>    

      <SignatureProperties>    

        <p:Purpose xmlns:p="http://www.myexample.com/schemas">    

          Integrity    

        </p:Purpose>    

      </SignatureProperties>    

    </Object>    

  </Signature>    

</PatientRecord>

Example 4 - Detailed XML Signature Example

Note that there is a single reference with URI "", meaning "this document". If only the <Account> element were to be signed, it could be referenced using the id attribute value, as follows: <Reference URI="#acct">. If there was no id attribute (perhaps signing wasn't anticipated), an XPath expression could be used, producing the following <Reference>: 

<Reference URI="">    

    <Transforms>    

        <Transform    

Algorithm="https://www.w3.org/TR/1999/REC-xpath-19991116">    

            <XPath>    

                /PatientRecord/account     

            </XPath>    

        </Transform>    

        <Transform    

Algorithm="https://www.w3.org/TR/2000/WD-xml-c14n-20000710" />    

    </Transforms>    

    <DigestMethod    

Algorithm="https://www.w3.org/2000/07/xmldsig#sha1" />    

    <DigestValue> kjsdf </DigestValue>    

</Reference>

Example 5 - Reference Transform Using XPath



Confidentiality: XML Encryption (XML Enc)

Purpose and Benefits

The XML Encryption recommendation defines an XML vocabulary and processing rules enabling confidentiality to be applied to a variety of content. XML Encryption serves the purpose of maintaining the confidentiality of information, both while in transit as well as when stored. Other technologies for confidentiality such as secure sockets layer (SSL)/transport layer security (TLS) or virtual private networks (VPNs) only provide confidentiality while the information is in transit, not while it is stored at a server. 

The owner of content may encrypt it to make it confidential. This will make the content unintelligible until it is decrypted. Encryption is generally performed using symmetric key encryption, since this is an efficient technique even for large documents. Symmetric key encryption uses the same key for both encryption and decryption. To send confidential information to a receiver, the sender must also share the symmetric key with the recipient but not anyone else. This can be difficult without person to person contact. 

To avoid this problem and make it easier to share confidential content with a number of people, asymmetric or public-key cryptography was designed. Public key cryptography uses a matched pair of keys, one for encryption and one for decryption. This allows the sender to encrypt using the recipient's public key, a key that can be shared widely. Decryption requires use of the recipient's private key, known only to them. This helps address the difficulty of establishing confidential communication. Because public key cryptography is less efficient than symmetric cryptography, they are typically used together. The symmetric key is used to encrypt the content, and then the symmetric key is encrypted using public key cryptography. Both the encrypted content and encrypted symmetric key are then sent to the recipient. 

To summarize, the sender may send content confidentially using the following steps: 


	
Encrypt the content using a symmetric key 


	
Encrypt the symmetric key using the recipient's public key 


	
Package the encrypted content, encrypted key and necessary algorithm information together 


	
Send the package to the recipient 



The recipient may obtain the original content using the following steps: 


	
Unpack the package to obtain the algorithm information, the encrypted symmetric key and the encrypted content 


	
Decrypt the symmetric key with their private key 


	
Decrypt the content with the symmetric key 



Features

The XML Encryption recommendation defines the framework and processing rules for XML encryption and decryption. It defines an XML vocabulary for packaging all the information needed to process encrypted content, such as encryption algorithm and parameters, information about keys, and encrypted content. The XML Encryption recommendation supports the following features: 


	
XML and non-XML content may be encrypted, giving broad applicability to the recommendation. 

	

Confidentiality may be applied at a fine level of granularity to XML content. It may be applied to XML elements and XML element content as well as entire XML documents. This is valuable for securing portions of XML Protocol messages to be routed through intermediary processors.

XML Encryption produces well-formed XML from well-formed XML. This allows portions of XML content to be encrypted yet subsequently processed by XML tools.

XML Encryption is compatible with and may be used in conjunction with XML Digital Signatures.

XML Encryption allows for encryption of a symmetric key that may be packaged with encrypted content.

XML Encryption supports a variety of encryption algorithms and techniques.

Key Concepts

1. When an XML element or element content is encrypted, it is replaced by an <EncryptedData> element.

When non-XML content is encrypted, the result is a new XML document containing an <EncryptedData> element.

An <EncryptedData> element may include a Type attribute to assist the recipient in decrypting it. This Type may indicate that an XML element or element content was encrypted, or give the type of other information, such as images for example. This is done using an existing standard for mail attachments, known as MIME types.

The <EncryptedData> element defines the algorithm used for encryption, provides the encrypted content, and may include information necessary to determine the key needed for decryption.

The symmetric key used to encrypt content may be conveyed in an <EncryptedKey> element.

XML Encryption supports the selection of appropriate encryption algorithms and defines XML identifiers for common cases and may be extended for others.

Definitions for identifying key information are based on XML Digital Signature definitions and extended.

User-defined properties may be associated with an encrypted element, such as a timestamp or log reference.

The actual cipher text, the result of encryption, is specified using a <CipherData> element. This may contain the actual encrypted data within a <CipherValue> element, or a URI reference to encrypted data that is stored elsewhere (<CipherReference>). A reference is useful when the encrypted data is large and not needed by most parties, such as processing intermediaries.

An important issue in XML Security is the interaction of XML Digital Signatures and XML Encryption. Suppose you receive a document with an XML Signature and an <EncryptedData> element as in the following:

<PatientRecord     

  xmlns="http://www.medical.org/"     

  xmlns:lab="http://www.lab.org/">     

    <Name> John Doe </Name>     

    <Account> 123456 </Account>     

    <EncryptedData Type='element'>     

        ...      

    </EncryptedData>     

    <Signature>     

        <SignedInfo>     

            <Reference URI="">     

                ...     

            </Reference>     

        </SignedInfo>     

    </Signature>     

</PatientRecord>

Example 6 - Encrypted and Signed Document

In this case, the signature indicates that it applies to the entire <PatientRecord> document, since the <Reference> URI is "". This raises the question: did the signature or the encryption come first? This is important to know, since a signature can only be verified as correct if the content has not changed. If a portion of the document was encrypted after signing, the signature will not verify unless the encrypted portion is decrypted first. Knowing the order of encryption and decryption is essential in order to know how to verify the signature. The XML Encryption Transform recommendation [ XMLDecTrans ] defines a solution. When signing, the signer must identify which <EncryptedData> elements are present as part of the signature. This allows a signature verifier to explicitly know which <EncryptedData> elements must be decrypted before verifying a signature. 

There are additional security issues raised by XML Encryption, particularly those of "known plaintext attacks". If it is known that particular text was encrypted, such as an element (such as <Visit>, for example) it can make it easier to break the encryption. Because XML is verbose, and the names of elements may be known from the schema definition of the XML vocabulary, it is more likely that plaintext attacks are possible. As a result, additional care must be taken in choosing the encryption algorithms and their parameters to prevent use of this information from removing confidentiality.

Examples

Use of both <EncryptedData> and <EncryptedKey> elements may be summarized using the previous example where the account information is encrypted for confidentiality. Additional information on the EncryptedData and EncryptedKey portions of this example are explained in the XML Encryption candidate recommendation [ XML Enc ]: 

<PatientRecord     

  xmlns="http://www.medical.org/"     

  xmlns:lab="http://www.lab.org/tests">     

  <Name>John Doe</Name>      

  <EncryptedData     

Type='https://www.w3.org/2001/04/xmlenc#Element'     

xmlns='https://www.w3.org/2001/04/xmlenc#'>     

    <EncryptionMethod     

Algorithm='https://www.w3.org/2001/04/xmlenc#3des-cbc'/>      

    <ds:KeyInfo     

xmlns:ds='https://www.w3.org/2000/09/xmldsig#'>      

      <EncryptedKey Id='EK'     

xmlns='https://www.w3.org/2001/04/xmlenc#'>     

        <EncryptionMethod     

Algorithm="https://www.w3.org/2001/04/xmlenc#rsa-1_5" />      

        <ds:KeyInfo     

xmlns:ds='https://www.w3.org/2000/09/xmldsig#'>      

          <ds:KeyName>     

            Dr Kutter's public key pair     

          </ds:KeyName>     

        </ds:KeyInfo>       

             

        <CipherData>     

          <CipherValue>xyzabc</CipherValue>     

        </CipherData>      

             

        <CarriedKeyName>     

          Dr Kutter's symmetric key     

        </CarriedKeyName>     

      </EncryptedKey>      

           

      <ds:KeyName>     

        Dr Kutter's symmetric key     

      </ds:KeyName>     

    </ds:KeyInfo>      

         

    <CipherData>     

      <CipherValue>a17xj2z</CipherValue>     

    </CipherData>     

  </EncryptedData>      

       

  <Visit date="10pm March 10, 2002">     

    <Diagnosis>     

      Broken second metacarpal     

    </Diagnosis>     

         

    <lab:Diagnosis>     

      <lab:Xray>xhzhez</lab:Xray>     

    </lab:Diagnosis>     

  </Visit>      

       

  <Signature xmlns='https://www.w3.org/2000/09/xmldsig#'>      

    <SignedInfo>      

      <SignatureMethod     

Algorithm="https://www.w3.org/2000/07/xmldsig#rsa-sha1" />      

           

      <!-- signature on entire PatientRecord     

           before encryption is default interpretation -->      

      <Reference URI="">     

        <Transforms     

Algorithm="https://www.w3.org/TR/2000/WD-xml-c14n-20000710" />      

        <DigestMethod     

Algorithm="https://www.w3.org/2000/07/xmldsig#sha1" />     

        <DigestValue>kjsdf</DigestValue>     

      </Reference>     

    </SignedInfo>     

         

    <SignatureValue>xjksdasd</SignatureValue>     

         

    <KeyInfo>     

      <KeyName>Sally Smith's Integrity Key</KeyName>      

    </KeyInfo>      

  </Signature>      

</PatientRecord>

Example 7 - Detailed XML Encryption Example



Key Management: XML Key Management Specification (XKMS)

Purpose and Benefits

The XML Key Management Specification (XKMS) [ XKMS ] defines protocols for Public Key management services. Public Key management includes the creation of a public and private key pair, the binding of this key pair with identity and other attributes, and the representation of this key pair in different formats, such as by key name, digital certificate or key parameters, to give some examples. Public key technology is an essential part of XML Digital Signatures, XML Encryption and other security applications. When signing, the private key is used to sign and the public key is used to verify signatures. When encrypting, the public key is used to encrypt and the private key is used to decrypt. In either case the private key must be maintained under control of the owner and the public key may be shared with others. XKMS is designed to help manage the sharing of the public key to enable signature verification and encrypting for recipients. 

Public Key management usually requires a registration step in which the key pair is generated and some sort of token is issued to associate the public key with the identity and other attributes of the owner. This registration step usually incorporates some sort of due diligence to reduce the risks of associating the public key incorrectly, since people will rely upon the key pair later. Management also includes the ability to revoke the association of information with the key pair should circumstances change, such as the theft of the private key or a change in the owner's attributes (no longer an employee, for example). Likewise, information bound to the key pair may be updated. Traditionally, such bindings were managed using X.509 Digital Certificates, specialized protocols and public key infrastructures. XKMS defines XML message formats to support requests and responses for public key management, including registration, revocation and updates. This eliminates the need for applications to support other specialized public key registration and management protocols. 

Once registration is complete, a public key pair may be used for signing and verification or encryption and decryption. The <KeyInfo> element defined in the XML Digital Signature recommendation may be used to provide information to the recipient of a digital signature or encrypted data block about the key needed to process that content. This information may take on a number of different forms, such as a key name, a digital certificate containing the public key, a set of key parameters, or a URI indicating where to obtain the public key. Given the variety of choices for providing information about a key to a recipient, it may be hard for an application to process and locate a key. In addition to the difficulty of anticipating all formats, some, such as X.509 certificates, require special cryptographic code and logic for processing. XKMS provides an XML message format to allow this processing to be performed by a service which will sort through the various options, determine the one that was used, and provide the key information to the recipient in a useful form. 

Features

The XML Key Management Specification (XKMS) defines three specifications: 

• XML Key Registration Service Specification (XKRSS),
• XML Key Information Service Specification (XKISS)
• Protocol Bindings

These specifications define the XML request and response messages necessary for registering and managing information associated with public keys and for ensuring that security requirements are met.

The registration service supports the binding of information with a public key pair, either one generated by the server or by the client. The binding associates information with the key pair, creating a <KeyBinding> element. This binding may have a validity period associated with it and may be reissued or revoked. The private key associated with a key binding may also be backed up recovered if the local copy is destroyed (as when an operating system requires reinstallation).

The key information service allows a client to request information associated with a <KeyInfo> element. This may include:

1. Locate – Resolve the <KeyInfo> element to return requested key information


2. Validate – Locate key information and provide an assertion on the validity of the binding to the key pair.

A key information request may specify the form of key information to be returned. For example, it may request that a <KeyName> and <KeyValue> be determined from a <KeyInfo> element. As part of this process, the server may perform validation to assert the validity of the binding to the key.

The Protocol Bindings specification defines mechanisms for meeting security requirements, including mechanisms to ensure message confidentiality, integrity, and security. This includes the following definitions:

• A two phase protocol to avoid replay attacks
• Pending response protocol
• Use of payload security
• Use of transport security such as SSL/TLS
• Use of Web Services security (see below)

Key Concepts

Important points about the XKMS specification are:

1. This specification defines XML protocol messages to convey key registration and information requests to a trust server and to convey responses from the server. The specification defines a binding of these messages to the XML Protocol (SOAP) and defines the relationships among the messages using the Web Services Definition Language (WSDL).

<ds:KeyInfo> processing is delegated to the trust service by the client, minimizing the complexity of the client. How the trust service is implemented is dependent on the service, but acting as a front-end to a public key infrastructure (PKI) is one possibility.

The XML Key Information Service Specification (XKISS) includes online status functionality equivalent to that in traditional PKI OCSP protocols as part of the Validate functionality.

Registration supports the requirements of smart card manufacturing, including bulk processing and pending responses.

The specification supports the use of XML Digital Signatures for message integrity and authentication. The specification also defines other authentication mechanisms, support for proof of key ownership and other security functionality.

A Locate or Validate request may include a <KeyInfo> element and <RespondWith> element in the request. The <RespondWith> element is used to specify what the <KeyInfo> element is to be resolved to, possibly more than one item. For example, the request <KeyInfo> might contain an X.509 certificate and the <RespondWith> might indicate that the KeyName and KeyValue are to be returned. Possibilities include KeyName, KeyValue, and Certificate, Certificate Chain (collection of certificates needed to trace a signature back to a trusted party) among the possibilities outlined in the specification.

A <KeyBinding> element is used to associate information with a key. This is what is returned in a Locate or Validate response. Every <KeyBinding> includes a <ValidityInterval> (NotBefore, NotOnOrAfter) and may also include <KeyInfo>, <ProcessInfo> (opaque data), <KeyUsage> and <UseKeyWith> elements.

Key usage definition is deliberately limited to Encryption, Signing and Key Exchange.

A <KeyBinding> <UseKeyWith> element defines which application and application entity the key is intended for. For example, a key may only be appropriate for authentication of an SSL server. In this case, the application is HTTPS, and the identifier is the URL of the server. Applications listed in the specification include S/MIME, HTTPS, SMTP, IPSec, PKIX and others.

Examples

A client might generate a key pair and wish to register it with a trust server, as in this example. (Complete examples are provided with the XKMS specification):

<RegisterRequest      

  xmlns:ds="https://www.w3.org/2000/09/xmldsig#"      

  Service="http://test.xmltrustcenter.org/XKMS"      

  RequestId="hZMRGyATbUL4H7rYOanR6Q=="      

  xmlns="https://www.w3.org/2002/03/xkms#">      

  <RespondWith>X509Cert</RespondWith>      

  <Prototype Id="tX4Y83grmj/eIVoeYNuTNg==">      

    <KeyInfo>      

      <ds:KeyValue>      

        <ds:RSAKeyValue>      

          <ds:Modulus>      

            zvbTdKsTprGAKJdgi7ulDR0eQBptL...      

          </ds:Modulus>       

          <ds:Exponent> AQAB </ds:Exponent>       

        </ds:RSAKeyValue>      

      </ds:KeyValue>      

    </KeyInfo>       

          

    <KeyUsage>Signature</KeyUsage>      

    <UseKeyWith      

      Application="urn:ietf:rfc:2633"      

      Identifier="alice@alicecorp.test" />       

  </Prototype>       

  <Authentication>      

    <ProofOfPossession>       

      <ds:Signature>      

        signing with the private key      

        demonstrates possession of it      

      </ds:Signature>       

    </ProofOfPossession>      

  </Authentication>      

</RegisterRequest> 

Example 8 - XKMS Register Request

The server responds with the information requested with <RespondWith>: 

<RegisterResult xmlns:ds="https://www.w3.org/2000/09/xmldsig#"       

                Service="http://test.xmltrustcenter.org/XKMS"       

                ResultMajor="Success"       

                RequestId="hZMRGyATbUL4H7rYOanR6Q=="       

                ResponseId="k9gyjDdhLLV1vbF7RzJjIw=="       

                xmlns="https://www.w3.org/2002/03/xkms#">      

    <KeyBinding Id="LVrJqd26QzO9GWJD0usQwg==">      

        <KeyInfo>      

           <KeyName>Sally Smith key</KeyName>      

        </KeyInfo>      

        <KeyUsage>Signature</KeyUsage>      

        <UseKeyWith Application="urn:ietf:rfc:2633"       

        Identifier="alice@alicecorp.test" />      

    </KeyBinding>      

</RegisterResult>

Example 9 - XKMS Register Response

A client could request an identity validation: 

<ValidateRequest xmlns:ds="https://www.w3.org/2000/09/xmldsig#"       

                 xmlns:xenc="https://www.w3.org/2001/04/xmlenc#"       

                 Service="http://test.xmltrustcenter.org/XKMS"       

                 RequestId="zzjmNi9YL+dnkRXzDoqPoQ=="       

                 xmlns="https://www.w3.org/2002/03/xkms#">      

    <RespondWith>KeyName</RespondWith>      

    <RespondWith>KeyValue</RespondWith>      

    <RespondWith>Multiple</RespondWith>      

    <KeyBindingQuery Id="T/QMi7gGuKCcNWPi120A/w==">      

        <Keyoo	

Frequently Asked Questions (FAQs) on XML Security