Design principles

Ubikom is based on the following design goals:

Usability requirements are:

Architecture Overview

The system components include:

The identity server is the most important component. It is currently running in beta on an Ethereum-inspired blockchain. It can be used on its own to support this and many other use cases. The rest of the components are there to implement the full working email backend.

Identity Service

Identity service is responsible for registering keys, names, and addresses. The information is stored in the decentralized identity registry.

The identity service exposes two interfaces: identity registration and identity lookup:

In order to locate other users public key, we use the identity registry. The registry is a key-value store, which contains the following entities:

It is essential that the identity registry is decentralized and distributed, without any central authority controlling it. The complete decentralization will be achieved in the following sequence:

Currently, we are at the Stage 3.

Storage Server

Dump server stores encrypted messages temporarily, allowing recipients to pick up their messages as needed.

It has only two methods - sending and receiving messages. Anyone can send a message, but only the owner of the private key can receive messages addressed to it.

It's up to the user to decide how to receive their messages. The identity registry contains a record specifying the endpoint where a dump server (or another server implementing same interface) is located.

Email Proxy

To make everything working end-to-end without coding new email clients, we want to take advantage of the existing clients. A translation layer is required to convert gRPC calls (used between Ubikom components) to SMTP/POP3 calls used by email clients. The encryption and decryption is handled on the fly by the email proxy.

Ideally, each user would run email proxy on their machine, to keep control over their private keys. This requirement, however, would limit the adoption, and would not answer the question of how to handle potential web clients.

If we were to run public email proxy, we would need a way to transmit user credentials to the proxy, without risk of losing control of the user's private key. To do that, we use concept of limited authority delegation to the email proxy while keeping the ultimate authority over user's private key.

Delegating Authority

When a private key is created and registered, it is required to perform any action associated with this key, which include:

Email proxy only needs encryption and decryption. If we were to send user's private key to the public proxy, we would risk the key being compromised, allowing all the operations listed above.

To handle this situation, we introduce another key, which is registered as a child of the main key. Child keys are only allowed to perform encryption and decryption, but none of other operations.

Child key is transmitted to the email proxy in a secure way, and then used to encrypt outgoing messages and decrypt incoming messages.

If the child key is compromised, the user would use the main key to generate another email key, disable the previous one, and transfer name and address registration to the new key.

In fact, it might be a good idea to do email key rotation on a regular basis.