Uses of XML Signature for Web Services Security

XML Signature finds multiple uses for Web Services security. When used alone, it provides data integrity. When linked to the signer’s identity, it provides nonrepudiation of data content. In addition, it can be used for authentication. When SOAP routing occurs, it can be used for workflow.

Persistent Integrity

Digital signatures ensure data integrity, meaning that if a document changes, then no matter how slight the change, it can be detected. In a Web Services communication, data integrity may also be present at lower layers of the OSI stack (for example, using SSL or IPSec). However, when integrity is implemented only in the course of the SOAP communication, it is not persistent integrity. If the document changes after reaching the Web Service, then the change is undetectable.

This persistent integrity is particularly useful where a document may be composed of portions that are authored by different entities—for example, in a workflow scenario. XML Signature guarantees the integrity of certain portions of a document, but allows participants in a workflow system to edit other unsigned portions of the document.

Nonrepudiation: How Useful Is the KeyInfo Element?

Nonrepudiation extends integrity to link the signature to the identity of the signer so that the signer cannot deny signing the data. The KeyInfo section of signature can be used to reference the public key of the signer. However, this is not enough, because nonrepudiation is achieved by proving that a particular private key, however discovered, was used to create the signature. The <KeyInfo> element may provide hints about the discovery of the private key (often very good hints), but it is optional (and is not necessarily signed). In Chapter 2, we learned that the way in which a certificate authority binds a public key to a person’s identity is by issuing a digital certificate. As well as the use of a certificate authority, nonrepudiation may also involve the use of a timestamping service in order to guarantee the time in which the signature was created.

Nonrepudiation is a feature not provided by session layer or transport layer security. With the use of SSL for B2C (business to consumer) commerce, nonrepudiation was not such an important requirement due to the low value of the transactions involved. The picture is different for the kind of B2B transactions likely to be performed using Web Services, where a small percentage of deniable fraud cannot be tolerated.

Certificate Verification

An additional aspect of nonrepudiation is signature validation.

XKMS provides a means to verify a digital certificate without requiring the use of an ASN.1 processor. The KeyInfo section of an XML Signature is packaged into a SOAP message and sent to an XKMS trust service. See Chapter 10 (XKMS) for more details.

Certificate verification is important since although a signature may verify correctly, the signer’s digital certificate may no longer be valid. This may have occurred because they lost their smartcard, because their password was stolen, or simply because their certificate has expired. A check against an XKMS trust service, or a non-XML system such as a certificate revocation list (CRL) or an Online Certificate Status Protocol (OCSP) responder verifies the current status of the digital certificate.

Authentication

A document that has been signed using XML Signature authenticates the signer, provided that the information in the KeyInfo section of the XML Signature can be tied to the signer’s identity using a digital certificate. If this information is used to authenticate, care should be taken to avoid replay attacks. The next section examines what a replay attack is, and how it can be avoided.

Replay Attacks

If message authentication is required, it is important to avoid a replay attack. Authentication at the session or transport layers involves the use of “choreography” of messages – a challenge, followed by a response – in order to negotiate a secret key.

SOAP-SEC was superseded by WS-Security, but the discussion of replay attacks is useful because it is simple and succinct:

“Digital signatures alone do not provide message authentication. One can record a signed message and resend it (replay attack). To prevent this type of attack, digital signatures must be combined with an appropriate means to ensure the uniqueness of the message, such as nonces or time stamps.”
from SOAP-SEC specification, published on the World-Wide Web Consortium web site (http://www.w3.org/TR/SOAP-dsig/)

Sending the message a second time does not break the integrity of the message, nor does it break the link between the signer of the message and the signed data. It is for these reasons that the replay attack is powerful. It is the equivalent of finding a hand-signed paper document beside a fax machine and resending it. If the document says “Please transfer $1000 into my checking account,” and an imposter sends it again—thus transferring another $1000 into the account—that’s a replay attack.

There are two possible solutions to this problem. One is to separate sender authentication from document authentication. This can be achieved in an HTTP-based Web Services environment by combining client-side SSL with XML Signature in a SOAP message. This ensures that if a duplicate document is received, the sender has been authenticated.

The second solution is to ensure that the digital signature is over data which changes for each message. This type of changing data would include an incremental counter, a nonce, or a timestamp. Returning to the analogy with the re-sent fax, this would be the equivalent of including a printout of the current time in the fax. If a duplicate document was received containing the same time, that would be suspicious.