"Non-repudiation refers to a state of affairs where the purported maker of a statement will not be able to successfully challenge the validity of the statement or contract." [wikipedia]

Non-repudiation is an essential component of any digital transaction system that involve the changeover of money or property.

Askemos applications enable the human users to exchange information – contracts, images, money, etc – in such a way so as to guarantee all transitions can not be repudiated. Askemos accomplishes non-repudiation by using networks of computers called notary device, or notary for short.

Each user has (normally and at least) one notary they alone operate. A notary device in this role is termed a representative. The owner of a representative gets to choose which applications (scripts a.k.a. contracts, e.g. wallets, diaries and so on) it may run and for each of those to choose additional notaries that are collectively trusted to officiate the operation. This makes it so no one can cheat.

A wallet to manage funds – as documented here – would be a typical example application that requires such assurance. Though any kind of "software agent" could be used that way.

Repudiation in Askemos

If a user needs to repudiate the authenticity of a signature for a transaction in Askemos, we resort to human intervention. Users need to physically "pull the plug" by disconnecting their personal representative from the notary network. This preserves their evidence of the state of affairs, which they can present to the legal authorities or arbiters of the network. Arbiters are typically the owners of the notaries who are commissioned to audit the repudiated object.

Non-repudiation in digital security

Citing wikipedia with minor edits:

Regarding digital security, the cryptological meaning and application of non-repudiation shifts to mean:

  • A service that provides proof of the integrity and origin (provenance) of data.
  • An authentication that can be asserted to be genuine with high assurance.

Proof of data integrity is typically the easiest of these requirements to accomplish. A data hash is usually sufficient to establish that the likelihood of data being undetectably changed is extremely low.

This "easiest" requirement is accomplished by the implementation: every object and every change is identified by a canonical hash. (see also OID)

Trusted third parties (TTPs)

Citing wikipedia again:

The ways in which a party may attempt to repudiate a signature present a challenge to the trustworthiness of the signatures themselves. The standard approach to mitigating these risks is to involve a trusted third party.

The two most common TTPs are forensic analysts and notaries.

To aid forensic analysis, users keep their own representative and switch it off to preserve all evidence in case of doubt. (See "Repudiation in Askemos" above.)

Otherwise there is little to add to wikipedia when it comes to the duty of notaries:

A notary provides a witness whose job is to verify the identity of an individual by checking other credentials and affixing their certification that the party signing is who they claim to be. Further, a notary provides the extra benefit of maintaining independent logs of their transactions, complete with the type of credential checked and another signature that can independently be verified by the preceding forensic analyst. For this double security, notaries are the preferred form of verification.

Askemos's "notary devices") operate in a similar fashion, only translated into a digital space:

A notary device is essentially an "electronic witness" whose job is to verify the identity of a representative by checking other credentials and affixing their independent certification that the representative signing is what they claim to be. Further, a notary maintains independent copies of their transactions, complete with the current state of the contract, a time-stamp, and the type of credential checked.

Importantly, only when enough independent notaries have approved an identical transaction, is the transaction allowed to take place. A human analogy would be having not only one, but 2 or more independent certified notaries check every datum pertaining to the transaction plus verify each other correctly doing so. This provides additional assurance to both business people that the credentials and veracity of each are "doubly verified". For this double (or triple) security, notaries are the preferred form of verification. In Askemos one can have more than 2 or 3 third parties – and, its software can perform multiple independent checks much, much more swiftly than any human agent.

Note that just one notary is still a trusted third party in the strict sense of "trusted" meaning being able to fail, possibly due to malice, thereby being able to break the specific security policy. By commissioning multiple notary devices from different operators, users create their "trustworthy network" according to their personal preferences.

Currently the Askemos implementations use byzantine agreement to implement consensus on active replication among notaries.

Side-note: A popular consensus protocol these days is the Bitcoin "block-chain". This "block-chain" is a Merkle tree just like the versions of places in our implementation. Therefore it seems to be a viable alternative and maybe we'll see an implementation of Askemos on top it. The Ethereum project is working on something like this. The Bitcoin protocol however requires a proof-of-work instead of our commissioned notaries majority vote. This makes Bitcoin much lower and resource hungry, while I fail to see an advantage over the notary concept. I expect it to be too slow for any practical purpose. I might be wrong at that. Time will tell.