- Information Security In General
- Securing XML Documents: XML Signature, XML Encryption
- Applying XML Security to Web Services: Web Services Security
- Using XML and Web Services for Security
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Securing XML Documents: XML Signature, XML Encryption
Let's start by looking at the XML security standards. There are several XML security specifications, but the most fundamental ones are XML Signature and XML Encryption. These are also the ones that are most stable—having W3C Recommendation (or very close to having W3C Recommendation) at the time of writing. As you can see below, XML Signature and XML Encryption are actually bundles of a couple of specifications.
XML Signature
XML-Signature Syntax and Processing—W3C Recommendation
Canonical XML (C14N)—W3C Recommendation
Exclusive Canonicalization—W3C Proposed Recommendation (PR)
XML Encryption
XML Encryption Syntax and Processing—W3C Candidate Recommendation (CR)
Decrypt Transform for XML Signature—W3C Candidate Recommendation (CR)
Why do we need these specifications, anyway? We all know that there are already a number of security protocols—for example, SSL/TLS, SSH, and IPSec. For example, SSL/TLS is a very widely used protocol for securing Web traffic; and providing confidentiality, integrity, and authentication. So, if you use SSL/TLS for B2B connection, your business data, expressed as an XML document, will be sufficiently protected while it travels across the Internet. XML Signature and XML Encryption can provide protections on these stored documents.
However, after an XML document is received and stored in memory, SSL/TLS cannot protect the document from unauthorized copying or modification. XML was originally designed as a format of structured documents, so it is natural to protect such documents as stored and persistent data, not as transient data that exists only in a communication flow in a network. For the same reason, SSL/TLS does not provide protection in stored-and-forwarded communication (that is, asynchronous communication such as e-mail and messaging). Thus, SSL/TLS is not enough; we need something different to protect stored XML documents.
You might now ask, "Why not use e-mail security standards such as S/SIME and PGP?" Certainly, these standards can protect stored data by encrypting and signing the data. Unfortunately, these specifications can protect a stored document only as a whole. It is not possible to protect a part of an XML document using S/MIME—to encrypt and sign the Body element of a SOAP envelope, for example. This is because these e-mail security standards treat the contents as a binary object, and has no knowledge of the internal structure of the data.
XML is used for exchanging business documents between companies. Very often, these documents are exchanged between more than two companies. Some of the data in the document must not be seen by one of these companies; for example, a credit card number in a purchase order document should be protected from the eyes of any parties except for the credit card owner and the credit card company. In this case, the "all-or-nothing" protection of e-mail security standards cannot solve the problem. To encrypt or sign a part of an XML document, we need to define these operations—based on the XML structure such as elements and node sets. It is also important that signed documents are not invalidated by XML's parsing and serialization processes. In XML, the same document can be expressed in many different ways as an octet stream (the character encoding can be changed, the attribute order can be changed, and so on) if the document is processed by different XML processors. These changes invalidate a signature if the signature is done as binary data. Two canonicalization specifications, Canonical XML and Exclusive Canonicalization, address these issues.
By combining XML Signature and XML Encryption, you can provide very flexible yet strong protection for your XML document. You can sign and encrypt a sensitive part of the document. You can sign an already encrypted portion of a document as a confirmation of the integrity of the data, without knowing the contents of the data. You can cosign with other signers, or you can countersign an already signed document. If there is encrypted data in a signed document, and it is unclear whether the signature verification should be done after or before decrypting the encrypted data, Decryption Transform for XML Signature can be used to resolve this ordering problem.