第 12 章 Web 服务加密的模式

CHAPTER 12 Patterns for Web Services Cryptography

He told me that toward 1886 he had devised a new system of enumeration and that in a very few days he had gone slightly over twenty-four thousand. He had not written it down, for what he had thought just once would not be erased. His first stimulus, I believe, had been his discontent with the fact that ‘thirty-three Uruguayans’ required two symbols and three words, rather than a single word and a single symbol. Later he applied his extravagant principle to the other numbers. In place of seven thousand thirteen, he would say (for example) Máximo Perez; in place of seven thousand fourteen, The Railway; other numbers were Luis Melián Lafinur, Olimar, sulphur, Clubs, The Whale, Gas, The Cauldron, Napoleon, Agustín Vedia. In lieu of five hundred, he would say nine. Each word had a particular sign, a species of mark; the last were very complicated…1

Jorge Luis Borges, ‘Funes el memorioso’, http://www.literatura.us/borges/funes.html

12.1 Introduction

Information can be captured and read during its transmission. A message can also be modified or replayed. How can we protect this information from such attacks? Encryption provides message confidentiality by transforming readable data (plain text) into an unreadable format (cipher text) that can be understood only by the intended recipient after decryption, the inverse function that makes the encrypted information readable again. There are two types of encryption: symmetric and asymmetric. In symmetric encryption a common key is used for both encryption and decryption. In asymmetric encryption a public/private key pair is used for encryption/decryption; the sender encrypts the information using the receiver’s public key, while the receiver uses their private key to decrypt the ciphered text.

How can we prove that a message came from a specific user? Digital signatures use public-key cryptography to provide message authentication by proving that a message was sent indeed from a specific sender [dig][sta06]. The sender encrypts the message and uses their private key to sign it. In this case, the signature has at least the same length as the message. This works, but it wastes bandwidth and time. Thus, we need to reduce the length of the message before signing it. This can be done by producing a digest through hashing. When the receiver gets the signed message, they verify the signature by decrypting it using the sender’s public key, thus proving that the message was encrypted by the sender.

Digital signatures can also provide message integrity, by verifying whether a message was modified during its transmission. They can also protect the integrity of and verify the origin of a digital document, for example a certificate, or of programs. Digital signatures finally provide non-repudiation: the sender cannot deny having sent the message they signed. In several countries, including the US, digital signatures have legal validity.

Web services that exchange XML messages can be targets of similar attacks. Some security standards have been developed to correctly apply encryption functions and thus reduce security risks. XML Encryption is one of the basic standards in securing web services. It describes how to encrypt/decrypt an entire XML message, part of an XML message, or an external object linked to the message, and how to represent the encrypted content, and information such as the encryption algorithm and key, in XML format.

The XML Signature standard is a joint effort between the World Wide Web Consortium (W3C) and the Internet Engineering Task Force (ITEF). XML Signature describes how to digitally sign an entire XML message, part of an XML message, or an external object. XML Signature also includes hashing, but the pattern name follows the name of the standard. Because XML documents can have the same contents but in different layouts, we need to convert the documents into a canonical form before we apply digital signatures. XML Signature solves the same problem as the DIGITAL SIGNATURE WITH HASHING pattern (page 301), but in a more specialized context.

WS-Security is an OASIS standard that describes how SOAP messages can be secured through message integrity, message authentication and message confidentiality [OAS06b]. WS-Security is a flexible protocol that supports different formats of security tokens, different encryption technologies and different signature formats. WS-Security does not define new security mechanisms, but it leverages existing technologies such as XML Encryption, XML Signature, and security tokens, for example Kerberos tickets and X.509 certificates. We describe this standard in the form of a pattern. It has already been applied in a variety of applications, such as the travel industry [Nak05].

We present three abstract cryptographic patterns here:

• SYMMETRIC ENCRYPTION protects message confidentiality by making a message unreadable to those that do not have access to the key. Symmetric encryption uses the same key for encryption and decryption.
• ASYMMETRIC ENCRYPTION provides message confidentiality by keeping information secret in such a way that it can only be understood by intended recipients who have access to the valid key. In asymmetric encryption, a public/private key pair is used for encryption and decryption respectively.
• DIGITAL SIGNATURE WITH HASHING allows a principal to prove that a message was originated from it. It also provides message integrity by indicating whether a message was altered during transmission.

We then present patterns for encryption in web services. Figure 12.1 shows how these patterns relate to the patterns of Chapter 11:

Figure 12.1: Pattern diagram for web service security standards and abstract cryptographic patterns

• XML ENCRYPTION describes a process to apply encryption functions to XML data, keeping a correct XML syntax.
• XML SIGNATURE provides a means of identifying the source of the XML message (message authentication), and also provides message integrity.
• WS-SECURITY describes how to secure SOAP messages, applying XML security technologies such as XML ENCRYPTION and XML SIGNATURE. It also describes how to embed different security tokens. Security tokens provides authentication by proving one’s identity (certificates or SAML assertions are examples).

Figure 12.1 also shows the abstract patterns that provide the basis for the more specialized XML patterns.

Symmetric Encryption and XML Encryption come from [Has09b]. Digital Signature with Hashing and XML Signature appeared in [Has09a]. WS-Security appeared in [Has09c]. All these patterns, as well as Asymmetric Encryption, come from Keiko Hashizume’s MS Thesis.

Patterns for WS-Secure Conversation and WS-Federation were produced after we had completed this book: see [Aja 13] and [Aja 12].

12.2 Symmetric Encryption

Encryption protects message confidentiality by making a message unreadable to those that do not have access to the key. Symmetric encryption uses the same key for encryption and decryption.

EXAMPLE

Alice in the purchasing department regularly sends purchase orders to Bob in the distribution office. A purchase order contains sensitive data such as credit card numbers and other company information, so it is important to keep it secret. Eve can intercept her messages and may try to read them to get the confidential information. As part of her work Alice needs to communicate with only a few employees in the company.

CONTEXT

Applications that exchange sensitive information over insecure channels and where the number of users and applications is not very large.

PROBLEM

Applications that communicate with external applications interchange sensitive data that may be read by unauthorized users while they are in transit. Clearly, if we send sensitive information, we are exposing confidential information and we may be risking the privacy of many individuals. How can we protect messages from being read by intruders?

The solution to this problem must resolve the following forces:

• Confidentiality. Messages may be captured while they are in transit, so we need to prevent unauthorized users from reading them by hiding the information in the message.
• Convenient reception. The hidden information should be revealed conveniently to the receiver.
• Protocol. We need to apply the solution properly, or it will not be able to withstand attacks (there are several ways to attack a method of hiding information).
• Performance. The time to hide and recover the message should be acceptable.
• Security. In some cases we need to have a very high level of security.

SOLUTION

We can prevent unauthorized users from reading messages by hiding the information in the message using symmetric cryptographic encryption. Symmetric encryption transforms a message in such a way that it can only be understood by the intended receiver after applying the reverse transformation using a valid key. The transformation process at the sender’s end is called encryption, while the reverse transformation process at the receiver’s end is called decryption.

The sender applies an encryption function (E) to the message (M) using a key (k); the output is the cipher text (C):

equation

When the cipher text (C) is delivered, the receiver applies a decryption function (D) to the cipher text using the same key (k) and recovers the message:

equation

STRUCTURE

Figure 12.2 shows the class diagram for the SYMMETRIC ENCRYPTION pattern. A Principal may be a user or an organization that is responsible for sending or receiving messages. This Principal may have the roles of Sender or Receiver. A Sender may send a Message and/or an EncryptedMessage to a Receiver with which it shares a secret Key.

Figure 12.2: Class diagram for SYMMETRIC ENCRYPTION pattern

The Encryptor creates the EncryptedMessage that contain the cipher text using the shared Key provided by the sender, while the Decryptor deciphers the encrypted data into its original form using the same Key. Both the Encryptor and Decryptor use the same Algorithm to encipher and decipher a message.

DYNAMICS

We describe the dynamic aspects of the SYMMETRIC ENCRYPTION pattern using sequence diagrams for the use cases ‘Encrypt a message’ and ‘Decrypt a message’.

Use Case: Encrypt a Message – Figure 12.3

Figure 12.3: Sequence diagram for the use case ‘Encrypt a message’

Use Case: Decrypt an Encrypted Message – Figure 12.4

Figure 12.4: Sequence diagram for the use case ‘Decrypt an encrypted message’

IMPLEMENTATION

• Use the Strategy pattern [Gam94] to select different encryption algorithms. Selection could be based on speed, computational resources, key length or memory constraints. The selection could happen when instantiating the pattern in an application, or dynamically according to environmental parameters.
• The designer should choose well-known algorithms such as AES (Advanced Encryption Standard) [Fed01] and DES (Data Encryption Standard) [Fed99]. Books such as [Sta06] describe their features and criteria for selection.
• Encryption can be implemented in different applications, such as in e-mail communication, distribution of documents over the Internet, or web services. In these applications we may need to encrypt an entire document or just its body. However, in web services we may want to encrypt specific elements of a message.
• Both the sender and the receiver have to previously agree what cryptographic algorithms they support, and they both must have the same key. This is the key distribution problem, which can be handled in several ways.
• A key management strategy is needed, including key generator, storage and distribution. This strategy should generate keys that are as random as possible, or an attacker who captures some messages might be able to deduce the key. The key should be properly protected, or an attacker who penetrates the operating system might be able to get it. Timely and secure key distribution is obviously very important.
• A long encryption key should be used (at least 64 bits). Only brute force is known to work against the DES and AES algorithms, for example: using a short key would let an attacker generate all possible keys. Of course, this might change and the repertoire of algorithms may need to be updated.

EXAMPLE RESOLVED

Alice now encrypts the purchase orders she sends to Bob. The purchase order’s sensitive data is now unreadable by Eve. Eve can try to apply to it all possible keys, but if the algorithm has been well-chosen and well-implemented, Eve cannot read the confidential information. Since Alice only needs to communicate with a few people within the company, key distribution is rather easy.

CONSEQUENCES

The SYMMETRIC ENCRYPTION pattern offers the following benefits:

• Only receivers who possess the shared key can decrypt a message, transforming it into a readable form. A captured message is unreadable to the attacker. This also makes attacks based on modifying a message very hard.
• The strength of a cryptosystem is based on the secrecy of a long key [Sta06]. The cryptographic algorithms are publicly known, so the key should be kept protected from unauthorized users.
• It is possible to select from several encryption algorithms the one suitable for the application’s needs.
• Encryption algorithms that take an acceptable time to encrypt messages exist.

The pattern also has the following potential liabilities:

• The pattern assumes that the shared key is distributed in a secure way. This may not be easy for large groups of nodes exchanging messages. Asymmetric cryptography can be used to solve this problem.
• Cryptographic operations are computationally intensive and may affect the performance of the application. This is particularly important for mobile devices.
• Encryption does not provide data integrity. The encrypted data can be modified by an attacker: other means, such as hashing, are needed to verify that the message was not changed.
• Encryption does not prevent a replay attack, because an encrypted message can be captured and resent without being decrypted. It is better to use another security mechanism, such as time stamps or Nonces, to prevent this attack.

KNOWN USES

SYMMETRIC ENCRYPTION has been widely used in different products.

• GNuPG [Gnu] is free software that secures data from eavesdroppers.
• OpenSSL [Ope1] is an open source toolkit that encrypts and decrypts files.
• Java Cryptographic Extension [SunA] provides a framework and implementations for encryption.
• The .NET framework [Mic07] provides several classes to perform encryption and decryption using symmetric algorithms.
• XML Encryption [W3C02] is one of the foundation web services security standards that defines the structure and process of encryption for XML messages.
• Pretty Good Privacy (PGP), a set of programs used mostly for e-mail security, includes methods for symmetric encryption and decryption [PGP].

SEE ALSO

• The Secure Channel Communication pattern [Bra00] supports the encryption/decryption of data. This pattern describes encryption in more general terms: it does not distinguish between asymmetric and symmetric encryption. Another version is given in [Sch06b]. An extension of these patterns is given in [Via05].
• The Strategy pattern [Gam94] describes how to separate the implementation of related algorithms from the selection of one of them. This pattern can be used to select an encryption algorithm dynamically.
• ASYMMETRIC ENCRYPTION is commonly used to distribute keys (see below).
• Patterns for key management are given in [Leh02].

12.3 Asymmetric Encryption

Asymmetric encryption provides message confidentiality by keeping information secret in such a way that it can only be understood by intended recipients who have the access to the valid key. In asymmetric encryption, a public/private key pair is used for encryption and decryption respectively.

EXAMPLE

Alice wants to send a personal message to Bob. They have not met each other to agree upon a shared key. Alice wants to keep the message secret, since it contains personal information. Eve can intercept Alice’s messages, and may try to obtain the confidential information.

CONTEXT

Applications that exchange sensitive information over insecure networks.

PROBLEM

Applications that communicate with external applications interchange messages that may contain sensitive information. These messages can be intercepted and read by imposters during transmission. How can we send sensitive information securely over insecure channels?

The solution to this problem must resolve the following forces:

• Confidentiality. Messages may be captured while they are in transit, so we need to prevent unauthorized users from reading them by hiding the information the message contains. Hiding information also makes replaying of messages by an attacker harder to perform.
• Reception. The hidden information should be revealed conveniently to the receiver.
• Protocol. We need to apply the solution properly, or it will not be able to withstand attacks (there are several ways to attack a method of hiding information).
• Performance. The time to hide and recover the message should be acceptable.
• Key distribution. Two parties may want to communicate to each other, but they have not agreed on a shared key: we need a way to send messages without establishing a common key.

SOLUTION

Apply mathematical functions to a message to make it unreadable to those that do not have a valid key.

This approach uses a key pair: private and public key. The sender encrypts (E) the message (M) using the receiver’s public key (PuK), which is accessible by anyone. The result of this process is cipher text (C):

equation

On the other side, the receiver decrypts (D) the cipher text (C) using their private key (PrK) to recover the plain message (M):

equation

STRUCTURE

Figure 12.5 shows the class diagram for the ASYMMETRIC ENCRYPTION pattern. A Principal may be a user or an organization that is responsible for sending or receiving messages. The Principal may have the roles of Sender or Receiver. A Sender may send a Message and/or an EncryptedMessage to a Receiver with which it shares a secret key.

Figure 12.5: Class diagram for the ASYMMETRIC ENCRYPTION pattern

A Principal has one or more KeyPairs that are composed of a private key, kept secret by its owner, and a public key. which is publicly published. PublicKeyRepository is a repository that contains a list of public keys where users can register and/or access public keys. These two keys are mathematically related, so while one encrypts, the other decrypts. However, it is not feasible to deduce a private key from its corresponding public key.

The Encryptor creates the EncryptedMessage that contain the cipher text using the public key of the Receiver provided by the sender, while the Decryptor deciphers the encrypted data into its original form using its private key. Both the Encryptor and Decryptor use the same Algorithm to encipher and decipher a message.

DYNAMICS

We describe the dynamic aspects of the ASYMMETRIC ENCRYPTION pattern using sequence diagrams for the following use cases: ‘Encrypt a message’ and ‘Decrypt a message’.

Use Case: Encrypt a Message – Figure 12.6

Figure 12.6: Sequence diagram for the use case ‘Encrypt a message’

Use Case: Decrypt an Encrypted Message – Figure 12.7

Figure 12.7: Sequence diagram for the use case ‘Decrypt an encrypted message’

IMPLEMENTATION

• Use the Strategy pattern [Gam94] to select different encryption algorithms.
• The designer should choose well-known algorithms such as RSA [Riv78].
• Encryption can be implemented in different applications, such as in e-mail communication, distribution of documents over the Internet, or web services. In these applications we are able to encrypt an entire document. However, in web services we can encrypt parts of a message.
• Both the sender and the receiver have to previously agree what cryptographic algorithms they support.
• A good key pair generator is very important. It should generate key pairs for which the private key cannot be deduced from the public key.

EXAMPLE RESOLVED

Alice now can look up Bob’s public key and encrypt the message using this key. Since Bob keeps his private key secret, he is the only one who can decrypt Alice’s message. Eve cannot understand the encrypted data, since Eve does not have access to Bob’s private key.

CONSEQUENCES

The ASYMMETRIC ENCRYPTION pattern offers the following benefits:

• Asymmetric encryption does not require a secret key to be shared among all the participants. Anyone can look up the public key in the repository and send messaged to the owner of the public key.
• Only recipients that possess the corresponding private key can make the encrypted message readable again.
• The strength of a cryptosystem is based on the secrecy of a long key [Sta06]. The cryptographic algorithms are known to the public, so the private key should be kept protected from unauthorized users.
• It is possible to select from several encryption algorithms the one suitable for the application’s needs.
• Encryption algorithms that take an acceptable time to encrypt messages exist.

The pattern also has the following potential liabilities:

• Cryptography operations are computationally intensive and may affect the performance of the application. Asymmetric encryption is slower than symmetric encryption. It is best to use a combination of both algorithms: asymmetric encryption for key distribution, and symmetric encryption for message exchange.
• Encryption does not provide data integrity. The encrypted data can be modified by an attacker: other means, such as hashing, are needed to verify that a message has not been changed.
• Encryption does not prevent a replay attack, because an encrypted message can be captured and resent without being decrypted. It is recommended to use another security mechanism, such as timestamps or Nonces, to prevent this attack.
• This pattern assumes that a public key belongs to the person who they claim to be. How can we know that this person is not impersonating another? To confirm that someone is who they say they are, we can use certificates issued by a certification authority (CA). If the CA is not trustworthy, we may lose security.

KNOWN USES

ASYMMETRIC ENCRYPTION has been widely used in different products.

• GNuPG [Gnu] is free software that secures data from eavesdroppers.
• Java Cryptographic Extension [SunA] supports a variety of algorithms, including asymmetric encryption.
• The .NET framework [Mic07] provides several classes to perform asymmetric encryption and decryption.
• XML Encryption [W3C02] is one of the foundation web services security standards that defines the structure and process of encryption for XML messages. This standard supports both types of encryption: symmetric and asymmetric encryption.
• Pretty Good Privacy (PGP) uses asymmetric encryption and decryption as one of its process to secure e-mail communication [PGP].

SEE ALSO

• The Secure Channel Communication pattern [Bra00] supports the encryption/decryption of data. This pattern describes encryption in more general terms: it does not distinguish between asymmetric and symmetric encryption. Another version is given in [Sch06b].
• The Strategy pattern [Gam94] describes how to separate the implementation of related algorithms from the selection of one of them. This pattern can be used to select an encryption algorithm dynamically.
• Predicate-based encryption is a family of public key encryption schemes; patterns for them are described in [Mui 12].

12.4 Digital Signature with Hashing

The DIGITAL SIGNATURE WITH HASHING pattern allows a principal to prove that a message was originated from it. It also provides message integrity, by indicating whether a message was altered during transmission.

EXAMPLE

Alice in the sales department wants to send a product order to Bob in the production department. The product order does not contain sensitive data such as credit card numbers, so it is not important to keep it secret. However, Bob wants to be certain that the message was created by Alice, so he can charge the order to her account. Also, because this order includes the quantity of items to be produced, an unauthorized modification to the order will make Bob manufacture the wrong quantity of items. Eve is a disgruntled employee who can intercept the messages and may want to attempt this kind of modification to hurt the company.

CONTEXT

People or systems often need to exchange documents or messages through insecure networks and need to prove their origin and integrity. Stored legal documents need to be kept without modification and with indication of their origin. Software sent by a vendor through the Internet is required to prove its origin.

We assume that those exchanging documents have access to a public key system where a principal possesses a key pair: a private key that is secretly kept by the principal, and a public key that is in a publicly-accessible repository. We assume that there is a mechanism for the generation of these key pairs and for the distribution of public keys; that is, a public key infrastructure (PKI).

PROBLEM

In many applications we need to verify the origin of a message (message authentication). Since an imposter may assume the identity of a principal, how can we verify that a message came from a particular principal? Also, messages that travel through insecure channels can be captured and modified by attackers. How can we know that the message or document that we are receiving has not been modified?

The solution to this problem must resolve the following forces:

• For legal or business reasons we need to be able to verify who sent a particular message. Otherwise, we may not be sure of its origin, and the sender may deny having sent it (repudiation).
• Messages may be altered during transmission, so we need to verify that the data is in its original form when it reaches its destination.
• The length of the signed message should not be significantly larger than the original message, otherwise we would waste time and bandwidth.
• Producing a signed message should not require large computational power or take a long time.

SOLUTION

Apply properties of public key cryptographic algorithms to messages in order to create a signature that will be unique for each sender [Sta06]. The message is first compressed (hashed) to a smaller size (digest), then encrypted using the sender’s private key. When the signed message arrives at its target, the receiver verifies the signature using the sender’s public key to decrypt the message. If it produces a readable message, it could only have been sent by this sender. The receiver then generates the hashed digest of the received message and compares it with the received hashed digest: if it matches, the message has not been altered.

This approach uses public key cryptography in which one key is used for encryption and the other for decryption. To produce a digital signature (SIG), we encrypt (E) the hash value of a message (H(M)) using the sender’s private key (PrK):

equation

We recover the hash value of the message (H(M)) by applying decryption function D to the signature (SIG) using the sender’s public key (PuK). If this produces a legible message, we can be confident that the sender created the message, because they are the only one who has access to their private key. Finally, we calculate the hash value of the message as:

equation

If this value is the same as the message digest obtained when the signature was decrypted, then we know that the message has not been modified.

It is clear that the sender and receiver should agree to use the same encryption and hashing algorithms.

STRUCTURE

Figure 12.8 shows the class diagram for the DIGITAL SIGNATURE WITH HASHING pattern. A Principal may be a process, a user or an organization that is responsible for sending or receiving messages. This Principal may have the roles of Sender or Receiver. A Sender may send a plain Message and/or a SignedMessage to a receiver.

Figure 12.8 shows the class diagram for the DIGITAL SIGNATURE WITH HASHING pattern.

The KeyPair entity contains two keys, public and private, that belong to a Principal. The public key is registered and accessed through a repository, while the private key is kept secret by its owner. PublicKeyRepository is a repository that contains public keys. The PublicKeyRepository may be located in the same local network as the Principal, or on an external network.

The Signer creates the SignedMessage that includes the Signature for a specific message. On the other side, the Verifier checks that the Signature within the SignedMessage corresponds to that message. The Signer and Verifier use the DigestAlgorithm and SignatureAlgorithm to create and verify a signature respectively. The DigestAlgorithm is a hash function that condenses a message to a fixed length called a hash value, or message digest. The SignatureAlgorithm encrypts and decrypts messages using public/private key pairs.

DYNAMICS

We describe the dynamic aspects of the DIGITAL SIGNATURE WITH HASHING pattern using sequence diagrams for the use cases ‘Sign a message’ and ‘Verify a signature’.

Use Case: Sign a Message – Figure 12.9

Figure 12.9: Sequence diagram for the use case ‘Sign a message’

Use Case: Verify a Signature – Figure 12.10

Figure 12.10: Sequence diagram for the use case ‘Verify a signature’

IMPLEMENTATION

• Use the Strategy pattern [Gam94] to select different hashing and signature algorithms. The most widely used hashing algorithms are MD5 and SHA1. These and others are discussed in [Sta06].
• A good hashing algorithm produces digests that are very unlikely to be produced by other meaningful messages, meaning that it is very hard for an attacker to create an altered message with the same hash value. The message digest should be encrypted after being signed to avoid man-in-the-middle attacks, where someone who captures a message could reconstruct its hash value.
• Two popular digital signature algorithms are RSA [Riv78][rsa] and Digital Signature Algorithm (DSA) [Fed00][sta06].
• The designer should choose strong and proven algorithms to prevent attackers from breaking them. The cryptographic protocol aspects, for example key generation, are as important as the algorithms used.
• The sender and receiver should have a way of agreeing on the hash and encryption algorithms used for a specific set of messages. (XML documents indicate which algorithms they use, and pre-agreements are not necessary in this case.)
• Access to the sender’s public key should be available from a public directory or from certificates presented by the signer.
• Digital signatures can be implemented in different applications, such as in e-mail communication, distribution of documents over the Internet, or web services. For example, it is possible to sign an e-mail’s contents, or any other document’s content, such as a PDF. In both cases, the signature is appended to the e-mail or document. When digital signatures are applied in web services, they are also embedded within XML messages. However, these signatures are treated as XML elements, and they have additional features, such as signing parts of a message, or external resources, which can be XML or any other data type.
• When certificates are used to provide the sender’s public key, there must be a convenient way to verify that the certificate is still valid [SOA01].
• There should be a way of authenticating the signer software [dig], as an attacker who gains control of a user’s computer could replace the signing software with their own software.

EXAMPLE RESOLVED

Alice and Bob agree on the use of a digital signature algorithm, and Bob has access to Alice’s public key. Alice can then send a signed message to Bob. When the message is received by Bob, he verifies that the signature is valid using Alice’s public key and the agreed signature algorithm. If the signature is valid, Bob can be confident that the message was created by Alice. If the hash value is correct, Bob also knows that Eve has not been able to modify the message.

CONSEQUENCES

The DIGITAL SIGNATURE WITH HASHING pattern offers the following benefits:

• Because a principal’s private key is used to sign the message, the signature can be validated using its public key, which proves that the sender created and sent the message.
• When a signature is validated using a principal’s public key, the sender cannot deny that they created and sent the message (non-repudiation). If a message is signed using another private key that does not belong to the sender, the validity of the signature fails.
• If the proper precautions are followed, any change in the original message will produce a digest value that will be different (with a very high probability) from the value obtained after decrypting the signature using the sender’s public key.
• A message is compressed into a fixed length string using the hash algorithm before it is signed. As a result, the process of signing is faster, and the signed message is much shorter.
• The available algorithms that can be used for digital signatures do not require very large amounts of computational power and do not take large amounts of time.

The pattern also has the following potential liabilities:

• We need a well-established public key infrastructure that can provide reliable public keys. Certificates issued by a certification authority are the most common way to obtain this [Sta06].
• Both the sender and the receiver have to previously agree what signature and hashing algorithms they support. (This is not necessary in XML documents, because they are self-describing.)
• Cryptographic algorithms create some overhead (time, memory, computational power), which can be reduced but not eliminated.
• The required storage and computational power may not be available, for example in mobile devices.
• Users must implement the signature protocol properly.
• There may be attacks against specific algorithms or implementations [dig]. These are difficult to use against careful implementations of this pattern.
• This solution only allows one signer for the whole message. A variant or specialization, such as the XML SIGNATURE pattern (page 317), allows multiple signers.
• Digital signatures do not provide message authentication, and replay attacks are possible [SOA01]. Nonces or time stamps could prevent this type of attack.

KNOWN USES

Digital signatures have been widely used in different products.

• Adobe Reader and Acrobat [Ado] have an extended security feature that allows users to digitally sign PDF documents.
• CoSign [Arx] digitally signs different types of documents, files, forms and other electronic transactions.
• GNuPG [Gnu] digitally signs e-mail messages.
• The Java Cryptographic Architecture [SunB] includes APIs for digital signature.
• Microsoft .NET [Mic07] includes APIs for asymmetric cryptography such as digital signature.
• XML Signature [W3C08] is one of the foundation web services security standards that defines the structure and process of digital signatures in XML messages.

SEE ALSO

• Encryption/decryption using public key cryptography [Bra00].
• Generation and distribution of public keys [Leh02].
• Certificates [Mor06a] are issued by a certificate authority (CA) that digitally signs them using its private key. A certificate carries a user’s public key and allows anyone who has access to the CA’s public key to verify that the certificate was signed by the CA.
• The Strategy pattern [Gam94] describes how to separate the implementation of related algorithms from the selection of one of them.

12.5 XML Encryption

The XML ENCRYPTION pattern provides confidentiality by hiding selected sensitive information in a message using cryptography.

EXAMPLE

Alice in the purchasing department regularly sends purchase orders in the form of XML documents to Bob, who works in the distribution office. The purchase order contains sensitive data such as credit card numbers and other company information, so it is important to keep it secret. Messages may also contain non-sensitive data. At the receiving end, different people will handle different parts of the order. Eve can intercept these orders and may try to read them to access the confidential information.

CONTEXT

Users of web services sending and receiving XML messages through insecure networks such as the Internet.

PROBLEM

In many applications that communicate with external applications users exchange sensitive data. This data may be read by unauthorized people while the messages are in transit. How can we prevent this?

The solution to this problem must resolve the following forces:

• Messages may be captured while they are in transit, so we need to prevent unauthorized users from reading them by hiding the information the message contains using encryption.
• We need to express encrypted elements in a standardized XML format to allow encrypted data to be nested within an XML message, otherwise different applications cannot interoperate.
• Different parts of a message may be intended for different recipients, and not all the information contained within a message should be available to all the recipients. Thus, recipients should be able to read only those parts of the message that are intended for them.
• For flexibility reasons, both symmetric and asymmetric encryption algorithms should be supported.
• If a secret key is embedded in the message, it should be protected, otherwise an attacker could read some messages.

SOLUTION

Transform an XML message using some encryption algorithm so that it can only be understood by legitimate receivers that possess a valid key.

XML Encryption supports both types of encryption: symmetric and asymmetric. The symmetric encryption algorithm uses a common key for both encryption and decryption. The asymmetric encryption algorithm uses a key pair: a public key and a private key. The sender encrypts a message using the receiver’s public key, and the receiver uses their private key to decrypt the encrypted message. Thus, in both types of encryption, only recipients who possess the shared key or the private key that matches the public key used in the encryption process can read the encrypted message after decryption. Different parts of the message may be encrypted with different keys, or not encrypted.

STRUCTURE

Figure 12.11 shows the class diagram of the XML ENCRYPTION pattern. The shaded classes correspond to the classes of the XML ENCRYPTION pattern, while the unshaded classes describe the structure of the message and show that encryption can now be applied to specific portions of the message.

Figure 12.11: Class diagram for the XML ENCRYPTION pattern

A Principal may be a user or an organization that sends and receives XMLMessages and/or EncryptedXMLMessages. This Principal may have the roles of Sender and Receiver. Both an XMLMessage and a EncryptedXMLMessage are composed of XMLElements. Each XMLElement may have many children, and each child also can be composed of other XMLElements, and so on. The XMLEncryptor and the XMLDecryptor encipher a message and decipher an encrypted message respectively.

The EncryptedData contains other subelements, such as the encryption method, key information, cipher value and encryption properties. The EncryptionMethod is an optional element that specifies the algorithm used to encrypt the data. If this element is not specified, the receiver must know the encryption algorithm. The optional KeyInfo contains the same key information as that described in the XML Signature standard [W3C08]. However, this standard defines two other subelements: EncryptedKey and ReferenceList. The EncryptedKey contains similar elements to the EncryptedData; they are not shown in the class diagram.

The EncryptedKey includes an optional ReferenceList element that points to data or keys encrypted using this key. The CipherData is a mandatory element that stores either the cipher value or a pointer (cipher reference) to where the encrypted data is located. The EncryptionProperties element holds information such as the time that the encryption was performed, or the serial number of the hardware used for the process.

DYNAMICS

We describe the dynamic aspects of the XML ENCRYPTION pattern using sequence diagrams for the use cases ‘Encrypt XML elements’ and ‘Decrypt an encrypted XML message’.

Use Case: Encrypt XML Elements – Figure 12.12

Figure 12.12: Sequence diagram for the use case ‘Encrypt XML elements’

Use Case: Decrypt an Encrypted XML Message – Figure 12.13

Figure 12.13: Sequence diagram for the use case ‘Decrypt an encrypted XML message’

IMPLEMENTATION

• The designer should choose strong encryption algorithms to prevent attackers from breaking them, such as AES (Advanced Encryption Standard) or DES (Data Encryption Standard) for symmetric encryption, and RSA for asymmetric encryption [RSA].
• Asymmetric encryption or public-key encryption is more computationally intensive than symmetric encryption. However, symmetric encryption requires that both sender and receiver share a common key. A better practice is to use asymmetric encryption in combination with symmetric encryption: use symmetric encryption for the message and asymmetric encryption for secure key distribution.
• XML ENCRYPTION supports both symmetric and asymmetric encryption. This provides application flexibility; for example, a session can use symmetric encryption and key distribution can use asymmetric encryption.
• Encryption does not require creation of a new document, as shown in the solution, but could be done in place, replacing the message by an encrypted message.
• Data is usually serialized before encryption. The serialization process converts the data into octets. This serialized data is then encrypted using the chosen algorithm and the encryption key. The cipher data and the information of the encryption (algorithm, key and other properties) are represented in XML format.
• The following example illustrates how an encrypted part is embedded within an XML message.

Suppose you want to send a purchase order to the distribution office. This document contains details of the order, such as what item to buy, quantity and credit card information for payment. We want to keep the XML document simple by just focusing on the encryption part.

<Order>
<Item> Item X </Item>
<Quantity> 24 </Quantity>
<Payment Info>
<Credit Card>
<Number>1234566 </Number>
<Expiration Date> 12/12/2010</Expiration Date>
</Credit Card>
</Payment Info>
</Order>

Because Payment Info contains sensitive information, we want to encrypt only this element, so it can only be understood by the intended receiver.

<Order>
<Item> Item X </Item>
<Quantity> 24 </Quantity>
<Encrypted Data>
<Encryption Method Algorithm=‘AlgorithmX’/>
<Cipher Data>
<Cipher Value>ijutfrewsvbnmlkk</Cipher Value>
</Cipher Data>
<Key Info>
<Key Name> KeyA </KeyName>
</Key Info>
</Encrypted Data>
</Order>

The Payment Info element is replaced by the Encrypted Data element that includes all the information needed by the receiver. The Encryption Method element includes the algorithm used for the encryption. The Cipher Value element contains the actual encrypted data. For this example, the KeyInfo element includes the name that identifies the key.

EXAMPLE RESOLVED

Alice now encrypts the purchase orders she sends to Bob, using different keys for the parts that should be read by different people. The purchase order’s sensitive data is now unreadable by Eve. Eve can try to apply to it all possible keys, but if the algorithm has been well-chosen and well-implemented, Eve cannot read the confidential information. Nonsensitive information is not encrypted, which saves time and bandwidth.

CONSEQUENCES

The XML ENCRYPTION pattern offers the following benefits:

• Only users that know the key can decrypt and read the message. Each recipient can only decrypt parts of a message that are intended for them, but are unable to decrypt the remainder of the message.
• The Encrypted Data is an XML element that replaces the data to be encrypted. The EncryptedData, as well as the EncryptedKey, are composed of other subelements such as encryption method, key information and cipher value.
• The entire XML message, or only some parts of it, can be encrypted.
• If both the sender and the receiver have not exchanged the keys previously, the key can be sent in the message, encrypted using a public key system.

The pattern also has the following potential liabilities:

• The general liabilities of symmetric and asymmetric encryption still apply.
• The structure is rather complex and users may be confused.
• Unencrypted portions of the message may help a possible attacker. This might be improved by superencryption of the whole message at a lower level, such as using TLS.

KNOWN USES

Several vendors have developed tools that support XML ENCRYPTION:

• Xtradyne’s Web Services Domain Boundary Controller (WS-DBC) [Xtr]. The WS-DBC is an XML firewall that provides protection against malformed messages and malicious content, XML encryption, XML signature, and authentication, authorization and audit.
• IBM DataPower XML Security Gateway XS40 [IBM05] parses, filters, validates schema, decrypts, verifies signatures, signs, and encrypts XML message flows.
• Forum Sentry SOA Gateway [For] conforms to XML Digital Signature, XML Encryption, WS-Trust, WS-Policy and other standards.
• Microsoft .NET [Mic07] includes APIs that support the encryption and decryption of XML data.

SEE ALSO

• This pattern includes a specialization of the SYMMETRIC ENCRYPTION pattern (page 288).
• The WS-SECURITY pattern (page 330) is a standard for securing XML messages using XML SIGNATURE, XML ENCRYPTION and security tokens.
• The Strategy pattern [Gam94] describes how to separate the implementation of related algorithms from the selection of one of them.
• The XML Key Management Specification (XKMS) [W3C01] specifies the distribution and registration of public keys, and works together with XML ENCRYPTION.
• The WS-Security Policy [Aja 10b] standard describes how to express security policies, such as what algorithms are supported by a web service or what parts of an incoming message need to be signed or encrypted.

12.6 XML Signature

The XML SIGNATURE pattern allows a principal to prove that a message was originated from it. It also provides message integrity by detecting whether a message was altered during transmission. The XML Signature standard [W3C08] describes the syntax and the process of generating and validating digital signatures for authenticating XML documents. XML Signature also provides message integrity, and requires canonicalization before hashing and signing.

EXAMPLE

Alice in the sales department wants to send product orders to Bob in the production department. The product orders are XML documents and do not contain sensitive data such as credit card numbers, so it is not important to keep them secret. Each order must be signed by Alice’s supervisor Susie to indicate approval. Bob wants to be certain that the message was created by Alice so he can charge the order to her account, and also needs to know that the orders are approved. Because the orders include the quantity of items to be produced, an unauthorized modification to an order will make Bob manufacture the wrong quantity of items. Eve can intercept the messages and may want to make this kind of modification.

CONTEXT

Users of web services send and receive SOAP messages through insecure networks such as the Internet and need to prove their origin and integrity. During their transmission these messages can be subject to a variety of attacks.

We assume that a principal possesses a key pair: a private key that is secretly kept by the principal, and a public key that is in a publicly-accessible repository. We assume that there is a mechanism for the generation of these key pairs and for the distribution of public keys.

PROBLEM

In many applications we need to verify the origin of a message (message authentication). Since an imposter may assume the identity of a principal, how can we verify that a message came from a particular principal? Also, messages that travel through insecure channels can be captured and modified by attackers. How do we know that the message or document that we are receiving has not been modified?

The solution to this problem must resolve the following forces:

• For legal or business reasons we need to be able to verify who sent a particular message, otherwise we may not be sure of its origin, and the sender may deny having sent it (repudiation). We assume the sender has signed the message to prove they are its author.
• Messages may be altered during transmission, so we need to verify that the data is in its original form when it reaches its destination.
• The length of the signed message should not be significantly greater than the original message, otherwise we would waste time and bandwidth.
• Producing a signed message should not require a lot of computational power or take a long time.
• We need to express a digital signature in a standardized XML format, so interoperability can be ensured between applications.
• There may be situations in which we want to ensure proper origin or integrity in specific parts of a message. For example, an XML message can travel through many intermediaries that add or subtract information, so if we sign the entire message, the signature would have no meaning. We need to be able to sign portions of a message.

SOLUTION

Apply cryptographic algorithms to messages to create a signature that will be unique for each message. First, the data to be signed may need to be transformed before applying any digest algorithm. The series of XML elements (that includes other subelements) is canonicalized before applying a signature algorithm. Canonicalization is a type of transformational algorithm that converts data into a standard format, to remove differences due to layout formatting. This process is required because XML is a flexible language in which a document can be represented in different ways that are semantically equal. Thus, after calculating the canonical form, both the sender and the receiver will sign and verify the same XML data respectively. After applying a canonicalization algorithm, the result value is digested and then encrypted using the sender’s private key. Finally, the signature, in XML form, is embedded in the message.

At the other end, the receiver verifies the signature appended to the signed message. The verification process has two parts: reference verification and signature verification. In the reference verification, the verifier recalculates the digest value of the original data. This value is compared with the digest value included in the signature. If there is any mismatch, the verification fails. In the signature verification, the verifier calculates the canonical form of the signed XML element, then applies the digest algorithm. This digest value is compared against the decrypted value of the signature. The decryption is done using the sender’s public key.

There are three types of XML Signature: enveloped, enveloping and detached signature. In an enveloped signature, the signature is a child element of the signed data. For example, when you sign the entire XML message, the signature is embedded within the message. An enveloping signature is a signature where the signed data is a child of the signature. You can sign elements of a signature, such as the <Object> or <KeyInfo> element. A detached signature is calculated over external network resources or over elements within the message. In the latter case, the signature is neither an enveloped nor an enveloping signature.

STRUCTURE

Figure 12.14 shows the class diagram of the XML SIGNATURE pattern. Note that the upper part of this figure is almost the same as Figure 12.8 (page 303). The main difference is that Figure 12.14 adds more details about the structure of the elements of the message so that signatures can be applied more finely.

Figure 12.14: Class diagram for the XML SIGNATURE pattern

A Principal may be a process, a system, a user, or an organization that sends and receives XMLMessages and/or SignedXMLMessages. This Principal may have the roles of Sender and Receiver. Both an XMLMessage and a SignedXMLMessage are composed of XMLElements, but this is only shown in the SignedXMLMessage. Each XMLElement may be a SingleElement that does not have any children, or be a Composite element which is composed by other XMLElements.

The XMLSigner and the XMLVerifier create and verify a signature respectively. They can select signature and digest algorithms. An XMLSignature element is an XMLElement that has two required children, SignedInfo and SignatureValue, and two optional children, KeyInfo and Object. The SignedInfo element is the one that is actually signed. It contains one or more Reference elements, the canonicalization algorithm identifier, and the signature algorithm identifier. The canonicalization algorithm is used to convert the SignedInfo element into a standard form before it is signed or verified. The signature algorithm also includes a digest algorithm that is applied after calculating the canonical form of the SignedInfo in both process creation and verification of XML signatures.

Each Reference element includes a URI, a hash value (digestValue), the digest algorithm identifier (digestMethod) and an optional list of Transform elements. The URI is a pointer that identifies the data to be signed. It can point to an element inside an XML message, an element inside the signature element such as Objector KeyInfo, or resources located on the Internet. The digestValue contains a hash value created after applying the digest algorithm to the data pointed to by its URI. If the Transform element exists, it includes an ordered list of transform algorithms that are applied to the data before the digest is created. The SignatureValue element includes the value of the digital signature.

If the KeyInfo element is present, it indicates the information about the sender’s public key that will be used to verify the signature. This flexible element may contain certificates, key names and other public keys forms. Additional information about this element can be found in [W3C08]. The optional Object element may contain SignatureProperties and/or a Manifest. The SignatureProperty identifies properties of the signature itself, such as the date/time when the signature was created. The Manifest element includes one or more Reference elements, as for the Reference element within the SignedInfo element. They are semantically equal; however, each Reference in the SignedInfo has to be validated in order for the XMLSignature to be considered a valid signature. On the other hand, the list of Reference elements within the Manifest is validated.

The Sender and Receiver must use the same hash, signature and canonicalization algorithms. XML documents are self-descriptive and indicate this information, so the sender only needs to find the corresponding algorithms.

DYNAMICS

We describe the dynamic aspects of the XML SIGNATURE pattern using sequence diagrams for the use cases ‘Sign different XML elements of an XML message’ and ‘Verify an XML signature with multiple references’.

Use Case: Sign Different XML Elements of an XML Message – Figure 12.15

Figure 12.15: Sequence diagram for the use case ‘Sign different XML elements of an XML meassage’

Use Case: Verify an XML Signature with Multiple References – Figure 12.16

Figure 12.16: Sequence diagram for the use case ‘Verify an XML signature with multiple references’

IMPLEMENTATION

• Identifiers of algorithms used to create a signature are attached along with the signature, so they also should be protected from being modified by attackers.
• XML documents may be parsed by different processors; XML allows some flexibility without changing the semantics of the message. Thus, we need to convert the data to be signed to a standard format.
• All the signers of a given document should have the same level of trust, to avoid misleading the receivers about the trust level of the whole message. Allowing untrusted signers might give them a better chance of attacking the message.
• Use the Strategy pattern [Gam94] to select different hashing and signature algorithms. The most widely used hashing algorithms are MD5 and SHA1. Two popular digital signature algorithms are RSA [RSA] and the Digital Signature Algorithm (DSA) [Fed00].
• The data to be signed may need to be transformed before producing a digest. For instance, if the object to be signed is an image, it needs to be converted into text.
• The use of certificates issued by a certification authority that are trusted by the sender and the receiver is recommended.

EXAMPLE RESOLVED

Alice and Susie sign each production order sent to Bob. Bob has access to Alice’s and Susie’s public keys. When the message is received by Bob, he verifies whether the signatures are valid using Alice’s and Susie’s public keys and the signature algorithm specified in the order. If the signature are valid, Bob can be confident that the message was created by Alice and approved by Susie. If the hash value is correct, Bob also knows that Eve has not been able to modify the message.

CONSEQUENCES

The XML SIGNATURE pattern offers the following benefits:

• A principal’s private key is used to sign the message. The signature is validated using its public key, which proves that the principal created and sent the message.
• When a signature is validated using a principal’s public key, the principal (sender) cannot deny that they created and sent the message. If a message is signed using another private key that does not belong to the sender, the validity of the signature fails.
• Any change in the original message will produce a digest value that will be different from the value obtained after decrypting the signature using the sender’s public key.
• Before applying any signature algorithm, the data is compressed to a short fixed-length string. In XML SIGNATURE, digest algorithms are used twice: one is used to digest data to be signed indirectly, and the other digest algorithm is used to digest the canonical form of the SignedInfo element.
• Any change in the data that was indirectly signed will produce another digest that will invalidate the signature.
• The available algorithms that can be used for digital signatures do not require a lot of computational power and do not take large amounts of time.
• We can sign different parts of a message with different signatures. This allows a set of principals to write portions of one document and sign them individually.
• An XML signature is an XML element that is embedded in the message. The XML signature is composed of several XML elements that include information such as the value of the signature, the key that will be used to verify the signature, and algorithms used to compute the signature. This standard format helps XML parsers to better understand signature elements during the validation process.
• This pattern also supports message authentication codes (MAC). Both signatures and MACs are syntactically identical: the difference between them is that signatures use public key cryptography, while MACs uses a shared common key.
• The data being signed is pointed by its URI, so elements within XML messages and external network resources can be located using their identifiers.
• SignedInfo is the element that is actually signed. It includes the references that point the data being signed, along with their digest values and algorithm identifiers. Thus the XML signature also protects the algorithm identifiers from modification.
• XML SIGNATURE uses canonicalization algorithms to ensure that different representations of XML are transformed into a standard format before applying any signature algorithm.
• XML documents are self-describing; the sender and receiver don’t need to agree in advance on the algorithms to be used.

The pattern also has the following potential liabilities:

• We need a well-established public key infrastructure that can provide reliable public keys. Certificates issued by a certification authority are the usual way to obtain this [Sta06]. There is a public key standard for XML that should be used.
• Users must properly implement the signature protocol.
• There may be attacks against specific algorithms or implementations [dig]. These are difficult to use against careful implementations of this pattern.
• Even using efficient algorithms, signing and verifying XML messages may create a significant overhead.

The pattern does not describe the complete standard. For example, details of transforms and key values have been left out for simplicity [W3C08].

KNOWN USES

Several vendors have developed tools that support XML SIGNATURE:

• IBM DataPower XS40 XML Security Gateway [IBM05] parses, filters, validates schema, decrypts, verifies signatures, signs and encrypts XML message flows.
• Xtradyne’s WS-DBC [Xtr]. The Web Services Domain Boundary Controller is an XML firewall that provides protection against malformed messages and malicious content, XML encryption, XML signature, as well as authentication, authorization and audit.
• Forum Sentry SOA Gateway [For] conforms to XML Digital Signature, XML Encryption, WS-Trust, WS-Policy and other standards.
• Microsoft .NET [Mic07] includes APIs that support the creation and verification of XML digital signatures.
• Java XML Digital Signature API [Mul07] allows XML signatures to be generated and validated.

SEE ALSO

• This pattern is a specialization of the DIGITAL SIGNATURE WITH HASHING pattern (page 301).
• The WS-SECURITY pattern (below) is a standard for securing XML messages using XML SIGNATURE, XML ENCRYPTION and security tokens.

The following specifications are related to XML SIGNATURE, but they have not been expressed as patterns:

• The XML Key Management Specification (XKMS) [W3C01] specifies the distribution and registration of public keys, which works together with XML SIGNATURE.
• The WS-Security Policy [OAS07] standard describes how to express security policies, such as what algorithms are supported by a web service, or what parts of an incoming message need to be signed or encrypted.

12.7 WS-Security

The WS-Security standard [OAS07]describes how to embed existing security mechanisms such as XML Encryption [W3C02], XML Digital Signature [W3C08] and security tokens into SOAP messages in order to provide message confidentiality, integrity, authentication and non-repudiation.

CONTEXT

Users of web services sending and receiving SOAP messages through insecure channels such as the Internet.

PROBLEM

Sending messages through insecure channels exposes the messages to a variety of attacks, including illegal reading, modification or replay, and the sender can deny having sent a specific message [Sta06]. We have cryptographic solutions for these problems; however, there are many algorithms and protocols and we need to make a selection self-descriptive.

The solution to this problem must resolve the following forces:

• Interoperability. We need a common format in SOAP messages in order to add security features, so both senders and receivers can process messages that contain security features without the need for previous agreements.
• Fine degree of protection. SOAP messages may travel through many intermediaries in a network environment, and different users may need access to different parts of them. We may need to protect different parts of a message in different ways.

SOLUTION

Define areas in the message format with parameters that specify security mechanisms such as encryption, digital signatures and security tokens.

A SOAP message is composed of a body and an optional header. Three major elements can be embedded within the header of a message: XML encryption, XML signature and security tokens. If an element within the message is signed, the header can include information about the signature, such as the algorithm, the key and the value of the signature. For XML encryption, the security header can enclose a list of references that point to the parts of the message that have been encrypted, and describe how they were encrypted.

STRUCTURE

Figure 12.17 shows the class diagram for this pattern. A Principal may be a system, a user or an organization that sends and receives XMLMessages. This principal may have the roles of Sender and Receiver. The SenderEngine includes a Sender and an Encryptor, while the ReceiverEngine includes a Verifier and a Decryptor1. SecurityTokens such as username/password, X.509 certificates and Kerberos tickets are used for authentication and authorization purposes.

Figure 12.17: Class diagram for the WS-SECURITY pattern

XMLMessages are composed of a Body and an optional Header. A Header may contain a SecurityBlock, which may enclose Timestamp, EncryptedKey, ReferenceList, SignedElement and SecurityToken elements. Timestamps provide the time of creation and expiration of a message. EncryptedKey element represents the key used to encrypt parts or the entire message, and this key is encrypted according to the XML encryption standard. The ReferenceList element points to the parts of the message that are encrypted with XML encryption. The SignedElement2 holds information about the signatures generated according to XML Signature standard. The Body is a collection of XMLElements, some of which are EncryptedData elements. Elements can be structured into Composite pattern hierarchies [Gam94].

DYNAMICS

We describe the dynamic aspects of the WS-Security standard using sequence diagrams for the use cases ‘Encrypt an element using an encrypted key’ and ‘Sign an element using a security token’.

Use Case: Encrypt an Element using an Encrypted Key – Figure 12.19

Figure 12.18: Sequence diagram for the use case ‘Sign an element using a security token’

Figure 12.19: Sequence diagram for the use case ‘Encrypt an element using an encrypted key’

Use Case: Sign an Element using a Security Token – Figure 12.18

IMPLEMENTATION

To implement the WS-Security standard, the following aspects are required:

• Clients need to have knowledge of cryptographic algorithms, such as security token formats, signature formats and encryption technologies.
• A message can have multiple headers if they are targeted for different recipients. In other words, message security information targeted to different recipients must be in different headers.

CONSEQUENCES

The WS-SECURITY pattern offers the following benefits:

• Using the header of a SOAP message, we can specify the security features of a message, such as XML encryption, XML signatures and security tokens.
• We can specify different parts of a message with different types of encryption, different keys or different signatures.

The pattern also has the following potential liabilities:

• The pattern does not describe details of encryption, digital signatures or security tokens: these require separate standards.
• WS-Security does not tell you whether you should sign or encrypt a whole message, a part of it, or only the header. It is up to the designer to define these aspects.
• WS-Security is an immature specification that is still changing.

KNOWN USES

Several vendors have developed products that support WS-SECURITY:

• Xtradyne’s Web Service Domain Boundary Controller (WS-DBC) [Xtr] is an XML firewall that supports the WS-Security standard and other standards.
• IONA’s Artix iSF Security Framework [ION] implements most of the web services standards, including WS-Security.
• Forum Sentry SOA Gateway [For] conforms to XML Digital Signature, XML Encryption, WS-Trust, WS-Policy and other standards.

SEE ALSO

• The DIGITAL SIGNATURE WITH HASHING (page 301) and XML ENCRYPTION patterns (page 309) provide message security for the WS-Security standard.
• Secure Channel is a way to transport messages providing message authentication, message confidentiality and message integrity [Bra00], and is the generalization of WS-SECURITY.
• WS-SECURITY uses WS-POLICY (page 263) for policy specification.
• As shown in Figure 12.1 (page 287), WS-Federation, WS-TRUST and WS-Secure Conversation use WS-SECURITY for secure token transport.
• SAML uses WS-SECURITY for security assertion transport.

1 My improvements on the translation in http://evans-experientialism.freewebspace.com/borges.htm

1 These classes are not shown in Figure 12.17.

2 Not shown in Figure 12.17.