Context

Data passes between an online application and a Web service, sometimes through one or more intermediaries. The data contained in the request message from the online application influences the Web service's behavior. There is a risk that an attacker could manipulate messages in transit between the online application and the Web service to maliciously alter the behavior of the Web service. Message manipulation can take the form of data modification within the message, or even substitution of credentials, to change the apparent source of the request message.

Problem

How do you prevent an attacker from manipulating messages in transit between an online application and a Web service?

Forces

Solution

Use Data Origin Authentication, enabling the recipient to verify that messages have not been tampered with in transit (Data Integrity) and that they originate from the expected sender (Authenticity).

You can also use Digital Signatures to provide evidence that a subject has performed a particular action related to data, in cases where the subject denies performing the action (non-repudiation).

 

Note: While digital signatures can be used for Non-repudiation purposes, they may not be sufficient to provide legal proof of Non-repudiation. By itself, a Digital Signature is just a mechanism to capture a subject’s association to data. In cases where data has been digitally signed, the degree to which an individual or organization can be held accountable is established in an agreement between the party requiring digital signatures, and the owner of the digital signature.

 

Participants

 

Process

Two types of signatures can be used to sign a message: Symmetric and Asymmetric.

 

Note: The following discussion refers to both XML signatures and digital signatures. XML signatures are used for SOAP message security, using either a symmetric or asymmetric algorithm, whereas digital signatures refer are created explicitly using an asymmetric algorithm, and may or may not be used for SOAP message security.

 

Symmetric Signatures

A symmetric signature is created by using a shared secret to sign and verify the message. A symmetric signature is commonly known as a Message Authentication Code (MAC). A MAC is created by computing a checksum using the message content and shared secret. A MAC can only be verified by a party that has both the shared secret and the original message content used to create the MAC.

The most common type of MAC is a Hashed Message Authentication Code (HMAC). The HMAC protocol uses a shared secret and a hashing algorithm (such as MD5, SHA-1 or SHA-256) to create the signature, which is added to the message. The message recipient uses the shared secret and the message content to verify the signature, by recreating the HMAC and comparing it to the HMAC sent in the message.

If security is the primary consideration to choose a hashing algorithm for an HMAC, you should use SHA-256 where possible for the hashing algorithm to create an HMAC, as it is the least likely to produce collisions (when two different pieces of data produce the same hash value). If performance is the main consideration, then MD5 is the best choice. SHA1 is currently the most widely adopted algorithm, and so may be required for interoperability reasons.

The shared key and algorithm used to encrypt the hash may depend on the symmetric algorithm used to encrypt sensitive data (see the Data Confidentiality pattern.)  When used to create an HMAC, the name of these algorithms are preceded by the term “HMAC” (for example, HMAC SHA-1 or HMAC MD5).

Figure 1 shows the process of using a MAC to sign a message:

Figure 1

Signing a message using a symmetric signature

1.  Sender creates a MAC using a shared secret key and attaches it to the message.

2.  Sender sends message and MAC to recipient.

3.  Recipient Verifies the MAC that was sent with the message using the same shared secret key used to create the MAC.

 

By signing with a shared secret, both Data Integrity and Data Origin Authenticity are provided for the signed message content. However, symmetric signatures are not normally used to provide non-repudiation, because shared secrets are known by multiple parties. This makes it more difficult to provide evidence that a specific party used the shared secret to sign the message.

Asymmetric Signatures

An asymmetric signature is processed using two different keys, one to create the signature and the other verify it. The two keys are related to one another and are commonly referred to as a public/private key pair. The public key is generally available and can be distributed with the message while the private key is kept secret by the owner and never sent in a message. A signature created and verified using an asymmetric public/private key pair is called a Digital Signature.

The following diagram depicts the process of using asymmetric keys to sign a message:

Figure 2

Signing a message using an asymmetric signature

1.  Sender signs message content using the sender’s private key and attaches it to the message.

2.  Sender sends message and digital signature to the recipient.

3.  Recipient verifies the digital signature using the sender's public key matched with the private key that was used to sign the message.

 

The most commonly used algorithm to create digital signature is the Digital Signature Algorithm (DSA).  DSA uses the public/private key pairs created for use with the RSA algorithm (as described in the Data Confidentiality pattern) to create and verify signatures.

For both signing and encryption purposes, asymmetric keys are often managed through a Public Key Infrastructure (PKI.)  X.509 is the most common PKI standard in use.  Information describing the subject is bound to their public key through endorsement from a trusted party to form a certificate.  Certificates allow a message recipient to verify a signature created by a subject with their private key against the public key in the subject’s certificate.  For more information on X.509, see X.509 Security Primer.

Digital signatures are typically used to support requirements for non-repudiation. This is because access to the private key is usually restricted to the owner of the key, which makes it easier to verify proof-of-ownership.

Example

When using message layer authentication it is often necessary to include Data Origin Authentication (DOA) as part of the authentication process. One such example is the use of X.509 certificates to perform message layer authentication. Since X.509 is based on public key cryptography, the type of DOA used would be an asymmetric signature.

For example, a business customer for a bank would sign their payroll transfers using his or her certificate private key. The bank would then verify that the payroll transfer request came from the correct business customer, and that the message had not been tampered with in transit between the business customer and the bank.

Resulting Context

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

Benefits

Tampering of message can be detected by the recipient.  Also, the origin of the message can be traced to an identifiable source.

Liabilities

Security Considerations

Related Patterns

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

Child Patterns

 

References

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.