As XML becomes the de-facto format for businesses to communicate over the Internet, so 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 security 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.
A bit of history
A common thread in the debate about XML and security has focussed on whether to put the security layer within the XML document or not. 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 the XML data payload up 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 does not address digital signatures. The W3C then became involved, setting up the XML Signature Working Group to produce the XML Digital Signature Specification (XML-DSIG). 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.
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 that is used to verify the signature can be incorporated within the <Signature&rt; block, or 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 threw number of interesting questions. Some of these touch on philosophical issues, and get to the core of the concepts behind structured data and its representation on-screen. The XML Signature standard mandates that only what is "seen" should be signed. The word seen is in inverted commas because the user may perceive the information in another media rather than the visual media, through sound, for example. It is important to secure the actual data that was presented to the person. This means that if XML is being rendered on-screen using a style-sheet, then the visual representation of the data must be signed, since this is what the user actually sees. It has 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 is not 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 is not being obscured by another application in the foreground. Identrus makes use of an XML format called CSC (Certificate Status Check), to authenticate users.
Another interesting aspect of XML Signature is that the document itself must be protected so that no changes happen to it in transit that could invalidate the signature. To understand why this is important, it's important 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 someone else runs 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, then the hash will not match the original hash and so the signature will not 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 be solved by XML Canonicalisation. XML Canonicalisation defines a standard way to normalise XML information between operating systems. So-called canonical XML is intended to be platform-neutral.
An example of an XML Signature is shown below in Figure 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 that is used to verify the signature is included with the signature itself. This signature is appended to the document which it signs.
Figure 1: XML Signature Example
<?xml version="1.0" ?> <Signature Id="Vordel" xmlns="http://www.w3.org/2000/CR-xml-c14n-20001026"> <SignedInfo> <CanonicalizationMethod Algorithm="None" /> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <Reference URI="http://www.w3.org/TR/2000/CR-xml-c14n-20001026"> <Transforms> <Transform Algorithm="http://www.w3.org/2000/CR-xml-c14n-20001026" /> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <DigestValue> qyd5dHCHsQ1GXw0j6hk6PZtF8vE= </DigestValue> </Reference> </SignedInfo> <SignatureValue> NrZOJ7rEyIPmLs/CoK2gQJ32EWwkTnAkhuzUMrjs/+WwJdJ+3XoP </SignatureValue> <KeyInfo> <X509Data> <X509IssuerSerial> <X509IssuerName> c=IE, o=Vordel, ou=TS, cn=VordelCA, email@example.com </X509IssuerName> <X509SerialNumber>970241782</X509SerialNumber> </X509IssuerSerial> <X509SubjectName> c=IE, o=Vordel, ou=Dev, cn=Mark, firstname.lastname@example.org, telephoneNumber=35312153333 </X509SubjectName> <X509Certificate> -----BEGIN CERTIFICATE----- MIIC2TCCAcGgAwIBAgIEOdS29jANBgYkCgYEAr2emzUvznx9/jeFNc5NUI mceS9x9QSP63cxkwlGAQYS3OkOFShmeF6xvt8ra2UiwS0xO1FYXQu7mRIA KQe9zhQaIP63NlsqfuRJLNkRFkHstfZtTlESzAe5LosLGVgeU8ocT+8f6z u3LkcgqfWJhxq79YScl9OixBYD6jAIIDC4IHgEOyDCLhKaJgZ2eAnepx4M k+fSPmGvN7uDhUIk/OujQOwlOG4qYzrd4d4Vax/QV6GXn2UpT894h0giEB xZczY4xIkCsdXIGF+PGIfcq1WdPYMG+Nvz661QMrTxGYiG8Aws2R8+29mw 6JkYTzcpItNw95FQoM1MpeMfUZcm/Ja7Fon2Qfp9oeGTlNE+Q==mkl213b lktrh[-qwDFSgfEWTet=2tewgfsm,qWuGrt -----END CERTIFICATE---- </X509Certificate> </X509Data> </KeyInfo> <Object> <SignatureProperties> <SignatureProperty Id="TimeStamp" Target="#Vordel"> <timestamp> <date>2001Apr02</date> <time>10:08:04</time> </timestamp> </SignatureProperty> </SignatureProperties> <DirectoryIPAddress /> </Object> </Signature>
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, and then a Public Key Infrastructure (PKI) 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 organisation, that proof is just a mathematical proof. PKI is used to link the transaction to the person, making use of publicly available directories to store the public keys that are 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 organisations rely on global PKI services such as Verisign or PricewaterhouseCooper's Betrusted.
As we have seen, PKI brings a lot of value to XML. But, conversely, the world of PKI is beginning to become XML-enabled, with the arrival on the scene of XKMS (XML Key Management Protocol). 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 do not want to implement the signature checking themselves, or who want to delegate this functionality to an Application Service Provider that may be optimised 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 towards 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, then the catalog can calls 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 together 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 has recently been 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 is so easy to string Web Services together to create a business web, then what is 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. Centralised, 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 the vendor to register and sign their service. This has the advantage of retaining the peer-to-peer nature of the Internet, but still depends the existence of a service to check credentials. As we have 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 8i to conveniently read in a stream of XML. For an IT Manager it is 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 do not understand that a protocol is being 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, too, have been affected by this problem which results in essential LDAP directory lookups (which use port 389) being blocked - hence the need for DSML (Directory Services Markup Language, 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 travelling over web ports to check their payloads, much like today's email virus checkers dip into email 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 then a traditional firewall is of limited use, because it simply cannot 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 which 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. Of course, this relies on proxies and firewalls being configured to recognise 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 facilitate partners and affiliates to link their exchanges together 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 websites. 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 are not 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 favourable 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 at 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 following four layers (see Figure 2 below). It is 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 security worlds, because they are 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.
Figure 2 - XML Security standards vs. B2B network layers
Get HelpContact Us
Follow Us on: