The Web Services Advisor
(Receive this column in your inbox,
click Edit your Profile to subscribe.)
An inside look at XML Encryption
For the last several columns, I've been covering Web services security standards, and this time around we get to one of the core pieces of technology - encryption. Without encryption, anyone can read the data being sent across the Internet during a transaction. And that would mean the death of Web services for any business purpose - and for private purposes for that matter.
Encryption solves the problem, and the encryption standard used for Web services is XML Encryption. It doesn't work by itself - rather it works in concert with other security standards, notably XML Signature and XKMS. XML Signature allows documents to be digitally signed, and XKMS handles the digital keys used to encrypt and decrypt documents.
How XML encryption works
Before taking a closer look at XML Encryption, we'll take a very brief look at how encryption works. When a piece of data is to be encrypted, a key, cipher or unique algorithm is applied to the data, and the data can only be encrypted by the use of the same key or a matching key in a key pair. So any encryption system needs to detail the data itself, as well as the key or keys used to encrypt and decrypt the data.
XML Encryption does this by outlining a process that allows any data in XML documents to be encrypted and decrypted. It specifies the data to be encrypted, as well giving information about the cipher or key used to encrypt the data. It doesn't, however, handle the actual exchange of keys - that's the job of XKMS.
XML Encryption has to handle a particularly thorny problem unique to Web services - it must be flexible enough to encrypt only individual parts of a document, or be able to encrypt the entire document itself. That's because Web service transactions may be performed among many partners and businesses, and not all the information in the transaction should be available to everyone who participates in the transaction. For example, a transaction may include payment information and credit card information that only some of the participants should be able to see, but that should be shielded from others.
XML Encryption in action
How does XML Encryption solve this task? Let's take a look at it in action. We'll take a very simple transaction, showing how it can encrypt part or all of a credit card payment done via a Web service. (This example is taken from the W3C proposed encryption standard. For more information about the standard or this example, go to http://www.w3.org/TR/xmlenc-core/.)
We'll imagine a fictitious transaction in which John Smith is paying using his credit card over a Web service. The initial, unencrypted XML document looks like the following. Note that this would be just one part of a much larger XML document that would define the entire transaction.
<?xml version='1.0'?>
<PaymentInfo xmlns='http://example.org/paymentv2'>
<Name>John Smith</Name>
<CreditCard Limit='5,000' Currency='USD'>
<Number>4019 2445 0277 5567</Number>
<Issuer>Example Bank</Issuer>
<Expiration>04/02</Expiration>
</CreditCard>
</PaymentInfo>
As you can see, tags define John's name, as well as the bank that issued his credit card, its expiration date, his credit limit, and the actual card number itself. Clearly, all that information can't be sent out unencrypted because the credit card can be easily stolen. So we need to use encryption. Here's how XML Encryption would handle encrypting all the information about the credit card:
<?xml version='1.0'?>
<PaymentInfo xmlns='http://example.org/paymentv2'>
<Name>John Smith</Name>
<EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element'
xmlns='http://www.w3.org/2001/04/xmlenc#'>
<CipherData>
<CipherValue>A23B45C56</CipherValue>
</CipherData>
</EncryptedData>
</PaymentInfo>
Note that everything about the credit card has been encrypted - even including the fact that a credit card is involved in the transaction. Tags point to where the encrypted data can be found, how the data is encrypted, and the cipher or key used to encrypt the data. With the proper matching key, the information can be decrypted.
What if, however, some people in the transaction need to know that a credit card with a particular limit was used - but they don't need to know the card's number, issuer, and expiration date. Here's how XML Encryption would handle that:
<?xml version='1.0'>
<PaymentInfo xmlns='http://example.org/paymentv2'>
<Name>John Smith</Name>
<CreditCard Limit='5,000' Currency='USD'>
<EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
Type='http://www.w3.org/2001/04/xmlenc#Content'>
<CipherData>
<CipherValue>A23B45C56</CipherValue>
</CipherData>
</EncryptedData>
</CreditCard>
</PaymentInfo>
As you can see, the fact that a credit card is used and the credit limit are not encrypted, and so can be read. But the actual credit card information is encrypted. In similar ways, any part of an XML document can be encrypted - and if need be, the entire document can be encrypted as well.
Where XML Encryption is today
XML Encryption has been recommended as a standard by the W3C, and that body believes that the specification is stable. For a look at the standard itself, go to http://www.w3.org/TR/xmlenc-core/. To find out information about the W3C working group handling the specification, go to http://www.w3.org/Encryption/2001/.
To use XML Encryption, you'll need toolkits, and several are already available. You can try IBM's XML Security suite at http://www.alphaworks.ibm.com/tech/xmlsecuritysuite, Baltimore KeyTools at http://www.baltimore.com/keytools/index.asp, as well as products from RSA Security at http://www.rsasecurity.com.
Whether you need XML Encryption today or not, you will need it some time in the future. The standard is a solid, stable one, so worth looking into now.
About the Author
Preston Gralla, a well-known technology expert, is the author of more than 20 books, including "How the Internet Works," which has been translated into 14 languages and sold several hundred thousand copies worldwide. He is an expert on Web services and the author of a major research and white paper for the Software and Information Industry Association on the topic. Gralla was the founding managing editor of PC Week, a founding editor and then editor and editorial director of PC/Computing, and an executive editor for ZDNet and CNet. He has written about technology for more than 15 years for many major magazines and newspapers, including PC Magazine, Computerworld, CIO Magazine, eWeek and its forerunner PC Week, PC/Computing, the Los Angeles Times, USA Today, and the Dallas Morning News among others. As a well-known technology guru, he appears frequently on TV and radio shows and networks, including CNN, MSNBC, ABC World News Now, the CBS Early Show, PBS's All Things Considered and others. He has won a number of awards for his writing, including from the Computer Press Association for the Best Feature in a Computer Publication. He can be reached at preston@gralla.com.
For More Information:
