Encryption Syntax

I'm going to give you just a brief overview of what an encrypted XML document looks like. As with digital signatures (which use a lot of the same math), the arithmetic is far too complex for most humans to do by hand. You'll always use a software application or library to encrypt documents. Encrypted XML isn't intended to be authored by a text editor like normal XML.

When a document or portion of a document is encrypted, that part is replaced by an EncryptedData element like the one that follows .

 <EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"   Type="  URI  " MimeType="  MIME type  " Encoding="  URI  ">     <EncryptionMethod Algorithm="  URI  "/>     <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">       <EncryptedKey>  Base64-encoded, encrypted key value  </EncryptedKey>       <ds:KeyName>  Name of the key used to encrypt this data  </ds:KeyName>       <ds:RetrievalMethod>  Where to find the key  </ds:RetrievalMethod>     </ds:KeyInfo>     <CipherData>       <CipherValue>  Base64-encoded, encrypted data  </CipherValue>         or       <CipherReference          URI="http://www.example.com/encrypteddata.dat"/>     </CipherData> </EncryptedData> 

Each EncryptedData element represents one chunk of encrypted XML. This can decrypt to plain text, to a single element, to several elements, or to mixed content. The result of this replacement must be well- formed . That is, you cannot encrypt an attribute alone, or the start-tag of an element but not the end-tag. This is all sensible . It just means that structures you encrypt are the structures found in the XML document. The Type attribute indicates what was encrypted. It can have the following values.

  • http://www.w3.org/2001/04/xmlenc#Element : A single element was encrypted.

  • http://www.w3.org/2001/04/xmlenc#Content : A sequence of XML nodes was encrypted, potentially including any number of elements, text nodes, comments, and processing instructions in any order and combination.

At a minimum, the EncryptedData element has a CipherData child element. This contains either a CipherValue or a CipherReference . A CipherValue contains the encrypted data encoded in Base64. A CipherReference points to the encrypted data using its URI attribute. The data is not included with the document. For example, consider the comic book order from Item 48, which is repeated in Example 49-1.

Example 49-1 An Order Document
 <?xml version="1.0"?> <Order>   <Item type="BackIssue">     <Title>Fables</Title>     <Issue>2</Issue>     <Publisher>DC</Publisher>   </Item>   <Item type="BackIssue">     <Title>Gen 13</Title>     <Issue>46</Issue>     <Publisher>Wildstorm</Publisher>   </Item>   <CreditCard type="VISA">     <Name>Elliotte Rusty Harold</Name>     <Number>5555 3142 2718 2998</Number>     <Expires>       <Month>06</Month>       <Year>2006</Year>     </Expires>   </CreditCard> </Order> 

If I encrypted the content of the CreditCard element, the result would look something like Example 49-2 (depending on the choice of key and algorithm, of course).

Example 49-2 Encrypting the Content of an Element
 <?xml version="1.0"?> <Order>   <Item type="BackIssue">     <Title>Fables</Title>     <Issue>2</Issue>     <Publisher>DC</Publisher>   </Item>   <Item type="BackIssue">     <Title>Gen 13</Title>     <Issue>46</Issue>     <Publisher>Wildstorm</Publisher>   </Item>   <CreditCard type="VISA"><EncryptedData     Id="ed1" Type="http://www.w3.org/2001/04/xmlenc#Content"     xmlns="http://www.w3.org/2001/04/xmlenc#">   <EncryptionMethod     Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>   <CipherData>     <CipherValue>ZPbIV3QYoAK/m1c81yu+37mylmmvFocDas7BxR94FA0qjm/ 6u0GY59lluoclaLiq/fGHXS8P69YShwIaehDGG2n56JS8B0/h3m1AHf5Ozm9zUop gyqn7k8HcXAkB7oAFLiKvHc/R+ZjU8XpVJdCFfTjaJ3Jy4bQNR3TWrbmCTPK5//C WedrnLuebpq2r88/y</CipherValue>   </CipherData>   </EncryptedData>   </CreditCard> </Order> 

This would allow a process that did not have the key to know that the encrypted data is credit card information for a VISA card. However, it would not know the card number, the expiration date, or the cardholder's name.

If I encrypted the entire CreditCard element, the result would look like Example 49-3. Now you don't know for sure that the encrypted data is credit card information unless you know the decryption key.

Example 49-3 Encrypting a Single Element
 <?xml version="1.0"?> <Order>   <Item type="BackIssue">     <Title>Fables</Title>     <Issue>2</Issue>     <Publisher>DC</Publisher>   </Item>   <Item type="BackIssue">     <Title>Gen 13</Title>     <Issue>46</Issue>     <Publisher>Wildstorm</Publisher>   </Item>   <EncryptedData     Id="ed1" Type="http://www.w3.org/2001/04/xmlenc#Element"     xmlns="http://www.w3.org/2001/04/xmlenc#">     <EncryptionMethod        Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>     <CipherData>     <CipherValue>ZPbIV3QYoAK/m1c81yu+37mylmmvFocDas7BxR94FA0qjm/ 6u0GY59lluoclaLiq/fGHXS8P69YShwIaehDGG2n56JS8B0/h3m1AHf5Ozm9zUop gyqn7k8HcXAkB7oAFLiKvHc/R+ZjU8XpVJdCFfTjaJ3Jy4bQNR3TWrbmCTPK5//C WedrnLuebpq2r88/y</CipherValue>     </CipherData>   </EncryptedData> </Order> 

In some cases, it may be useful to include additional information beyond the encrypted data itself. An empty EncryptionMethod element specifies the algorithm that was used to encrypt the data so that it can more easily be decrypted. The Algorithm attribute contains a URI identifying the algorithm. There's no exhaustive list of these because new algorithms continue to be invented, but some common ones include the following:

  • Triple DES : http://www.w3.org/2001/04/xmlenc#tripledes-cbc

  • AES 128 bit : http://www.w3.org/2001/04/xmlenc#aes128-cbc

  • AES 256 bit : http://www.w3.org/2001/04/xmlenc#aes256-cbc

  • AES 192 bit : http://www.w3.org/2001/04/xmlenc#aes192-cbc

Depending on the algorithm, it may be useful to include either the actual key used or the name of the key. If the name of the key is included, presumably the recipient knows how to find the value of that key in some central repository. The actual value of the encryption key may be included for public key/private key systems since knowing the encryption key doesn't help you decrypt the message. Alternately, because public key cryptography is relatively slow, the actual message may be encoded using a symmetric cipher such as DES using a randomly chosen key. The random key is then encoded using the recipient's public key and stored in the key info . None of this information is required for XML encryption. All of it is allowed if you find it useful.

If present, such information is stored in a KeyInfo element in the http://www.w3.org/2000/09/xmldsig# namespace. As the URI suggests, this is the same KeyInfo element used in XML digital signatures. (See Item 48.) It can provide keys by name, reference, or value. Example 49-4 includes the RSA (public) key used to encrypt the data encoded by both name and value. If you have the private key that matches this public key, you can decrypt the information. Nobody else should be able to, at least not easily.

Example 49-4 Bundling Key Info with the Encrypted Data
 <?xml version="1.0"?> <Order>   <Item type="BackIssue">     <Title>Fables</Title>     <Issue>2</Issue>     <Publisher>DC</Publisher>   </Item>   <Item type="BackIssue">     <Title>Gen 13</Title>     <Issue>46</Issue>     <Publisher>Wildstorm</Publisher>   </Item>   <EncryptedData     Id="ed1" Type="http://www.w3.org/2001/04/xmlenc#Element"     xmlns="http://www.w3.org/2001/04/xmlenc#">     <EncryptionMethod        Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>     <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">       <KeyName>Bob</KeyName>       <KeyValue>         <RSAKeyValue>           <Modulus>              V5foK5hhmbktQhyNdy/6LpQRhDUDsTvK+g9Ucj47es9AQJ3U              xA7SEU+e0yQH5rm9kbCDN9o3aPIo7HbP7tX6WOocLZAtNfyx              SZDU16ksL6WjubafOqNEpcwR3RdFsT7bCqnXPBe5ELh5u4VE              y19MzxkXRgrMvavzyBpVRgBUwUl=            </Modulus>           <Exponent>AQAB</Exponent>         </RSAKeyValue>       </KeyValue>     </KeyInfo>     <CipherData>       <CipherValue>          ZPbIV3QYoAK/m1c81yu+37mylmmvFocDas7BxR94FA0qjm/6u0GY59l          luoclaLiq/fGHXS8P69YShwIaehDGG2n56JS8B0/h3m1AHf5Ozm9zUo          vHc/R+ZjU8XpVJdCFfTjaJ3Jy4bQNR3TWrbmCTPK5//CWedrnLuebpq          2r88/y       </CipherValue>     </CipherData>   </EncryptedData> </Order> 

For a symmetric key, you'd normally just use the name you had previously agreed on for the key with the recipient. Exactly how keys are named is beyond the scope of the XML Encryption specification.



Effective XML. 50 Specific Ways to Improve Your XML
Effective XML: 50 Specific Ways to Improve Your XML
ISBN: 0321150406
EAN: 2147483647
Year: 2002
Pages: 144

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net