Context

Data passes between an online application and a Web service, sometimes through one or more intermediaries. Messages may also be kept in repositories, such as message queues or databases. Some of the data within the messages is considered to be sensitive in nature. There is a risk that an attacker can gain access to sensitive data, either by eavesdropping on the network or accessing a repository.

Problem

How do you protect data within a message from information disclosure to unintended parties?

Forces

• Business data contains sensitive information that must be protected from unauthorized users. Disclosure of sensitive data could result in loss or damage such as Identity theft, lawsuits, loss of business, or regulatory fines.
• Sensitive data must be protected from disclosure in transit. An eavesdropper could gain access to sensitive data, whenever it leaves a secure area (such as a protected memory space) or crosses a non-secure communication line (such as a public network).
• Sensitive data must be protected from disclosure when persisted. Applications may persist data for short periods of time such as in a message queue, or over longer periods of time in a database or a file.

Solution

Use encryption to protect sensitive data contained in a message. Unencrypted data, known as plaintext, is converted to encrypted data, known as ciphertext. Encryption occurs using an algorithm and cryptographic key. Ciphertext is then converted back to plaintext at its destination.

Participants

• Sender – Originator of a message. An online application can send a request message to a Web service, and a Web service can send a response message back to an application that has sent a request message.
• Recipient – Entity receiving a message from the sender. A Web service is the recipient of a request message sent by an online application, and an online application is the recipient of a response message it receives from a Web service.

Process

Applying data confidentiality can be broken into two steps:

1. Encrypting the data –Plaintext is rendered unintelligible to parties other than the intended recipient when the sender converts it into ciphertext.

2. Decrypting the data –Ciphertext is rendered intelligible to the intended recipient by converting it back into plaintext.

Two types of cryptography can be used to provide Data Confidentiality - Symmetric and Asymmetric. While both symmetric and asymmetric cryptography follow the same basic process, they each have their own unique characteristics.

Symmetric Cryptography

With symmetric cryptography, both the sender and recipient share a key that is used to perform both encryption and decryption. Symmetric cryptography is commonly used to perform encryption, and to provide data integrity.

Figure 1 shows the process of encrypting and decrypting data with a shared secret key:

Figure 1

The Process of Symmetric Encryption

1. Sender creates ciphertext message by encrypting the plaintext message using a symmetric encryption algorithm and a shared key.

2. Sender sends ciphertext message to recipient.

3. Recipient decrypts ciphertext message back into plaintext with shared key.

There are numerous symmetric algorithms in use. Some of the more common algorithms are RC5, RC6, Rijndael (AES), and Triple DES (3DES). These algorithms are all designed to perform efficiently on common hardware architectures.

Symmetric cryptography is comparatively simple in nature, because the secret key used for both encryption and decryption is shared between the sender and the recipient. However, before communication can occur, the sender and recipient must exchange a shared secret key. In some cases (such as SSL), asymmetric cryptography may be used to ensure that they initial key exchange occurs over a secure channel.

Asymmetric Cryptography

With Asymmetric cryptography (also known as Public Key cryptography) the sender encrypts data with one key, and recipient uses a different key to decrypt ciphertext. The encryption key and its matching decryption key are often referred to as a public/private key pair. As well as providing encryption, Public Key cryptography is commonly used to provide digital signatures, facilitating non-repudiation, and for key management purposes.

The public key of the recipient is used to encrypt data. It can be openly distributed to those wishing to encrypt a message to the recipient. The private key of the recipient is used to decrypt messages, and only the recipient must be able to access it.

Figure 2 demonstrates how asymmetric encryption and decryption take place:

Figure 2

The Process of Asymmetric Encryption

1. Sender creates ciphertext message by encrypting the plaintext message using an asymmetric encryption algorithm and the recipients public key

2. Sender sends ciphertext message to recipient

3. Recipient decrypts ciphertext message back into plaintext using the private key matched with the public key that was used to encrypt the message

There are few asymmetric algorithms in use. The most commonly used asymmetric algorithm is the RSA algorithm.

Asymmetric encryption requires more processing resources than Symmetric encryption. For this reason, asymmetric encryption is often used to exchange a shared key, which is then used for symmetric encryption. This is particularly useful when a sender and recipient need to send multiple messages back and forth within the same session.

Example

A Web service is published by a bank to provide business customers with the ability to upload payroll account transfers. Direct deposit account information is considered very sensitive for both the business customer, as compromise of this information could result in unauthorized account activity or disclosure of employee salary information.

Resulting Context

The following benefits, liabilities and security considerations are associated with the use of Data Confidentiality.

Benefits

Preventing unauthorized parties from viewing messages can prevent financial loss and legal liability, due to disclosure of sensitive information.

Liabilities

• Cryptography Operations are computationally intensive and impact system resource usage, affecting the scalability and performance of the application. 
• There is an administrative overhead associated with Key management, which safeguards encryption keys from being compromised. Factors that affect the administrative complexity of key management include:
• The number and type of keys used.
• The type of encryption used (symmetric or asymmetric).
• The Key Management Infrastructure in use.

Security Considerations

• Encryption does not prevent against data tampering. For example, a man-in-the-middle attack can replace the bits on the wire causing the receiver to decrypt the data to something other than the original plaintext. The receiver has no way to verify that decrypted ciphertext is the same as the original plaintext without Data Origin Authentication protection.
• If a message is being signed and then encrypted care you should ensure that signature within the message is also encrypted, If the signature is not encrypted, it can be the target of a plaintext cryptographic attack.
• If too much data is encrypted with the same symmetric key, an attacker can intercept several messages and attempt to cryptographically attack the encrypted messages, with the aim of obtaining the symmetric key. To minimize the risk of such an attack, you should consider generating session-based encryption keys with a relatively short lifespan. These session keys are typically derived from a master symmetric key such as a shared identity secret. The session key is normally exchanged using asymmetric encryption, during the initial interaction between a Sender and Recipient. Session keys should be discarded and replaced at regular intervals, based on the amount of data or number of messages that they are used to encrypt.
• Symmetric encryption algorithms gain much of their strength through the randomness of their encryption keys. If keys originate from a source that is not sufficiently random, attackers may narrow down number of possible values for the encryption key. This can allow a brute force attack to discover the key value from encrypted messages that have been intercepted. For example, if a user password is used as an encryption key, it can be very easy to attack, because user passwords are typically a non-random value of relatively small size, in order to allow a user to remember it without writing it down.
• You should use published, well-known encryption algorithms that have withstood years of rigorous attacks and scrutiny. Use of encryption algorithms that have not been subjected to rigorous review by trained cryptologists may contain undiscovered flaws that are easily exploited by an attacker.
• Each country may recognize different standards for data privacy/protection. For example, In the U.S., regulations such as Sarbanes-Oxley, HIPAA, Privacy Act of 1974 require measures to be taken to prevent disclosure of sensitive personal information or require accountability for the management of sensitive data. In the EU, regulations such as the Data Protection Directive enforce stringent standards for data privacy.

Related Patterns

There are three different types of patterns associated with Data Confidentiality: child patterns, dependent patterns, and alternate patterns.

Child Patterns

• Implementing Message Layer Authentication with UsernameToken in WSE 2.0 - Composite pattern that uses X.509 certificates for data confidentiality
• Implementing Message Layer Security with KerberosToken2 in WSE 2.0 - Composite pattern that uses Kerberos for data confidentiality
• Pattlet – Transport Layer Data Confidentiality using HTTPS - Pattlet that provides references for implementing data confidentiality with SSL.
• Pattlet – Transport Layer Security using X.509 Certificates and HTTPS - Pattlet that provides references for implementing SSL with Transport Layer X.509.

References

• OASIS Standards and Other Approved Work (including WS-Security) at http://www.oasis-open.org/specs/index.php#wssv1.0

Acknowledgments

Improving Web Application Security: Threats & Countermeasures - Chapter 2 athttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/THCMCh02.asp?frame=true

Microsoft Confidential. © 2005 Microsoft Corporation. All rights reserved. By using or providing feedback on these materials, you agree to the attached license agreement.