Securing Web Services with WS-Security: Demystifying WS-Security, WS-Policy, SAML, XML Signature, and XML Encryption

 <  Day Day Up  >  

As we have mentioned previously, there are times, probably most of the time actually, when XML Signature is an important partner to XML Encryption. The relationship between XML Signature and XML Encryption may be more subtle than you might have originally thought. Because parts of the EncryptedData / EncryptedKey elements are in the clear, they could be changed, making the decryption invalid. For example, Listing 5.13 shows what you might expect to see in an XML document containing XML Encryption.

Listing 5.13. An Example of How <Signature> Enters into XML Encryption Situations to Protect the Integrity of Parts of the <EncryptedData> Elements

<MyDocument> <EncryptedData id="encryptedData1"> <EncryptionMethod Algorithm=". . ." /> <CipherText> <CipherValue>. . .</CipherValue> </CipherText> <KeyInfo> <EncryptedKey> <EncryptionMethod Algorithm=". . ." /> <CipherText> <CipherValue>. . . </CipherValue> </CipherText> <KeyInfo> <X509Data> <X509Subject>O=HisCompany,OU=Technology,CN=Jothy Roesenberg</X509Subject> </X509Data> </KeyInfo> </EncryptedKey> </KeyInfo> </EncryptedData> <Signature> <SignedInfo> <CanonicalizationMethod Algorithm=". . ." /> <SignatureMethod Algorithm=". . ." /> <Reference URI="#encryptedData1"> <DigestMethod Algorithm=". . ." /> <DigestValue>. . .</DigestValue> </Reference> </SignedInfo> <SignatureValue>. . .</SignatureValue> <KeyInfo> <X509Data> <X509Subject>O=MyCompany,OU=Engineering,CN=David Remy</X509Subject> </X509Data> </KeyInfo> </Signature> </MyDocument>

The main point of this example is that the Signature points back up to the EncryptedData element with the ID "encryptedData1" . The objective here is to protect the EncryptedData information from an integrity and authenticity perspective. For example, based on your confidence that the public key is really associated with the sender and recipient (David Remy and Jothy Rosenberg in this example) and that the private key of each has not been compromised, you might be able to reasonably make the following statement about the document: This document was prepared by David Remy (or at least by an individual holding David Remy's private key) and can be read only by Jothy Rosenberg (or at least only by an individual holding Jothy Rosenberg's private key).

One criticism of this approach is that the Signature and EncryptedData elements are detached from each other, and it would be possible to remove the Signature without the recipient inherently knowing that the Signature had ever existed ”perhaps even substituting his signature in place such that the document appears to be authentically originating from another creator/sender. In other words, you need to have a policy for requiring signatures in a certain manner accompanying EncryptedData elements; otherwise , the document is not self-protecting . We describe this subject in more detail later in this chapter. This argument leads you to consider placing the Signature within the EncryptedData . To accomplish this, you first sign the target information and then encrypt it. For example, consider the signed XML in Listing 5.14.

Listing 5.14. Setting Up to Place the <Signature> Element Inside the <EncryptedData> Element, You Sign the <Customer> Element with an Enveloped Signature

<Order> <LineItem sku="82394" quantity="1"> <ProductName>Birdcage</ProductName> </LineItem> <Customer id="customer" custNum="A2345"> <FirstName>Fred</FirstName> <MiddleInit>L</MiddleInit> <LastName>Jones</LastName> <CreditCard> <CreditCardType>VISA</CreditCardType> <CreditCardNumber>43343456343566</CreditCardNumber> <CreditCardExpiration>10/08</CreditCardExpiration> </CreditCard> <Signature> <SignedInfo> <CanonicalizationMethod Algorigthm=". . ." /> <SignatureMethod Algorithm=". . ." /> <Reference URI="#customer" > <Transform Algorithm=".../#envelopedSignature" /> <DigestMethod Algorithm=". . ." /> <DigestValue>. . .</DigestValue> </Reference> </SignedInfo> <SignatureValue>. . . </SignatureValue> <KeyInfo> <X509Data> <X509SubjectName>O=MyCompany,OU=Engineering,CN=David Remy</X509SubjectName> </X509Data> </KeyInfo> </Signature> </Customer> </Order>

In this example, the Customer element has been signed with an Enveloped Signature . Now assume that you want the Customer element to be encrypted. The document would then look like Listing 5.15 after encryption.

Listing 5.15. Protecting the <Signature> Element Inside the <EncryptedData> Element, Making the <Signature> Element Not Even Visible

<Order> <LineItem sku="82394" quantity="1"> <ProductName>Birdcage</ProductName> </LineItem> <EncryptedData id="encryptedData1"> <EncryptionMethod Algorithm=". . ." /> <CipherText> <CipherValue>. . . </CipherValue> <CipherText> <KeyInfo> <EncryptedKey> <EncryptionMethod Algorithm=". . ." /> <CipherText> <CipherValue>. . .</CipherValue> </CipherText> <KeyInfo> <X509Data> <X509Subject>O=HisCompany,OU=Technology,CN=Jothy Rosenberg</X509Subject> </X509Data> </KeyInfo> </EncryptedKey> </KeyInfo> </EncryptedData> </Order>

This approach has a couple of advantages. First, the Signature element, which could contain sensitive data in some circumstances, is not visible at all. For example, you might use this approach if you don't want any reader of the document to know that you are the originator of the content and yet still allow the recipient to know and validate the originator. Second, the order of processing may be clearer. In this example, obviously, the decryption would occur, and then the signature verification would occur. In the first example in this section, the order of processing is not clear (we discuss how to surmount this issue in the next section "The Decryption Transform for XML Signature").

The problem with this approach is that the integrity of the EncryptedData and related elements are not guaranteed . It would still be possible for someone to mess around with these elements and break the encryption ”or even to substitute an entire new EncryptedData block.

As you can see, there are trade-offs with both approaches, and you will have to make your implementation decision based on the context of your specific situation. In high-security situations, you might implement a multi-layered approach that includes signatures, encryption, and then signatures again. As you determine your policy solution for XML Signature and XML Encryption in each situation, the most significant technical issue becomes telling the signature and encryption processor the sequence to process the XML Encryption and XML Signature. Consider the first XML Encryption and Signature example shown in this section. How would a processor know whether to process the XML Encryption or the XML Signature first? If the EncryptedData element were processed first, the signature would break because what was signed was the EncryptedData element itself. This sequencing requirement brought about the need for a new Transform introduced into XML Signature.

The Decryption Transform for XML Signature

The XML Decryption Transform is an additional Transform for XML Signatures [1] that enables an XML Signature processing engine to recognize EncryptedData structures that were encrypted prior to the XML Signature being applied so that they are not decrypted when validating the signature. An example will help you to understand this concept. Let's use an example similar to the one that is used in the specification. Sam is purchasing an item from Sally's furniture store, and MoneyBags Bank is being passed account information that will be used to verify and debit the account. In this scenario, the requirement is that Sally must be unable to read Sam's account information, so she simply forwards it to the bank. To accomplish this, Sam (or more correctly, the program Sam is using to submit this order) will encrypt his account information to MoneyBags Bank and then sign and encrypt the entire XML document so that Sally will know that a) Sam is verified to be the one who sent the order, and b) the order has not been changed in transit. Sam's order for two canvas hammocks and a matching table looks like Listing 5.16.

[1] The Decryption Transform for XML Signature has its own specification at http://www.w3.org/TR/2002/PR-xmlenc-decrypt-20021003.

Listing 5.16. An Order with Payment Information That Needs to Be Protected

<Order> <CustInfo> <Name>Sam Spade</Name> <Address>123 Anywhere Lane, James, MO 34586</Address> </CustInfo> <LineItems> <LineItem skuID="12345"> <Name>Country Hammock</Name> <Quantity>2</Quantity> <Price>.00USD</Price> </LineItem> <LineItem skuID="12346"> <Name>Country Hammock Table</Name> <Quantity>1</Quantity> <Price>.00USD</Price> </LineItem> </LineItems> <PaymentInfo> <Bank>MoneyBags Bank</Bank> <AccountNumber>13245459</AccountNumber> <Amount>0.00USD</Amount> </PaymentInfo> </Order>

Now, in Listing 5.17, Sam encrypts the sensitive bank account information using MoneyBag Bank's public key and using content-based encryption so that the attribute "MoneyBags" stays in the clear and Sally will know which bank to route it to.

Listing 5.17. <Order> from Listing 5.16 with the Confidential Payment Information Encrypted

<Order> <CustInfo> <Name>Sam Spade</Name> <Address>123 Anywhere Lane, James, MO 34586</Address> </CustInfo> <LineItems> <LineItem skuID="12345"> <Name>Country Hammock</Name> <Quantity>2</Quantity> <Price>.00USD</Price> </LineItem> <LineItem skuID="12346"> <Name>Country Hammock Table</Name> <Quantity>1</Quantity> <Price>.00USD</Price> </LineItem> </LineItems> <PaymentInfo bank="MoneyBags"> <EncryptedData Type="http://www.w3.org/2000/09/xmldsig#content"> <EncryptionMethod Algorithm="http://www.w3.org/2001/04/ xmlenc#aes128-cbc"> <CipherData> <CipherValue>. . .</CipherValue> </CipherData> </EncryptedData> </PaymentInfo> </Order>

Next, in Listing 5.18, Sam signs the entire message using an Enveloped Signature to demonstrate to Sally that he stands behind what is being sent and to provide for message integrity:

Listing 5.18. <Order> from Listing 5.17 Now Signed with an Enveloped Signature for Integrity

<Order> <CustInfo> <Name>Sam Spade</Name> <Address>123 Anywhere Lane, James, MO 34586</Address> </CustInfo> <LineItems> <LineItem skuID="12345"> <Name>Country Hammock</Name> <Quantity>2</Quantity> <Price>.00USD</Price> </LineItem> <LineItem skuID="12346"> <Name>Country Hammock Table</Name> <Quantity>1</Quantity> <Price>.00USD</Price> </LineItem> </LineItems> <PaymentInfo bank="MoneyBags"> <EncryptedData id="payInfo" Type="http://www.w3.org/2000/09/ xmldsig#content"> <EncryptionMethod Algorithm=" http://www.w3.org/2001/04/ xmlenc#aes128-cbc" /> <CipherData> <CipherValue>. . .</CipherValue> </CipherData> <KeyInfo> <KeyName>MoneyBags, Inc.</Keyname> </KeyInfo> </EncryptedData> </PaymentInfo> <Signature> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/ xml-exc-c14n#" /> <SignatureMethod Algorithm="http://www.w3.org/2000/09/ xmldsig#rsa-sha1" /> <Reference URI=""> <Transform=http://www.w3.org/2000/09/ xmldsig#enveloped-signature" /> <Transform="http://www.w3.org/2002/07/decrypt#XML"> <Except URI="#payInfo"> </Transform> </Reference> </SignedInfo> <SignatureValue>. . .</SignatureValue> <KeyInfo> <KeyName>Sam Spade</KeyName> </KeyInfo> </Signature> </Order>

As you can see in this example, Sam signed the whole Order ( Reference URI="" ) with an Enveloped Signature but also added a Decryption Transform . This Decryption Transform has an Except element that points to the encrypted data "payInfo" . It says to the Signature processor, "Decrypt everything except these URIs before validating the signature." Next, in Listing 5.19, Sam will encrypt the entire message, minus the outer Order element and the Signature (which is a little contrived for this example), to send to Sally:

Listing 5.19. <Order> from Listing 5.18 Now with the Entire Message Except for <Signature> Encrypted

<Order> <EncryptedData id="myOrder" Type="http://www.w3.org/2000/09/ xmldsig#content"> <EncryptionMethod Algorithm="http://www.w3.org/2001/04/ xmlenc#aes128-cbc"> <CipherData> <CipherValue>. . .</CipherValue> </CipherData> <KeyInfo> <KeyName>MoneyBags, Inc.</Keyname> </KeyInfo> </EncryptedData> <Signature> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/ xml-exc-c14n#" /> <SignatureMethod Algorithm="http://www.w3.org/2000/09/ xmldsig#rsa-sha1" /> <Reference URI=""> <Transform=http://www.w3.org/2000/09/ xmldsig#enveloped-signature" /> <Transform="http://www.w3.org/2002/07/decrypt#XML"> <Except URI="#payInfo"> </Transform> </Reference> </SignedInfo> <SignatureValue>. . .</SignatureValue> <KeyInfo> <KeyName>Sam Spade</KeyName> </KeyInfo> </Signature> </Order>

The preceding then is the final form of the message sent to Sally. For it to be processed correctly, the processor has to unwind it in the right order. The XML Security processor that Sally is using must be both XML Encryption and XML Signature aware. This processor first attempts to process the Signature element. The Signature references the Order element, and within the Decryption Transform , it references the "payInfo" element. Because it cannot locate the #payInfo element, it must assume that #payInfo is within the #myOrder EncryptedData element. Because there are no Signature elements with an Except #myOrder Transform, #myOrder is decrypted. This results in the intermediate XML structure shown earlier but repeated in Listing 5.20.

Listing 5.20. Intermediate Step in Unwinding the <Order> After Initial Decryption but Before Signature Processing

<Order> <CustInfo> <Name>Sam Spade</Name> <Address>123 Anywhere Lane, James, MO 34586</Address> </CustInfo> <LineItems> <LineItem skuID="12345"> <Name>Country Hammock</Name> <Quantity>2</Quantity> <Price>.00USD</Price> </LineItem> <LineItem skuID="12346"> <Name>Country Hammock Table</Name> <Quantity>1</Quantity> <Price>.00USD</Price> </LineItem> </LineItems> <PaymentInfo bank="MoneyBags"> <EncryptedData id="payInfo" Type="http://www.w3.org/2000/09/ xmldsig#content"> <EncryptionMethod Algorithm=" http://www.w3.org/2001/04/ xmlenc#aes128-cbc"> <CipherData> <CipherValue>. . .</CipherValue> </CipherData> <KeyInfo> <KeyName>MoneyBags, Inc.</Keyname> </KeyInfo> </EncryptedData> </PaymentInfo> <Signature> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/ xml-exc-c14n#" /> <SignatureMethod Algorithm="http://www.w3.org/2000/09/ xmldsig#rsa-sha1" /> <Reference URI=""> <Transform=http://www.w3.org/2000/09/ xmldsig#enveloped-signature" /> <Transform="http://www.w3.org/2002/07/decrypt#XML"> <Except URI="#payInfo"> </Transform> </Reference> </SignedInfo> <SignatureValue>. . .</SignatureValue> <KeyInfo> <KeyName>Sam Spade</KeyName> </KeyInfo> </Signature> </Order>

Now the Signature processing can be attempted again. This time the #payInfo is resolved, and there are no other EncryptedData elements. Note if there had been other EncryptedData elements, they would have been decrypted prior to signature validation. The Signature is validated correctly, and Sally extracts the information destined for MoneyBags Bank for payment validation, wraps it in a PaymentRequest , and signs the message with her private key, as shown in Listing 5.21.

Listing 5.21. <PaymentRequest> Created from Signature Validation of the Payment Information Embedded in the Incoming <Order>

<PaymentRequest> <PaymentInfo bank="MoneyBags"> <EncryptedData id="payInfo" Type="http://www.w3.org/2000/09/ xmldsig#content"> <EncryptionMethod Algorithm=" http://www.w3.org/2001/04/ xmlenc#aes128-cbc" /> <CipherData> <CipherValue>. . .</CipherValue> </CipherData> <KeyInfo> <KeyName>MoneyBags, Inc.</Keyname> </KeyInfo> </EncryptedData> </PaymentInfo> <Signature> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/ xml-exc-c14n#" /> <SignatureMethod Algorithm="http://www.w3.org/2000/09/ xmldsig#rsa-sha1" /> <Reference URI=""> <Transform=http://www.w3.org/2000/09/ xmldsig#enveloped-signature" /> <Transform="http://www.w3.org/2002/07/decrypt#XML"> <Except URI="#payInfo"> </Transform> </Reference> </SignedInfo> <SignatureValue>. . .</SignatureValue> <KeyInfo> <KeyName>Sally Brown</KeyName> </KeyInfo> </Signature> </PaymentRequest>

Notice that the Decryption Transform pointing to #payInfo is still there because it is not the decrypted payment information that Sally is signing. By signing this, Sally is attesting that she has received this encrypted data; she is saying nothing about the integrity of the internal plaintext. MoneyBags Bank will now receive this message, process it, and return a signed acknowledgement to Sally that payment was processed successfully. We will spare you the acknowledgement back to Sally and from Sally back to Sam, but, of course, the messages would be signed and possibly partially encrypted in a similar manner to the message shown previously.

As you can see from these examples, in practice XML Signature and XML Encryption become closely related when you consider documents that flow through a workflow or documents that are exchanged in a SOAP message.

XML Encryption and XML Signature Strategies

In our opinion, you will most often want to encrypt and then sign when working at the message security level (such as in WS-Security, discussed in Chapter 7), and sign and then encrypt when working with information that will be viewable by a person. The reasoning here is that when a person is viewing a piece of information, what is signed should be representative of what the person saw (as mentioned in Chapter 4), thus encryption before signing would violate this principle. However, with message-level integrity, the server attests to the integrity of the message bits themselves , and this concept is not violated by signing encrypted data.

You should strongly consider signing the EncryptedData elements even when your primary requirement is encryption. Although the additional XML Signature does not make the encryption any stronger, it increases the reliability and robustness of your encryption because you can be confident that the configuration parameters (for example, EncryptionMethod ) and the encrypted content are what the sender intended to send.

In some scenarios, signing the encrypted data could leave a security hole in that the encryption is not tied directly to the signature (although the signature is tied to the encryption). This violates a design goal of having a " self-describing " security mechanism such that traversing a document, discovering security artifacts, and validating them should, in the end, if there are no validation errors, result in a secure XML document.

XML Encryption and XML Schema

As described in Chapter 2, "The Foundations of Web Services," XML Schemas are used to validate the structure and data types of elements in a document. Use of XML Encryption results in EncryptedData elements that fold in and hide sets of elements, which then makes the original underlying XML Schema no longer valid. The external structure just doesn't match the new XML structure after the EncryptedData elements have been introduced and the original elements hidden. Using current XML Schema technology, a new schema would be required for each possible persistent layer of decryption until the document is fully decrypted. For example, say you have a document in a workflow situation, and it is going to the Receiving department, the Purchasing department, and finally to the department that ordered an item. You encrypted part of the document for each of these three recipients. To achieve schema validation at each stage, you would have to create three different schemas that represent the decrypted state for each department.

Some people in the standards world argue that there needs to be a way to designate elements as encryptable in XML Schemas, therefore allowing the possibility of a single XML Schema across all the different states of encryption. This work is in progress, and it is not clear that this idea has momentum. Therefore, you might need a schema for each stage of decryption for now ”or, more likely, go without XML Schema validation.

 <  Day Day Up  >  

Категории