The “He said, She said” dilemma – where one person claims a certain version of events that’s in partial or complete opposition to the story maintained by another – has been part of human interaction pretty much since the dawn of communication itself.
Disputes of this kind are typically resolved through a majority show of faith in one of the scenarios presented (as in the verdict delivered by a jury), or more practically through the verifiable evidence of a third party or witness to the actual events. This latter solution is in essence what non-repudiation is all about.
What is Non-repudiation?
In dictionary and legal terms, a repudiation is a rejection or denial of something as valid or true – including the refusal to pay a debt or honor a formal contract. Flip that on its head, and non-repudiation translates into a method of assuring that something that’s actually valid cannot be disowned or denied.
From the point of view of information security, non-repudiation usually applies to cases of a formal contract, a communication, or the transfer of data. Its aim is to ensure that an individual or organization bound by the terms of a contract, or the parties involved in a particular communication or document transfer are unable to deny the authenticity of their signatures on the contract documents, or that they were the originator of a particular message or transfer.
Classic analog examples of non-repudiation methods would include the signatures and documentation associated with a registered mail delivery (where by signing, the recipient is unable to deny having received that court summons from the utilities company), or the recorded presence of witnesses to the signing of a legal document or treaty.
Clearly, non-deniability in a communications or data transfer context cannot be achieved if the true identities of both parties to the dialog cannot be confirmed. So some reliable means of authenticating these parties has to be put in place. These methods might range from the Kerberos authentication protocol used to validate procedures on most operating systems to a simple Message Authentication Code.
But authenticity by itself isn’t enough to guarantee non-deniability. For example, the SSL or TLS authentication protocols used for internet communications can provide an assurance that a given client system is “talking” to its intended server, but there’s no fool-proof method of recording a session which the client could present in the case of a legal dispute with the service provider – which would introduce the element of non-repudiation into the data transfer.
So you can have authenticity/authentication without non-repudiation. But the reverse is not the case. Non-repudiation cannot be achieved without the identities of the concerned parties first having been established beyond reasonable doubt – in other words, authenticity has to be a part of the mix. But it’s not all of it.
Non-repudiation requires the creation of artifacts which may be used to dispute the claims of an entity or organization that denies being the originator of an action or communication. These artifacts consist of:
- An identity
- The authentication of that identity
- Tangible evidence connecting the identified party to a particular communication or action
For email transmission, non-repudiation typically involves using methods designed to ensure that a sender can’t deny having sent a particular message, or that a message recipient can’t deny having received it. Techniques would include email tracking.
Cryptographic hash functions may be used to establish the integrity of transmitted documents. No encryption keys are involved, and strong hash functions are designed to be irreversible. Moreover, they’re designed to avoid collision, which occurs in the rare cases where two separate documents give rise to the same hash value.
Taking this a stage further is HMAC, a technique used to provide data authentication and integrity through the hashing of a document and its transmission with a shared encryption key. However, the very fact that the key is a shared one means that this method lacks non-repudiation.
A digital signature is used to introduce the qualities of uniqueness and non-deniability to internet communications. Each certificate is digitally signed by a trusted Certificate Authority or CA, and its hash value is encrypted with a private key also held by that same trusted CA.
The sender of a message can use a private key to encrypt the hash of the document – giving its digital signature, which is attached to the document as it’s sent. At the other end, the recipient may decrypt the digital signature using a public key. By calculating the hash value of the document and comparing it with the document’s decrypted digital signature (which is also the hash value of the document), the two may be compared to confirm that they match.
With this match established, the recipient is able to confirm who the sender of the message actually is, and which particular message was actually sent. Digital signatures ensure that a document or message has actually been signed by the person who claims to have signed it. In addition, a digital signature can only be created by one person – so that person can’t later deny having been the originator of the transmission.
When a system or application doesn’t include protocols or controls for tracking and logging the actions of its users, the system may be manipulated by malicious intruders, who can forge the identifying credentials of new actions, which can’t be denied with certainty.
In a repudiation attack of this type, erroneous data may be fed into log files, the authoring information of actions on the system may be altered, and general data manipulation or spoofing may occur.
Some Best Practices
Since the strength of digital signature transactions lies in their private keys, care should be taken to store these keys in a secure location (such as on smart cards) to reduce the risk of them falling into the wrong hands.
With some analysts maintaining that digital signatures alone are insufficient to fully guarantee non-repudiation, a mix of measures is advised. Options include supplementing digital signatures with biometric information and other data captured from the sender of a message at the point of transmission.
Share this Post