Askemos

Request Dispatch Overview

Abstract

Running applications in an Askemos network slightly changes the landscape from the security point of view, since trust in Askemos comes from assertions about past message patterns.

However from the engineering view, some consequences are of interest because it sometimes provides a benefit (helps load balancing and saving network traffic) while in other settings the opposite is the case.

This (draft) outlines the basic message flow and outlines security related decisions user may choose.

Request Coming In

The following sketch outlines the first stage of request processing.

Incoming requests from client programs such as (but not limited to) Web Browsers, WebDAV file systems etc. are sent by the client program to the Askemos Peer process. (The arrow marked as (1).)

The peer will relay the request in the name of the user to the notary servers (a MRC) where the request is processed. (Those arrows with a (2).)

"Looking At" vs. "Changing" the World

There's already the first thing to detail more: request which may change the network state will be replicated to all, or at least most, of the replica while read only request are normally relayed to just one.

In the case of read only access it will help with load balancing, while write operations receive a penalty. This is the actual cost of the system. Askemos trades some additional communication effort for the gain trust and error resilience. (Future version will certainly allow to share the upload burden among all peers.)

Where is my Peer Software?

The peer software relays request in the name of the user. Users will want to take care that it is under their control.

Preferable the peer software will run on the same device as the client software. Or at least within the local network if the user chooses to. Depicted by the grey rectangle "User's Trusted System".

Alternative remote access, where the peer software would be not under control of the user are possible. However depreciated: if the peer is already remote, some attacker could use the remote software to forge stage (2) request replication. However in reality applications need to process requests coming in from a non-Askemos aware environment. That's where one just needs it.

A practical note by the way: in the recommended mode of operation the communication (1) is local. There is little reason to increase the client's complexity to reduces network load.

Where Goes The Data

Data is replicated at all peers registered to run/support the process instance (the "place"). This is a property of the running process and may migrate, expand or shrink over time among notaries at the discretion of the process.

No peer's vote is considered without prior registration. The registration is under control of the process itself. Neither sudden joins exist nor can a centralized decision maker allow/deny join requests.

In plain English: it depends on where you drop it.

Who Controls The Authentication

So, if the peer relays (2) in the name of the user, how is the authentication done?

In theory this is already out of the scope of Askemos.

Notably there is not requirement of a single or even common authentication scheme.

In fact it improves the security of the whole system, when those messages authenticated using different schemes. (Or, if used with X509 certificates, at least trusting in different CA's.)

Processing In Agreement

Once the transaction request has been received by at least the qualified majority of the commissioned peers (as controlled by the configuration of the service) the processing stages is entered.

All selected hosts will locate the associated contract (the source code) for the service. Then execute it to obtain updates to local state and further transaction messages, which might have to be sent.

However updates and messages are held back until the byzantine agreement protocol has reached the commit stage.

The agreement protocol requires two rounds of message exchanges (step "3" in the next picture) between those selected peers. Each message is signed by the peer approving the transition. Note that the users peer (representative) may or may not be involved here.

Once the protocol has consummated, changes are committed to permanent memory and additional messages may be sent out to trigger further processing and eventually a result will sent back to the client program.

Signature Validation

The integrity of the signed document and the "digital signature" can be attested even after the mechanism by which the signature was obtained is gone. Much in contrast to signatures tied cryptographically to the data, where the signature is useless once the private key is revealed or the cryptography is broken.

After the protocol has established a stable state, the stability of the state depends no longer on the cryptographic means (keys, certificates) used to reach the agreement. It depends instead on two other factors: a) the integrity (and honesty) of the majority of the chosen notary services and b) on the plausibility of the chain of states wrt. the agreement protocol.

If any key or even the authentication mechanism used to complete the transaction is broken at any time after the fact, the fact will be unimpressed. Trust in authentication mechanisms (as required for communication) is not coupled to the trust in integrity preservation. (In plain English: When doing notary service for someone, you convince yourself about the signature pertaining to the signer, you need to trust the authentication now. When later asked to testify whether or not there was a signature, you recall the fact from you data. You do NOT try to re-validate the old authentication mechanism again.)

Privacy Considerations

By selecting notary services from trusted providers, users ensure their privacy. More precicely their balance between secrecy and autonomy wrt. the topic.

Instead of leaving all personal data with a single, large provider - and thereby including all of providers employees into the users trusted system wrt. the data in question, user have a choice.

Share hosting of your personal blog, photos etc. with your friends; share medical data with your doctors and financial data elsewhere again.

Public Services

Tuning the balance towards the other end, public services can be build. When public databases of facts or proofs (for instance logs of certificates issued by some authority, public registries (a.k.a DNS replacements - some old ideas here) or even wikipedia style public knowledge) are shared over several independent notary service providers fraudulent entries will be "routed around".

In this case the code (the contract) as executed in byzantine agreement must simply implement proper policies on updates (e.g., "append only", bookkeeping style zero sum double entry etc.).

See also Certificate Authority Transparency and Auditability by Ben Laurie and Adam Langley -- Certificate Authority can harm.

Securing a convergence notary service against byzantine failures would be another trivial application. (To be done when time permits.)

Summary

The Askemos system does require to trust in any single third party. Nor does it require long term trust in any cryptographic mean to establish trust in factual assertions.

Instead of relying in "currently hard to solve" problems staying hard to solve over time - the problem cryptographic signature schemes have - it derives trust from communication patterns and "on-average" honesty of peers chosen to be trusted wrt. selected concerns.

In so far the whole system is not even new: it models an ages old pattern of human behaviour: make sure there is witness (backup knowledge) to relevant events. Plus at the same time control whereto data possibly flows.