XML Encryption

The W3C and IETF are working on an XML encryption specification. Java Community Process (www.jcp.org) is working to define a standard Java API for XML Encryption (JSR-106). In our discussion above, we outlined how to use SSL for encryption of messages over the transport. SSL addresses the needs to secure the document over the transport but does not handle the security requirements of a document once it is persisted. It also does not address when different parts of a document require different levels of protection.

The core element in XML encryption is the EncryptedData element, used with the EncryptedKey element to transport encryption keys from the originator to a known recipient. It derives from the EncryptedType abstract type. When an element is encrypted, the EncryptedData element replaces the element in the encrypted version of the XML document. The easiest way to demonstrate XML encryption is by showing unencrypted and encrypted XML documents, as in Listings 15.4 and 15.5.

Listing 15.4: Unencrypted XML document

 <?xml version='1.0'?> <InsuranceInfo xmlns='http://insurance.org/HMOv2'>     <Name>Sylvester James</Name>     <Employer>Planet Fruit</Employer>     <IDCard Deductible='5,000' Currency='TT'>         <Number>XJABAC 34534</Number>         <Issuer>Dispute Insurance</Issuer>         <Expiration>04/02</Expiration>     </IDCard>     <Insured>Soogia Rattan</Insured> </InsuranceInfo> 

Listing 15.5: Encrypted XML document

 <?xml version='1.0'?> <InsuranceInfo xmlns='http://insurance.org/HMOv2'>     <Name>Sylvester James</Name>     <Employer>Planet Fruit</Employer>     <EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element'     xmlns='http://www.w3.org/2001/04/xmlenc#'>         <CipherData><CipherValue>A1B2C3D4E5F</CipherValue></CipherData>     </EncryptedData>     <Insured>Soogia Rattan</Insured> </InsuranceInfo> 

In the above example, we have hidden the currency amounts. Sometimes it is necessary to encrypt the entire document (Listing 15.6).

Listing 15.6: Completely encrypted XML document

 <?xml version='1.0'?>     <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'     Type='http://www.isi.edu/in-notes/iana/assignments/media-types/text/xml'>     <CipherData><CipherValue>B1CH3TR1N1</CipherValue><</CipherData> </EncryptedData> 

Business messages must ensure authenticity (Who was the sender?), data privacy (Was it modified in transit?) and nonrepudiation (Can the sender deny sending it?) So far, we have discussed using Web server authentication for knowing the sender. We have considered use of SSL to secure the transport. We have thought about using either custom or XML encryption to make sure documents cannot be modified by intermediate parties.

In our solution, we have not considered whether we need to support non-repudiation. Flute bank needs to ensure that transactions sent to Flute Bank services come from authorized customers who cannot deny having sent transactions. This can be handled using multiple techniques.

Public key infrastructure (PKI) describes the processes, policies, and standards that govern the issuance and revocation of the certificates and public and private keys that encryption and signing operations use. Public-key cryptography allows Web services to exchange data across an insecure network such as the Internet with the assurance that messages will neither be modified nor inappropriately accessed.

The basis premise is that data is transformed according to an algorithm parameterized by a pair of keys (public and private). Each participant in the exchange has such a pair of keys. Users make their public key freely available to anyone wishing to establish a dialog with their services and keep the other key private and appropriately secured. Information encoded using one key can be decoded using the other. If someone else intercepts a message, it would remain unusable, because the private key is needed decrypt the message.

The advantages of using public-key infrastructure over other approaches based on shared secrets are not only scalability, in not having to distribute the secret to unknown parties in advance, but also the ability to validate the sender, because everyone has a unique private key.

To digitally sign a message, an algorithm that accepts the sender's private key transforms the data in the message. The detransformation can occur in reverse only if it uses the sender's public key, This assures the recipient of the message's true origin. If the data can be confirmed using the sender's public key, it must have been signed using the corresponding private key, to which only the sender has access. A certificate authority provides an assertion of a public key's validity and asserts that it actually does belong to the sender. Otherwise, an impostor could arbitrarily create or steal others' certificates, presenting himself as the owner.

Typically, public-key approaches do not encode an entire message. Instead, they create a small, unique thumbprint of the document, typically referred to as a digest or hash. Hashing algorithms are aware of changes to a source message and therefore provide a way for the recipient to validate that the message has not been altered. The digest is transformed using the sender's private key, creating a digital signature. This also allows the recipient to verify that the sender performed the transformation.

Listed below are some of the implementations of XML encryption:

• Phaos XML: www.phaos.com/e_security/prod_xml.html

• Trust Services Integration Kit: www.xmltrustcenter.org/developer/verisign/tsik/indes.htm

• XML Security Library: www.aleksey.com/xmlsec

• XML Security Suite: www.alphaworks.ibm.com/tech/xmlsecuritysuite