Securing Web Services using XKMS

Securing Web Services using XKMS

Introduction

The XML Key Management Specification (XKMS) is a recent development in the cryptography domain, along the lines of the nearly ubiquitous XML-orientation of technologies. These days when everything is getting XML-enabled, why is this XML technology worth considering? Unlike many XML-enabled technologies, XKMS has the potential to revolutionize Public Key Infrastructure (PKI) by making PKI simpler to deploy, use and manage. In fact, XKMS just might make PKI a viable reality for enterprises, embedded devices and users.

If you have worked with PKI software from various vendors, then you'll be aware of the difficulties in setting up a solution and in getting different vendor software to interoperate properly. Today every vendor sells their own wares their own way, which are supposedly standard. You have the Java security package and APIs, Microsoft CAPI, RSA BSAFE, Xcert Xuda, and so on. And all these vendors provide their own certificate and key management solutions. Then there are smart card or cryptographic token extensions offered by various vendors. All these are PKCS compatible, and yet incompatible. An oxymoron surely? But how can one have an "infrastructure" if the pieces of the infrastructure from various vendors have a difficult time working together? Even within a vendor's solution, deployment is a big hassle. One needs to educate, and then explain away the "extra" burdensome steps required by users and administrators to configure, use and manage the solution.

XKMS brings in an important simplification by offloading complex key management tasks to web services and establishing access standards via XML. This offloading and XML usage also makes client code thinner and amenable to embedding into small devices.

However XKMS still doesn't fully address PKI adoption problems, though it goes a long way into making it simpler to use. Signing, verification and certificate management is outside the scope of XKMS by definition. The XKMS Java SDK provided freely by the consortium includes crypto functions in addition to key management. These are good for signing XML-based messages using the XML Signature Specification, and can therefore be used in conjunction with its primary APIs for Web Services. This, then, is the focus of this article.

In this article we describe the elements of XKMS, then focus on Microsoft .NET and how to apply the XKMS SDK to it. We show how one may use this SDK to secure SOAP calls on a Microsoft platform. Note that the SDK supports SOAP transport, which can be misleading in this context. It means that an XKMS web service can be reached through SOAP invocations. That is, the XML schemas used to access the XKMS web service may be SOAP compliant. It does not mean that SOAP invocations done by any client to any web service can be secured (signed/encrypted) by using XKMS SDK. That is a slightly more difficult problem and hence forms the main content of this article.

Now considering that this SDK is Java-based and that Microsoft has a well-known aversion to Java technologies, making this SDK work on Windows native technologies is a not-so-simple task. But we believe that Microsoft will soon include an XKMS compliant SDK into its offerings, considering that they are one of the co-authors of the specification.

Until then, Visual Basic and Visual C++ programmers may use the techniques presented in this article for their .Net services. Unix-oriented developers may also look at the samples to get familiar with the use of XKMS. For the brouhahas on XKMS, go to the mother lode at http://www.xkms.org maintained by VeriSign Inc.

Note that one really doesn't need the XKMS SDK to do all that is described here. Digital Signature related APIs abound, so why have we chosen to use XKMS? First of all, XKMS provides a simple and interoperable way, that we hope becomes a standard. Secondly, how can one resist a great demonstration of consuming one web service from another? And finally, even though SOAP can be carried over HTTPS for security purposes, SOAP message forwarding or proxying would not be possible without creating the risk of a man-in-the-middle attack vulnerability. With our solution, one can sign/encrypt any portion of a SOAP message and send it through an arbitrary number of channels. We hope that someone (maybe Microsoft) takes note and goes on to build a fully native solution bypassing some of the tricks that we have used to make our solution functional.

Download

Download full seminar papers At
http://www.enjineer.com/forum