- Public Key Encryption
- XML Security Standards
- Digital Signatures
- The XML Encryption Standard
- XML and Web Services Attacks
- Forewarned Is Forearmed
- Summary
- References
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The XML Encryption Standard
XML encryption is an XML vocabulary for working with public key encryption. You may wonder why a separate vocabulary is needed for sending XML over the Internet, when Secure Sockets Layer (SSL) and Transport Layer Security (TLS) already exist for securing all kinds of data transfer, including XML. The answer is that, in many cases, SSL and TLS are completely sufficient. They work by encrypting XML as it moves from point to point. The role of XML encryption is not to replace or supersede SSL/TLS, but to augment it when requirements go beyond a simple point-to-point secure XML transfer.
There are three main use cases for XML encryption.
- Only part of the XML needs to be encrypted.
- You are sending SOAP messages over SSL/TLS and are concerned about intermediate SOAP handlers seeing your data.
- You are digitally signing XML and want to authenticate to the receiver that it’s really you sending the message.
Let’s look at each scenario in turn.
Case 1: Partial Document Encryption
Sometimes you may prefer to have only part of your document encrypted, for reasons such as the following:
- Encryption is expensive, and encrypting large documents is even more expensive both in terms of CPU cycles and memory.
- The XML may be processed in stages, with different constituencies working with different sets of elements.
Suppose you want to send the XML file in Listing 1 to a publishing company. The XML contains details of a book order that includes book and credit card information. The warehouse needs to see what book is being ordered, but doesn’t need access to the credit card information.
Listing 1 XML document before encryption.
<?xml version=’1.0’?> <Payments xmlns=’http://globalbank.org’> ... <Payment> <Name>John von Neumann<Name/> <Book> Gödel, Escher, Bach: An Eternal Golden Braid</Book> <ISBN>0465026567</ISBN> <CreditCard Limit=’5,000’ Currency=’Euro’> <Number>4654 2445 0277 5567</Number> <Issuer>World Bank</Issuer> <Expiration>04/09</Expiration> </CreditCard> </Payment> ... </Payments>
XML encryption offers several options:
- Encrypt the complete document.
- Encrypt a single element with XML encryption.
- Encrypt the content of an element.
If we encrypt the entire document, the warehouse won’t be able to read the book information, so let’s choose to encrypt the entire credit element and all its content, including sub-elements. The result is shown in Listing 2.
Listing 2 XML document with XML encryption elements.
<?xml version=’1.0’?>
<Payments xmlns=’http://globalbank.org’>
...
<Payment>
<Name>John von Neumann<Name/>
<Book>Gödel, Escher, Bach: An Eternal Golden Braid</Book>
<ISBN>0465026567</ISBN>
<EncryptedData Type=’http://www.w3.org/2001/04/xmlenc#Element’
xmlns=’http://www.w3.org/2001/04/xmlenc#’>
<CipherData>
<CipherValue>
A23B45C56
</CipherValue>
</CipherData>
</EncryptedData>
</Payment>
...
</Payments>
Notice that the entire CreditCard element and all its sub-elements from Listing 1 have been replaced by the EncryptedData element in Listing 2. Included in this EncryptedData element is the CipherValue element that holds the entire encrypted element. The book details remain visible for warehouse personnel, however.
Case 2: SOAP Data Transfer
The second scenario for considering XML encryption is when using web services with SOAP. The SOAP specification defines both an XML vocabulary for packaging and a protocol for receiving and responding to SOAP messages. The protocol component of the SOAP standard includes rules for when a SOAP-compliant server should forward SOAP messages to a final destination.
If you use SSL only to secure your XML/SOAP transmissions, your XML will be decrypted when received by the server and then sent in its original form to the SOAP handler. If the handler is not the final handler, your data will be visible to the intermediary. If the intermediary has been compromised, your data may also be compromised.
If XML encryption is used to secure all or part of the incoming XML, however, your data won’t be exposed—even if the server is compromised. Only the final recipient of the SOAP message will be able to see what’s hidden behind the mask of encryption.
Case 3: Authentication of Digital Signatures
The third scenario for using XML encryption is when you want to authenticate your digitally signed document. Earlier, we looked at how to digitally sign your will so your evil twin couldn’t modify it on the way to your attorney. However, there exists the possibility of a man-in-the-middle attack. This happens when your evil twin, Bob, intercepts your will, rewrites it, and generates a new digital signature, sending both to your attorney. Since the digital signature matches the document, Bob is home free.
The man-in-the-middle attack works because digital signatures address only document integrity, not authentication. Authentication provides the assurance that a document actually originates from the sender.
To authenticate the will so your lawyer knows it came from you, we need to combine digital signatures with public key encryption. As illustrated earlier in Figure 1, this is accomplished by encrypting the digital signature with your private key. Even though anyone can decrypt your message with your public key, that’s perfectly okay because we’re not trying to keep the will secret. We’re just trying to authenticate that the signature is your signature—and not Bob’s. Of course, we could encrypt both the will and the signature with your private key, but for very large messages it may not be cost-effective to encrypt the entire message.
){kind=link}