Welcome!

VP Innovation at Axway, Co-founder at Vordel

Mark O'Neill

Subscribe to Mark O'Neill: eMailAlertsEmail Alerts
Get Mark O'Neill via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: XML Magazine

XML: Article

XML and Security

XML and Security

As XML becomes the de facto format for businesses to communicate over the Internet, the need for security comes to the fore. Digital security has always been about the compromise between convenience and peace of mind. This holds true for XML also.

The proposed advantages of XML for digital commerce - the opening up of internal systems to trading partners via commonly agreed standards - are also concerns for security. These concerns are now being addressed by a number of industry initiatives.

This article describes a selection of these initiatives: the W3C's recent XML Signature specification and its relationship to SOAP, the OASIS SAML (Security Assertions Markup Language) initiative, and XKMS (XML Key Management Specification). Together, these initiatives are setting in place the infrastructure that will allow XML to travel safely between enterprises.

History
A common thread in the debate about XML and security has focused on whether or not to put the security layer within the XML document. Some of the early non-XML B2B integration frameworks, such as OBI (Open Buying on the Internet), which began in June 1997, incorporated X.509 and digital certificates and digital signatures at field level into their document sets. Then the early XML-based B2B integration frameworks, such as Open Trading Protocol (OTP), followed suit with security-specific tags. At this point opinion shifted and it was thought best not to mix up the XML data payload with security and authentication information. As the HTTP POST protocol became the commonly accepted method of transmitting XML, it was felt that SSL should be used since it comes "for free" with HTTP. XML can be transmitted just as well over an SSL connection as over a plain HTTP connection, albeit somewhat more slowly. The first SOAP draft (1999) avoided the authentication question, deferring it to later drafts, and suggested the use of SSL. However, although SSL handles authentication, it doesn't address digital signatures. The W3C then became involved, setting up the XML Signature Working Group to produce the XML Digital Signature Specification. XML-DSIG is an important standard because it supports the digital signing of any digital content, not just XML. Thus the debate has come full circle; the signature is now once again part of the XML document, except that now the signature format is a common standard that can be archived and interpreted by any piece of standards-compliant software.

XML Signature
The XML Signature standard describes a set of XML elements and attributes that are used to store information about the hashing and encryption algorithms used to generate a digital signature, as well as, of course, the signature itself. In addition, the public key used to verify the signature can be incorporated within the <Signature> block; alternatively, the address of the public key directory that includes the public key can be included.

The discussion relating to the design of the XML Signature standard yielded a number of interesting questions. Some touch on philosophical issues and get to the core of the concepts behind structured data and its representation onscreen. The XML Signature standard mandates that only what is "seen" should be signed. The word seen is in quotation marks because the user may perceive the information in another media other than visual - through sound, for example.

It's important to secure the actual data that was presented to the person. This means that if XML is rendered onscreen using a stylesheet, then the visual representation of the data must be signed since this is what the user actually sees. It's been suggested that the components used to render the XML should also be signed - the XML Signature specification says that the data must be signed along with "whatever filters, style sheets, client profile or other information that affects its presentation." These items may include the browser itself, even video drivers or font packs, or ultimately the operating system itself. The important point is that the user's decision to sign is based on the visual representation of the XML data, not the underlying XML itself.

The Identrus PKI group - a consortium of banks that issue digital certificates signed by the Identrus root certificate authority (CA) - requires that users be presented with a bitmapped image of the document that is to be signed. This bitmap isn't useful for subsequent data processing but instead serves as a record of what the user saw. The signing software must ensure that the document that the user views isn't obscured by another application in the foreground. Identrus uses an XML format, CSC (Certificate Status Check), to authenticate users.

Another interesting aspect of XML Signature is that the document itself must be protected so no changes happening to it in transit can invalidate the signature. To understand why this is important, you have to understand what a hash is. A hash is a value produced by a one-way mathematical function run on a piece of data. If others run the same hash function onto the data, they obtain the same hash value.

This is how signatures work - this hash value is encrypted with the private key of the signer, and then anyone with access to their public key can decrypt the original hash, compute a new hash based on the data they have received, and make sure that the two hash values are the same. XML presents a number of problems for hashing, however. An XML document may contain some white space between tags, for example, and this white space may be lost when a DOM or SAX processes the XML. Similarly, the order in which tags or attributes occur in an XML document may be changed when it's loaded into a DOM or SAX processor.

The problem with this scenario is that when the application computes a hash of the document, the white space or the tag order having changed, the hash won't match the original hash, so the signature won't compute. In addition, certain differences between file formats on different operating systems can cause XML documents to subtly change as they are sent between disparate machines. These issues are to be solved by XML Canonicalization. XML Canonicalization defines a standard way to normalize XML information between operating systems. So-called canonical XML is intended to be platform neutral.

An example of an XML Signature is shown in Listing 1. The SignatureMethod tag tells us that a combination of RSA (for public key encryption) and SHA-1 (for hashing) was used to create this signature. The X.509 certificate used to verify the signature is included with the signature itself. This signature is appended to the document it signs.

PKI - Binding a Key to a Person
The XML Signature standard specifies XML digital signature processing rules and syntax that prove that a document was signed using a certain private key; a Public Key Infrastructure (PKI) then binds that key to a user's identity. Note that there are two clauses in the previous sentence. Digital signature algorithms provide the mathematical proof of a transaction. However, unless the private key is linked to a person or organization, that proof is just mathematical. PKI is used to link the transaction to the person, making use of publicly available directories to store the public keys used to check the digital signatures and referencing a security policy document to enforce identity checks on applicants for digital certificates. Implementing a PKI can be a notoriously difficult and expensive undertaking, so many organizations rely on global PKI services such as VeriSign or PricewaterhouseCoopers beTRUSTed.

As we've seen, PKI brings a lot of value to XML. Conversely, however, with the arrival on the scene of XKMS (XML Key Management Specification), the world of PKI is beginning to become XML-enabled. XKMS is proposed by VeriSign, Microsoft, and webMethods, and has been submitted as a W3C note. It comprises two parts: the XML Key Information Service Specification (X-KISS) and the XML Key Registration Service Specification (X-KRSS).

X-KISS allows a client application to delegate part or all of the tasks required to process an XML Signature to a trust service. This is useful for developers who don't want to implement the signature checking themselves, or who want to delegate this functionality to an application service provider that may be optimized for signature checking (e.g., through hardware acceleration).

X-KRSS is an XML-based replacement for existing PKI file formats that are used when a user applies for a digital certificate. XML brings the same advantages to PKI as it brings to other industries - open standards, platform independence, and human readability.

XKMS looks likely to take off, not least because Microsoft is bundling it into its .NET initiative.

Web Services - Component-Based Computing Takes to the Web
The long-standing drive toward component-based computing in IT architectures is now moving to the Web. Components that are physically located on different computers can run together as one solution, using technologies such as SOAP (for enveloping XML on the wire), UDDI (for publishing information about available services), and DSML (for accessing directories over the Web) over frameworks such as .NET, Jini, or E-Speak.

A simple example of a Web service is a stock quotation object that can be instantiated over the Internet by an application that requires such a tax-calculation feature. By tying together Web services, "business Webs" - dynamic collections of businesses - can be spawned on a massive scale. An example of a business Web is a retail store that uses UDDI to publish its online catalog; the catalog can then call the company's shopping cart and a third company's credit card transaction service. Development tools such as Microsoft's Visual Studio.NET and Bowstreet's jUDDI allow developers to link Web services to create business Webs, often without any need for programming.

SOAP is firmly established as the enveloping protocol of choice for Web services. Until recently, SOAP did not address the requirement for security. But in January 2001 Microsoft and IBM proposed in a W3C note the integration of XML Signatures into the SOAP 1.1 Envelope via a new <SOAP-SEC:Signature> header entry. The various Web services frameworks - .Net, Jini, and E-Speak - will most likely use XML Signature-enabled SOAP messages.

E-Speak is something of a special case because it was the first fully operational Web services design, initially announced by Hewlett-Packard back in 1999, and was recently updated to comply with the SOAP specification. Certificate-based security is included in E-Speak in the form of fine-grained, rule-based security that uses attribute certificates. It remains to be seen if SOAP-level security will supplant this.

The advent of Web services opens up some important questions for security. If it's so easy to string Web services together to create a business Web, then what's to stop a hacker from exploiting this? What is needed is a way of certifying Web services. Otherwise a Web agent that searches for services has no way of knowing what services to trust. Centralized, trusted, UDDI directories are one way of answering this security question. However, it remains to be seen how well this option will scale. The other option would be to use a certification system similar to Microsoft's AuthentiCode, where the onus is on vendors to register and sign their service. This has the advantage of retaining the peer-to-peer nature of the Internet, but still depends on the existence of a service to check credentials. As we've seen, XKMS fits the bill as a protocol to deliver this.

And What About Firewalls?
One very special reason why XML-specific security is important is that Web services typically use the Web ports, thereby bypassing firewall restrictions. An example of this trend is SOAP, which earlier in its lineage used to travel over port 135 (the RPC Endpoint Mapper port), a port that is typically blocked by firewalls for security reasons. Now SOAP uses the Web ports and so avoids firewalls.

Other examples are the new XML interface on Microsoft SQL Server 2000, or the XSQL feature that allows Oracle 9i to conveniently read in a stream of XML. For an IT manager it's an appealing prospect to Internet-enable an application by opening it over Web ports via an XML interface. Quite often the fact that an application is blocked by a firewall appears to users as if the application "just plain doesn't work." Users typically don't understand that a protocol is blocked by the firewall for a reason.

This problem held up the spread of CORBA, even resulting in some CORBA vendors resorting to writing their own firewalls. PKI rollouts have also been affected by this problem, which results in essential LDAP directory lookups (which use port 389) being blocked - hence the need for Directory Services Markup Language (DSML, pronounced dismal) to provide an XML-based directory lookup over the Web ports.

The XML-based Internet does away with the possibility of denying network traffic based on specifying TCP/IP port numbers. Next-generation firewalls must be capable of dipping into XML streams traveling over Web ports to check their payloads, much like today's e-mail virus checkers dip into e-mail data streams on mail servers. In the case of XML signatures this authentication can be done locally or by sending the signature block to an XKMS trust service. However, if the XML stream is encrypted, a traditional firewall is of limited use because it simply can't read the data. SOAP partially gets around this problem by allowing the SOAPAction method name in the HTTP header to travel in the clear so that a firewall can route the document. But this has the disadvantage of giving away information about which Web service is being accessed.

The SOAP specification includes the SOAP-specific M-POST command that enables SOAP-compliant programs to add header information to the HTTP protocol to allow fine-grained, rule-based filtering and handling of SOAP messages by firewalls and proxy servers. This of course relies on proxies and firewalls being configured to recognize M-POST.

S2ML and AuthXML - Two Become One?
In November 2000 two separate initiatives were announced to develop an XML standard for transporting security information between online commerce systems. The two initiatives are S2ML (Security Services Markup Language), led by Netegrity, and AuthXML, led by Securant Technologies. The goal of both initiatives is to implement Single Sign-On, one of the holy grails of computing, between online trading environments.

This service is needed because online commerce typically involves more than one Web site or Web service, and these may need to share information about a user. S2ML or AuthXML would assist partners and affiliates in linking their exchanges to share "entitlement" information - for example, credit limits and "gold card"-type profiles. Also, both protocols would eliminate the need for users to repeatedly enter registration information onto multiple Web sites. Participants in S2ML include webMethods, Sun, VeriSign, and Jamcracker. In addition, the ebXML working group has endorsed S2ML. Participants in AuthXML include Check Point, Novell, and ValiCert. Some vendors, like some Florida voters, signed up to support both competing initiatives.

In view of the fact that S2ML and AuthXML address the same requirements but aren't interoperable, OASIS (part of the Open Group) set up a technical committee for XML-based security services to merge the two initiatives into a single standard. It was felt that a single standard would be a more favorable outcome for the industry than two competing initatives. After all, by definition a "standard" should be something that everyone uses. The OASIS initiative to merge AuthXML and S2ML is still in the early stages, having started in December 2000, but is gathering momentum. The initiative has been christened SAML - Security Assertions Markup Language.

How This All Fits Together
The initiatives described in this article fit into various parts of the four layers shown in Table 1. It's expected that XML Signature will be incorporated into many of the B2B integration frameworks, via the proposed SOAP XML-DSIG header extensions.

The next few months should be interesting for both the XML and the security worlds because they're coming together in interesting ways. XKMS is bringing the XML message of common standards to the digital security industry, notorious for its fragmented standards. Similarly, initiatives such as XML Signature and OASIS SAML are bringing the vital level of trust to business-to-business trading on the Internet. These events should lay the secure foundations for the much-anticipated growth of business Webs.

More Stories By Mark O'Neill

Mark O'Neill is VP Innovation at Axway - API and Identity. Previously he was CTO and co-founder at Vordel, which was acquired by Axway. A regular speaker at industry conferences and a contributor to SOA World Magazine and Cloud Computing Journal, Mark holds a degree in mathematics and psychology from Trinity College Dublin and graduate qualifications in neural network programming from Oxford University.

Comments (1)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.