Skip to content
Marcela edited this page Apr 28, 2015 · 11 revisions

Welcome to the CONIKS reference implementation Wiki!

Introduction

As secure messaging/email applications become more wide-spread, users still face the difficulties of key management. Even if existing secure messaging applications have built-in key management, these often still do not have a way for users to ensure that the keys for their friends/contacts remain consistent over time and across users. We have developed CONIKS to address this issue. CONIKS is a key management service for end-user public keys that integrates into existing secure messaging systems. It requires centralized identity providers to maintain consistent bindings of names to keys in directories containing all bindings registered under their individual namespaces/domains. Because these key directories are cryptographically verifiable, identity providers do not need to be trusted, which allows clients to verify the consistency of bindings in-band. This means that users do not have to worry about verifying keys out-of-band, or managing keys altogether.

CONIKS Design

How do clients check the consistency of bindings?

In a strawman design, each client could periodically download the entire key directory and check that each individual bindings is included in the provider's directory and has not changed unexpectedly since the last check. Then to check that each client is seeing a consistent view of the provider's directory, each client exchanges and compares its version of the key directory with every other client. This way, all clients can be sure that all bindings in the provider's key directory are consistent over time and across different "locations". But this is very wasteful in terms of storage and bandwidth.

Our design for CONIKS focuses on making consistency checks more efficient. First, we divide time into epochs. This allows providers to create snapshots of their entire key directory at regular time intervals. Thus, clients no longer have to check all individual bindings in a directory. Second, providers also distribute their snapshots to other providers in order to build a verifiable history of their directory. Third, the snapshots providers generate are digitally signed so they cannot later deny having created them.

Protocols

CONIKS provides four main protocols for checking the consistency of bindings.

  1. Registration: register new name-to-key bindings, or update existing bindings with new keys.
  2. Key Lookup: verify that the requested binding is consistent with the key directory snapshot in a given epoch.
  3. Monitoring: check validity, i.e. the key in a requested binding has not been replaced with a spurious key.
  4. Auditing: check for non-equivocation, i.e. clients and providers see consistent directory snapshot histories.
Clone this wiki locally