The Need for Security Standards

Communicating systems or services have to deal with tough challenges when it comes to secure messaging. If a system is sending a message to another, this requires the implementation of important security measures.

1. First, the receiving system must authenticate the sender before accepting its message. It must verify that the sender is indeed whoever claims to be.
2. During transmission, intruders may be able to peek into messages. If these messages contain sensitive data, then data privacy becomes an issue. Intruders must not be able to understand what they just saw.
3. Another concern during transmission, is Data Accuracy – or Integrity – which means that If an intruder intercepts the message and modifies it, this modification must be detected by the receiving system.

 

The WS-Security Standard

WS-Security is the foundation layer on top which other security standards are created. The WS-Security standard also uses another two important standards, these are XML-Encryption and XML-Signature. These standards were created to secure XML documents independent of SOAP and the WS-* stack. But the WS-Security standard then used these standards to secure SOAP messages.

Here, I will explain WS-Security, WS-SecureConversation, XML Encryption, and XML Signature. WS-Trust, and WS-Federation are explained in other articles, while WS-SecurityPolicy, just like all other policy assertions are explained in the policies article.

WS-Security provides solutions to authentication, message privacy, and message accuracy challenges . To achieve this, WS-Security introduces three key constructs. These are:

• Security tokens
• Encryption elements
• And Signature elements

Security Tokens

Security tokens carry information that is required for the message receiver to authenticate the message sender.

The token can be as simple as a username/password token, or it can be XML-based such as SAML token, or even a binary-based X.509 certificate. Username and binary tokens are explained in this module, while SAML tokens are explained in the next. It’s through the use of tokens that authentication scenarios become possible.

Encryption Elements

Encryption elements contain parts of the message that are encrypted. As I mentioned before, WS-Security uses another standard called XML Encryption to encrypt messages.

Encryption guarantees message privacy. By encrypting sensitive data, even if intruders were able to intercept a message, they won’t be able to understand the sensitive encrypted portion. This again also means that we are able to encrypt a selective portion of the message, something which we cannot achieve in Transport security where the complete message is secured.

Finally recall that having encrypted data at the message level, means that security is end-to-end regardless of the number of intermediaries; again something which cannot be achieved using transport security.

Signature Elements

Final construct, are the Signature elements which contain the digital signature applied on the message. Again, WS-Security uses another standard called XML Signature to apply digital signatures

Digital Signatures guarantee that any message tampering will be detected by the receiving party. This in fact is also a method for authentication because signatures are applied and verified using a private/public key pair, which effectively means, that upon successful signature verification, the receiving party has verified the sending party.

WS-Security Messages

XML Signature

The following diagram shows a portion of XML Signature applied to a message:

• The region of the XML Signature starts at the <Signature> element.
• The information about the signature is found in the <SignedInfo> element. This information contains, the algorithm used to apply digital signature in the <SignatureMethod> element.
• Then you will find one or more <Reference> elements, where each element references a part of the message that is signed. For example, in this particular sample, id 2 refers to the body section of the message, and id 4 refers to the action header. Both sections are signed, and are thus referenced each in a separate <Reference> element.
• As you can see, each reference element has its own <DigestValue> element. Recall from the previous discussion, that a digest value is unique per string.
• Also recall that it’s the encryption of the digest that is called digital signature. Well, the value of the digital signature is placed in the <SignatureValue> element.

Note that there are more elements and more options into the standard than what I showed you here, however, that’s just about enough for you to understand how XML Signature is used within a WS-Security message.

XML Encryption

Again, here is an image showing a portion of an XML Encryption applied on a message:

• Each encrypted part of the message in included in an <EncryptedData> element. For example, one <EncryptedData> element shows the result of encrypting the username token passed from the client to the service. While one <EncryptedData> element shows the result of encrypting the body part of the message.
• The <EncryptionMethod> element indicates the encryption algorithm.
• The <KeyInfo> specifies the encryption key. Here <SecurityTokenReference> is used to reference the key, which is pointing to a derived key specified using the <DerivedKeyToken>. I will explain later what are derived keys and what role do they play in message security. For now, just understand that the <KeyInfo> element either points to the public key itself, or to the location of the public key that is used for encryption.
• Finally, the <CipherData> element contains the <CipherValue> element, which holds the encrypted data.

Tokens

Finally, authentication tokens, hold client credentials to the service.

As I said before, a service can require multiple types of authentication tokens, such as username, XML-based tokens such as SAML, or binary tokens such as X.509 certificates.

For example, here is a username token . This token holds the username/password combination:

While here is a binary token:

 

SAML tokens are explained in a later article

WCF Symmetric and Asymmetric Binding Elements

WS-SecurityPolicy Symmetric and Asymmetric Bindings

WS-Policy will be explained later, but in general policies are a way to extend WSDL to describe capabilities of the WS-* standards.

Since the WS-* standards are extensions to the core web service standards, they cannot be described by the original WSDL specification. As such, WS-Policy defines a framework for describing policy assertions that can extend WSDL, where an assertion is a requirement or preference of the service. There are assertions for security, transactions, reliable messaging, among other WS-* standards.

WS-SecurityPolicy defines security assertions that describe the capabilities of WS-Security, WS-SecureConversation, and WS-Trust.

WS-SecurityPolicy specification defines three security binding assertions for message protection:

• Symmetric Binding
• Asymmetric Binding
• And Transport Binding

Each binding is used for certain scenarios, in the next sections, we’ll take a detailed look at how each binding is used.

Transport Binding

Transport Binding is used when security is implemented using transport protocol such as HTTPS. For the sake of this course, we’re not interested in this binding. The next two bindings however, are important in the context of this discussion.

Symmetric Binding

The symmetric binding is used, when only one of the communicating parties has a security token. A symmetric key is generated from this token, and it’s used to achieve message protection. The most common case is where the service has an X509 certificate, while the client does not have a key pair of its own.

In this case, the following flow occurs:

• As always, the service shares its public key with the client
• Upon each request, the client generates a random symmetric key
• The client encrypts and signs the request with this symmetric key
• It then uses the service public key to encrypt the symmetric key and embeds this encrypted key in the request header
• When the service receives the message, it uses its private key to decrypt the symmetric key
• Now the service uses the symmetric key to decrypt the message and verify the signature
• To send the response, the service again uses the symmetric key to encrypt and sign the response
• The client still preserving the symmetric key, uses this key to decrypt and verify the signature

Symmetric Binding with Derived keys

A more secure variation is using derived keys. When derived keys feature is enabled, the client derives two separate keys from the symmetric key it generated. And instead of using the symmetric key to encrypt and sign the message, it then uses one of the derived keys for encryption and the other one for signature.

Its then these two derived keys that are encrypted by the service public key and sent inside the request to the service

This is considered more secure because using separate keys for encryption and signature makes it more difficult for security attacks to guess these keys, as opposed to using the same symmetric key.

Reducing Overhead with WS-SecureConversation

One note I want to make here, is that the act of generating the random symmetric key and the derived keys out of it, happens for each request.

When the client is issuing multiple requests, this can be an overhead. To reduce this overhead, WS-SecureConversation can be used to establish a session key once and keep it live for the lifetime of the communication. I will return to this point later at the last section of this module.

Asymmetric Binding

The asymmetric binding is used when both the service and the client have security tokens. The most common case is where both the service and the client possess X509 certificates.

In this case, the public key infrastructure (PKI) comes into play. Both parties exchange their public keys, and the following flow occurs:

• The client uses its own private key to sign the message
• It then uses the service public key to encrypt the message
• The service uses its own private key to decrypt the message
• And then uses the client public key to verify the signature
• For the response, the opposite happens: the service uses its private key to sign the response
• And then uses the client public key to encrypt it
• The client the decrypts the response using its own private key
• And verifies the signature using the service public key

Asymmetric Binding with Derived Keys

Just as the case of symmetric binding, derived keys can also be enabled when using the asymmetric binding.

However, when the tokens used are of type X509 certificates, there is really no advantage of enabling derived keys, because encryption and signature are already being achieved using different keys.

WCF Binding Elements

WCF implements the three WS-SecurityPolicy binding assertions, using three corresponding binding element classes:

• AsymmetricSecurityBindingElement
• SymmetricSecurityBindingElement
• And TransportSecurityBindingElement

All of which are derived from the abstract binding element class SecurityBindingElement.

If we revisit the WCF channel stack,  recall that the SecurityBindingElement resides in the channel layer as illustrated in this diagram.