Blockchain as auditors

Follow our discussion at issue-151.

CONIKS requires an auditing protocol to detect server's equivocation. CONIKS servers broadcast STRs to auditors to validate the hash chain while clients ensure the STRs consistency by querying those auditors. To prevent a malicious server colluding with auditors, the client needs to query STRs from multiple auditors. Thus, we need to maintain a network of auditors who continuously validate every server's STRs and answer query from clients.

We propose an alternative approach to auditing CONIKS's server by using Ethereum.

#Architecture

EthIKS proposed implementing CONIKS server as an Ethereum smart contract. If we consider Ethereum blockchain as an immutable log, there is no need for auditing protocol since the malicious server cannot equivocate transactions in the blockchain log.

However, we think that maintaining the whole CONIKS server inside the blockchain is very costly. It also makes the system depends too much on Ethereum (what if Ethereum collapses in the future).

Instead, we think publishing only the STR to the blockchain is enough for the auditing purpose. Thus, a CONIKS server architecture now becomes

Where

• Geth is the official Ethereum wallet written in GO
• STR is the CONIKS server's Signed Tree Root
• Smart Contract is the code that stores all server's STRs while allows CONIKS clients to efficiently lookup only the STRs they are interested in.

Thus, the client architecture is as follow:

• Where Geth Light is Geth running in light client mode, which only download Ethereum block headers instead of the whole blockchain.
• Unlike full client, Geth Light client does not download the whole blockchain asks Ethereum P2P network for transactions related to interested STRs. The light client downloads only block headers (~ ? bytes per block)
• CONIKS client monitors users' keys by querying CONIKS server then cross checking with Geth Light.

#Security We want to make sure the blockchain scheme offers no less security than the original proposal where CONIKS client queries STRs from multiple auditors.

CONIKS server publishes its STR by executing the smart contract function, creating a transaction and sending to the Ethereum P2P network (via Geth). The transaction is confirmed by miners running POW algorithm on a given block Difficulty where:

• Block Difficulty is calculated purely on timestamp and Difficulty of parent's block.
• Miners run Proof-of-work function to confirm the transaction. In short, miners brute force a nonce so that the output of a mix function among the nonce, the transaction root and some pseudo-random data is smaller than a target difficulty value.
• Ethereum client will switch to whichever chain which has the same genesis block with it and has the highest total difficulty (accumulated from the genesis to the newest block).

The light client connects to other full nodes in Ethereum network to download the block header. There are different situations:

• Client only connects to honest nodes: Best case scenario, system works as intended.
• Client connects to some malicious nodes: Malicious nodes have to provide a longer block-chain to the client since the difficulty value is also included in the header. Unless malicious nodes control more than 50 percent of the total computational power of the network, it is unfeasible to keep fooling the client.
• Client only connect to malicious nodes: Since the difficulty value is included in the header, malicious nodes have to keep providing the light client a chain with valid nonce for each block. Therefore, those malicious nodes have to spend significant amount of computational power to keep fooling the client. If not, the client will observe a plummet in difficulty value or a surge in block interval time. Both of these symptoms can be reported to users.

So the only way for an attacker to attack the auditing process is to spend significant amount of computational power to produce a valid header chain to the light client.

Since the light client only download the transaction header as default, CONIKS client can trigger the light client to download specific transaction related to smart contract by scanning the log bloom filter in the transaction header then sending the result to a full node to get the block body.

Key management

• Server side will need to maintain an extra key pair for the full Ethereum wallet in order to sign the publish STR transaction.
• Client side will not need to care about the key pair since there is no transaction from the client