Dev2Dev > Articles

---

Securing ebXML: Part 1, Message Exchange

by Blake Dournaee
01/05/2005

Abstract

This is the first of two articles about security for ebXML, with a focus on the message layer. For a general introduction to ebXML concepts with a look at the overall use case for a generic ebXML interaction based on functional phases, see An Introduction to ebXML. In this article, the emphasis will be on explaining the message-level security and security policy mechanisms for ebXML messaging (ebMS).

This article begins with a summary review of message layer security benefits. The distinction between message layer security and transient socket-level security will be discussed briefly. The concepts presented in this summary are paramount to understanding the remainder of the discussion about ebMS message-layer security. Following the summary review is an in-depth examination of how security policy is described for the ebXML messaging layer through the use of the Collaboration Protocol Profile (CPP) and Collaboration Protocol Agreement (CPA).

What is Message Layer Security?

The majority of real-world ebXML messages have unique XML-based, message-level security requirements including digital signatures, non-repudiation, data privacy, and content-borne threat protection. These message-level mechanisms provide protection over and above transient application layer security such as SSL/TLS. Real-world ebXML deployments utilize both application-level security mechanisms and socket-level transport mechanisms.

The message-level security standards employed by ebXML rely on expensive XML Security operations such as XML Signature and XML Encryption. While both standards employ expensive cryptographic processing, the time spent performing XML processing within these standards far overshadows the cryptographic operations due to an expensive mix of XML parsing, transformation, schema validation, and message canonicalization. This article suggests that significant performance and security benefits can be realized by decoupling the XML and cryptographic processing to a secure, hardened XML gateway appliance (XML firewall).

Newcomers to the security space are often puzzled by the need for message layer security in light of the ubiquity of inexpensive and trusted transport-level mechanisms such as SSL/TLS or VPN technology. The term message layer security refers to persistent security properties applied to any sort of protocol-based message exchange, whether it is over HTTP, SMTP, FTP, or others. In the case of message layer security, the message unit, whether it is an XML document or binary attachment, is encrypted, signed, or both. For XML documents, the specific operation can be highly granular due to the structured nature of XML.

Applying message-level security to payloads solves security problems that transport-level mechanisms are not well designed to handle, such as security property persistence. For example, in an SSL connection, the security properties are applied to the socket, and any data written to or read from that socket is encrypted and authenticated. When the socket is torn down, however, there is no way to tell whether a piece of data that came through that socket has had security properties applied to it. Furthermore, in multihop path scenarios, the data remains in the clear at any point where the SSL connection has been terminated. This is known as the SSL security "gap" as shown in Figure 1.

Figure 1. SSL security gap

Message-level security mechanisms are used heavily in ebXML and other XML-based web services protocols. They help provide persistent non-repudiation, data privacy, and sender authentication for long-running transactions or transactions that span multiple domains in a multihop fashion. Other uses for message layer security include data at rest protection, where data is signed and encrypted before it is inserted in a database.

CPP Security Policy

To understand how a security policy is described by a CPP, it is necessary to examine the outer structure of a CPP instance. A CPP instance is defined by five direct child elements, shown in Listing 1. A simple BNF grammar is used to describe the cardinality of the elements. A plus (+) means one or more, a question mark (?) means zero or one, and an asterisk (*) means zero or more. No indicator means exactly one.

Listing 1. The Collaboration Protocol Profile (CPP) XML Structure

<CollaborationProtocolProfile>
  (<PartyInfo>)  +
  (<SimplePart>) +
  (<Packaging>)  +
  (<Signature>)  ?
  (<Comment>)    *
</CollaborationProtocolProfile>

Not all the elements shown in Listing 1 are of interest to us. The majority of the security policy information for ebMS message-level security is found within the <PartyInfo> element and <Packaging> elements. The reader may have noticed a <Signature> element in the example shown in Listing 1. This is an optional W3C XML Signature that may be provided by the creator of the CPP for authentication mechanisms. For the CPP, there is generally only a single signer, but the CPA may have additional signers once derived. It is important to note that for authentication purposes, ebMS utilizes XML Signature for both the CPP itself and the actual messages exchanged. The next two sections describe the policy information embedded within the <PartyInfo> and <Packaging> elements.

The <PartyInfo> Element
The <PartyInfo> element describes the implementation details for a specific trading partner. A CPP may have many <PartyInfo> elements because a large enterprise may be represented by many facets with different roles and transactions. The structure of the <PartyInfo> element is shown in Listing 2.

Listing 2. The <PartyInfo> Structure

<PartyInfo>
  (<PartyID>)  +
  (<PartyRef>) +
  (<CollaborationRole>) +
  (<Certificate>) +
  (<SecurityDetails>) +
  (<DeliveryChannel>) +
  (<Transport>) +
  (<DocExchange>) +  
  (<OverrideMshActionBinding>) *
</PartyInfo>

Three important subelements that help describe the security policy for an ebXML transaction include the <Certificate>, <CollaborationRole>, and <DocExchange> elements. The <SecurityDetails> element is currently used as an extension point and not to convey the immediate policy. The <Certificate> element is a central place in the CPP that lists the X.509 certificates containing the public keys used in the ebXML transaction. This structure is general and can be referenced from other places in the CPP. The <CollaborationRole> element has children that help describe legacy security policy items beyond the messaging layer. This might map to specific PKI implementations used on opaque (for example, non-XML) payloads within an ebXML conversation.

Finally, the <DocExchange> element lays the groundwork for the actual runtime ebMS security policies. This element contains important information for the sender and receiver security policies. Most notably it defines three important subelements: <SenderNonRepudiation>, <SenderDigitalEnvelope>, and <NamespaceSupported>. A visual representation of the content hierarchy is shown in Listing 3.

Listing 3. The <DocExchange> Hierarchy Snapshot

<PartyInfo>
  <DocExchange>
    <ebXMLSenderBinding>
      <SenderNonRepudiation>
      <SenderDigitalEnvelope>
      <NamespaceSupported>

The <SenderNonRepudiation> element defines the parameters used in the computation of the XML Signature including the protocol, which is generally a W3C XML Signature, the specific hash function used to form the digest (such as SHA-1), the actual signature algorithm (for example, RSA or DSA), and a reference back to the X.509 certificate used for the signature. In this case, a reference can be made back to the <Certificate> element that is a direct child of the <PartyInfo> element.

The <SenderDigitalEnvelope> refers to the encryption mechanism used. The term digital envelope derives from the fact that with message-level security, as used in ebXML, it is often more efficient to encrypt a payload using a fast symmetric cipher and then rely on the public key of the recipient to encrypt the symmetric key. In this sense, the original symmetric key is enveloped with another key. For ebXML, the recommended mechanism for digital envelopes is XML Encryption, but binary mechanisms such as S/MIME and PGP/MIME may also be specified. The <SenderDigitalEnvelope> element specifies the protocol type, version, and encryption algorithm used.

The final element, <NamespaceSupported>, can be used to disambiguate between different versions of the XML Security specifications, such as XML Signature and SAML. The job of the <NamespaceSupported> element is to directly specify the specific namespace (and therefore the version) of a particular security specification. An example of the <SenderNonRepudiation> and <SenderDigitalEnvelope> elements is shown in Listing 4.

Listing 4. Example Security Policy Elements

<SenderNonRepudiation>  
  <NonRepudiationProtocol>
    http://www.w3.org/2000/09/xmldsig#
  </NonRepudiationProtocol>

  <HashFunction>
    http://www.w3.org/2000/09/xmldsig#sha1
  </HashFunction>

  <SignatureAlgorithm>
    http://www.w3.org/2000/09/xmldsig#dsa-sha1
  </SignatureAlgorithm>

  <SigningCertificateRef certId="CompanyA_SigningCert"/>
</SenderNonRepudiation> 

<SenderDigitalEnvelope> 
 <DigitalEnvelopeProtocol version="2.0">
    S/MIME
  </DigitalEnvelopeProtocol>

  <EncryptionAlgorithm>
    DES-CBC
  </EncryptionAlgorithm>
<SenderDigitalEnvelope>

The examples shown in Listing 4 indicate that the sender supports XML Signature for message-level authentication using the DSA algorithm and SHA-1 hash function. For data privacy, the S/MIME v2.0 mechanism is used with a 56-bit DES key in CBC mode.

At this point, it may seem as if all the necessary message-level security mechanisms have been specified, but there is still a question of how to apply these operations to the ebMS message. The ebMS specification uses a multipart MIME encapsulation. The driver for this includes scenarios in which different portions of the entire ebMS message are encrypted or signed. This is the job of the <Packaging> element, which describes the parts of the ebMS message that need to be signed and encrypted and the parts that should be left in the clear for others to modify, update, or change.

The <Packaging> Element
The <Packaging> element describes which portions of the ebMS messages to sign and encrypt and which portions to leave in the clear.

To see how the <Packaging> element works, we must first look at the message structure of an ebMS message, which is defined in terms of SOAP with Attachments (SwA). The SwA structure is further defined in terms of a set of MIME packages called SOAP Message Packages. Each SwA message is a set of message packages with the main SOAP payload appearing in the first MIME container. Figure 2 shows a visual representation of an ebMS message in relation to the rest of the application layer.

Figure 2. The ebMS message structure

Figure 2 shows three MIME parts in the SOAP Message Package, a Header Container and two Payload Containers. When specifying message-level security policy, the <Packaging> element should help us clearly specify the parts of the package that should have security properties applied to them.

Due to the recursive nature of MIME, one MIME part may be conceptually replaced by a new MIME part that has been signed or encrypted. To identify the parts of a message package, the CPP contains a collection of <SimplePart> elements that serve to uniquely identify the various MIME parts in the message. The <SimplePart> elements define the constituents of the message by providing a simple reference mechanism. Three example <SimplePart> elements are shown here:

<SimplePart id="Part 1" mimetype="text/xml"/>
<SimplePart id="Part 2" mimetype="application/xml"/> 
<SimplePart id="Part 3" mimetype="text/html"/>

In the previous example, the MIME part of content-type text/xml is given an identifier of "Part 1," the MIME part of content-type application/xml is given an identifier of "Part 2," and the MIME part of content-type text/html is given an identifier of "Part 3."

To specify that a particular MIME part should be encrypted, the <Packaging> element uses the <CompositeList> element to specify the new outer MIME encapsulation. The <CompositeList> element contains any number of <Encapsulation> or <Composite> elements. <Encapsulation> elements represent encrypted or signed MIME parts with new content types and identifiers that are referred to by <Composite> elements. For example, consider Figure 3, which shows a conceptual view of three MIME parts in an ebMS message.

Figure 3. ebMS MIME parts before encryption

The tricky part regarding the <CompositeList> element is the way it refers to the existing MIME parts while simultaneously defining new parts that are the result of an implicit encryption or signature operation. For example, keeping Figure 3 in mind, consider Listing 5, which shows an example of the <CompositeList> child element.

Listing 5. The <CompositeList> Element

<Packaging>
  <CompositeList> 
  <Encapsulation 

   <!-- Part 2 is the payload being encrypted --> 
   id="Part A" mimetype="application/pkcs7-mime"   
   mimeparameters="smime-type="enveloped-data""> 
   <Constituent idref="Part 2"/>

   <Encapsulation> 

   <Composite tp:id="New Part"
    mimetype="multipart/related"
     mimeparameters="type="text/xml" 
     version="1.0"">

    <!-- Part 1 is the SOAP envelope
    The ebXML message is made up of the
    SOAP envelope and the encrypted payload. --> 
   
   <Constituent idref="Part 1"/>
   <Constituent idref="Part A"/>

  </Composite> 
  </CompositeList>
</Packaging>

It is easier to understand the recursive "Russian doll" nature of the encapsulated portions if the example is read from bottom to top. The last <Composite> element defines a new MIME encapsulation of content-type multipart/related. This new encapsulation houses two of the previous MIME parts in the example, the original MIME part with the label "Part 1" and a new MIME part with the label "Part A." Reading further upward, the <Encapsulation> element defines the new MIME part "Part A" by encrypting the original MIME part with the label "Part 2." A final pictorial example of the change is shown in Figure 4.

Figure 4. MIME part transformations for ebMS

Figure 4 shows the newly generated parts in bold. Notice that the original message went from three MIME parts to two MIME parts but preserved the original structure by creating a new hierarchy of encapsulated parts.

ebMS Message-Level Security

The general message structure for an ebMS message is based on SOAP v1.1 and SOAP with Attachments. The initial specification for ebMS 2.0 was completed in early April 2004; because of the timing it doesn't benefit from standard SOAP security mechanisms such as OASIS WS-Security and the OASIS WS-Security SOAP with Attachments Profile. Instead, it uses XML Signature for data integrity and sender authentication, and makes suggestions for different payload encryption techniques from a choice of XML Encryption, S/MIME, and PGP/MIME.

XML Signature and ebMS
The W3C XML Signature Recommendation defines how an XML Signature can be used to authenticate any type of XML document. For ebMS, which relies on SOAP Message Packages, the XML Signature must generally authenticate at least two important pieces of information: the SOAP payload, which resides in the first MIME part, and one or more attachment MIME parts, which contain the actual business messages.

The heart of an XML Signature is the <Reference> element. Each <Reference> element specifies a target URI to digest, including a digest function to use. After all the <Reference> elements have been resolved, they are collected into a list, and this list is signed.

In the case of ebMS, at least two <Reference> elements are generally used, one to specify the entire SOAP envelope with an enveloped signature and one to specify the attachment using the content-id reference mechanism.

It is extremely important to note that using an enveloped signature is a tremendous performance hit in terms of XML processing. The reason for this lies in the fact that the entire XML node set must be parsed against an expensive XPath expression and then canonicalized to ensure that syntactic changes are removed before verifying. This type of expensive XML processing is precisely the type of processing that can be easily offloaded to a dedicated hardware appliance that can perform XML Signature operations at wire speed. Listing 6 shows a sample signed ebMS message.

Listing 6. A Sample Signed ebMS Instance

<SOAP:Header>
<eb:MessageHeader eb:id="..." eb:version="2.0" SOAP:mustUnderstand="1"> 
</eb:MessageHeader>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> 
<SignedInfo> 
<CanonicalizationMethod 
  Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> 
<SignatureMethod 
  Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/> 
<Reference URI=""> 
<Transforms> 
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> 
<Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"> 
<XPath> 
  not(ancestor-or self::node()
  [@SOAP:actor="urn:oasis:names:tc:ebxmlmsg:actor:nextMSH"]
  | ancestor-or-self::node()[@SOAP:actor= 
  "http://schemas.xmlsoap.org/soap/actor/next"]) 
 </XPath> 
 </Transform>
 <Transform 
  Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
 </Transforms> 
 <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> 
   <DigestValue>...</DigestValue> 
 </Reference> 
 <Reference URI="cid://blahblahblah/"> 
 <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> 
 <DigestValue>...</DigestValue> 
 </Reference> 
 </SignedInfo> 
 <SignatureValue>...</SignatureValue> 
 <KeyInfo>...</KeyInfo> 
 </Signature> 
 </SOAP:Header> 
 <SOAP:Body> 
 <eb:Manifest eb:id="Mani01" eb:version="2.0"> 
 <eb:Reference xlink:href="cid://blahblahblah/" 
     xlink:role="http://ebxml.org/gci/invoice"> 
 <eb:Schema eb:version="2.0" 
     eb:location="http://ebxml.org/gci/busdocs/invoice.dtd"/> 
 </eb:Reference> 
 </eb:Manifest> 
</SOAP:Body> 
</SOAP:Envelope>

Perhaps the two most important parts of Listing 6 are the <Reference> elements with URI attributes of the empty set (" ") and the cid:// scheme. The URI attribute of the empty set essentially means that the target of the reference is the current XML document parsed from the document element, including the operation of the specified transforms (which include an XPath expression to remove the <Signature> element from the final calculation), and canonical XML (which strips syntactic variations). The cid:// scheme refers to the content-id of the first MIME part (not shown). The MIME part is interpreted as opaque binary, and the entire part is authenticated with the given <Reference> element.

Payload Encryption and ebMS

The ebMS 2.0 specification takes a strong stance on payload encryption and defines XML Encryption to be the default encryption method for ebMS 2.0 messages. This strong stance is softened by the fact that when the ebMS 2.0 specification was released, XML Encryption was not yet at the full Recommendations status, and therefore other legacy mechanisms such as S/MIME and PGP/MIME have also been specified as alternatives.

The advantage of XML Encryption over legacy mechanisms is its support of selective encryption for ebMS header elements. That is, with legacy mechanisms like S/MIME or PGP/MIME, it is easy to encrypt an entire MIME part but not possible to select a subdocument or specific child element to protect. This advantage coupled with the natural alignment of ebXML with XML-related standards makes XML Encryption the natural choice for most new B2B deployments.

Additional Content-Borne Threats

In this article we discussed what will be termed "traditional" message layer security, focusing primarily on applied cryptography such as signatures and encryption. In particular, this type of message layer security has to deal more with trust enablement than with threat prevention. What may not be apparent here is that there are new XML-based threats, called XML Content Attacks, that are also part of the message layer security. An example of some of these content-based threats will be discussed in Part 2 of this series.

Resources

• ebXML.org - The official ebXML web site
• Introduction to ebXML - An overview of ebXML
• W3C XML Signature - XML Signature Working Group
• W3C XML Encryption - XML Encryption Working Group
• W3C Web Services Activity - The W3C site for web services activity
• SOAP/XML Protocol - XML Protocol Working Group
• SOAP Messages with Attachments - The W3C site for SOAP Messages with Attachments
• OASIS WS-Security - OASIS Web Services Security page
• S/MIME - The S/MIME Specification
• PGP/MIME - The PGP/MIME Specification

Blake Dournaee is a senior architect at Sarvega, Inc, based in Oakbrook Terrace, IL.

---

Return to dev2dev.