Section 13.10. Non-Repudiation


13.10. Non-Repudiation

Sometimes the parties in a business transaction will have a dispute. To protect the interests of these parties, some evidence of the agreement must be generated and preserved, in the event that a third party must be called in to resolve the dispute. In the case of transactions initiated via Web service messages, this evidence must consist of Proof of Message Origin, Proof of Message Receipt, and Original Message content.

Secret-key cryptography alone is not sufficient to prevent the denial of an action that has taken place, such as the initiation of an electronic transaction. One can apply data privacy in such a scenario, but the fundamental flaw of a non-repudiation scheme based on secret-key cryptography is that the secret key is dispensed to more than one party.

13.10.1. Data Integrity and Data-Origin Authentication

At a much lesser cost than encrypting the entirety of a plain text, data integrity and data-origin authentication can be ensured by a secret cryptographic scheme using a Message Authentication Code (MAC) function.

The basic idea is to attach to each message, m, that is sent across a network the result, h(m), of a mathematical function, h, applied to m itself. If an error has occurred during the message's transmission, and the received message, a, is different than m, the message's receiver can detect the anomaly by independently computing h(a) and comparing it with h(m).

Figure 13-3. Using MACs to detect anomalies.


The main component of a MAC function is a hash digest function, which is considered to be one of the fundamental primitives in modern cryptography. By definition, a hash digest function is a deterministic function that maps a message of arbitrary length to a string of fixed length, n. Typically, n is 128 or 160 bits. The result is commonly known as a message digest. Because the original data is often longer than its hash value, this is also referred to as the original message's fingerprint.

Figure 13-4. Computing message hashes.


Of course, a hash digest function is inherently non-injective. In fact, the universe of the messages that can be digested is potentially unlimited, whereas the universe of all the message digests is limited by the set of the 2n strings with n bits. Therefore, multiple messages can map to the same digest. However, the fundamental premise is that, depending on the strength of the hashing algorithm, the hash value becomes a more compact representation of the original data. This means that it should be computationally infeasible to produce two messages having the same message digest, or to produce any message having a specified target message digest.

Message Digest V5 (MD5) and Secure Hash Algorithm V1 (SHA-1) are the most widely used cryptographic hash functions. MD5 yields a 128-bit (16-byte) hash value, while SHA-1 results in a 160-bit (20-byte) digest. SHA-1 appears to be a cryptographically stronger function. On the other hand, MD5 edges SHA-1 in computational performance and thus has become the de facto standard.

Hash functions alone cannot guarantee data integrity because they can't guarantee data-origin authentication, or the ability to authenticate the originator of a message. The problem with digest functions is that they are publicly available. If a message, m, is intercepted by an adversary after being transmitted by Alice, the adversary can change m into a different message, m', compute h(m'), and send Bob the pair, (m'..h(m')). By simply applying the function h to the received message, m', Bob has no means to detect that an adversary has replaced m with m'.

Data-origin authentication is inherently supported by secret-key cryptography, provided that the key is shared by two entities only. When three or more parties share the same key, however, origin authenticity can no longer be provided by secret-key cryptography alone. Various secret-key authentication protocols have been developed to address this limitation.

In contrast to using a simple hash function to digest a message, a MAC function combines a hash digest function with secret-key encryption. This yields a value that can be verified only by an entity that has the secret key. This enables both data integrity and data origin authentication.

Another simple way to achieve data integrity and data origin authentication is to apply a regular hash function, h, such as SHA-1 or MD5. But rather than hashing the message, m, alone, the message is first concatenated with the key, k, and then the result of the concatenation is hashed. In other words, the sender attaches to the message m the tag h(k, m). This solution has some theoretical weaknesses, however. A more reliable solution consists of attaching the tag h(k, h(k, m)).

A MAC can even be computed by using a secret-key block-cipher algorithm. For example, the last cipher text block, encrypted in CBC mode, yields the final MAC value. Therefore, the MAC so defined is a compact representation of the entire message that can be computed only by an entity that has the secret key. Known instances of this procedure employ DES and Triple-DES, resulting in DES-MAC and Triple-DES-MAC, respectively.

A MAC mechanism that uses a cryptographic hash function is also referred to as HMAC. HMAC is specified in [HMAC].

WS-Security currently does not provide a mechanism for non-repudiation. The following is one way to profile extending Web Services Security to provide Proof of Message Origin (PMO) and Proof of Message Receipt (PMR).

13.10.2. Proof of Message Origin

Proof of message origin (PMO) consists of a digital signature over original message content. Potentially, this could be a digital signature, generated by the initial sender and provided to the ultimate receiver, that envelops the entire original message. However, for Web service messages, this method is unacceptable because intermediaries might partially process the message en route from the initial sender to the ultimate receiver, altering some subset of the content. To allow for this possibility, the subset of the message content should be signed by the initial sender and targeted at the ultimate receiver, and it must not include the subset of the content that any intermediaries could alter. The initial sender should create a Web Service Security-conformant XML Signature that binds and provides origin authentication for the following message elements:

  • The <SOAP:Body> element containing the application-specific message data (SOAP 1.2)

  • A <wsa:MessageID> header block element that uniquely identifies the message (WS-Addressing)

  • A <wsa:From> header block element that identifies the initial sender (WS-Addressing)

  • A <wsa:To> header block element that identifies the intended ultimate receiver (WS-Addressing),

  • An <wsa:Action> header block that identifies the intended message semantics (WS-Addressing)

  • A <wsse:KeyInfo> element that identifies the signer's (AKA initial sender's) security token (XML Signature)

  • Any additional header block elements targeted to the ultimate receiver

The initial sender's signature does not refer to the outer SOAP Header element, because that would prevent insertion and removal of individual header block elements not targeted to the ultimate receiver. The initial sender, ultimate receiver, or a third-party store the signed message content in case of a dispute.

13.10.3. Proof of Message Receipt

PMO provides the mechanism for resolving disputes related to message content. However, an ultimate receiver might still claim never to have received a message at all. PMR provides a solution to this problem.

PMR consists of a digital signature over the received message content. This could be a digital signature, generated by the ultimate receiver and provided to the initial sender, enveloping the entire original message. However, for Web service messages, this method is unacceptable. Intermediaries might partially process the message en route from the ultimate receiver to the initial sender, altering some subset of the content. To allow for this possibility, the subset of the message content signed by the ultimate receiver matches the subset of the message content signed by the initial sender and targeted at the ultimate receiver. The ultimate receiver, initial sender, or some third-party store the signed PMR in case of a dispute.

13.10.4. Delivery of Proof of Message Receipt

In some cases, messages are sent that result in immediate synchronous responses, and in other cases, responses might be delivered asynchronously. Therefore, one should provide a mechanism for delivering <ReceiptAcknowledgement>, either together with the response or separately.



    Web Services Platform Architecture(c) SOAP, WSDL, WS-Policy, WS-Addressing, WS-BP[.  .. ] More
    Web Services Platform Architecture(c) SOAP, WSDL, WS-Policy, WS-Addressing, WS-BP[. .. ] More
    ISBN: N/A
    EAN: N/A
    Year: 2005
    Pages: 176

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net