Design principles

Ubikom is based on the following design goals:

• User identity must be controlled by the user - the concept known as Self-Sovereign Identity.
• There is no central authority controlling the Ubikom ecosystem. The avatar registry is decentralized and widely distributed.
• Users must have freedom to decide how to compromise between security and convenience. Users might decide to delegate their authority to a third-party system, a decision that can be revoked at any time
• Communications must be private and secure by default, and easy for non-technical users. In Ubikom ecosystem, only signed and encrypted messages can be sent without a need for special configuration
• Core software must be open-source

• Individual users must be able to register their avatars free of charge.
• The system must be resilient to prevent spam and abuse.
• The system must work with existing email clients.
• Native Ubikom client will support messaging and authentication.

Architecture Overview

The system components include:

• Identity Server, responsible for registering and querying user identity.
• Dump Server, responsible for storing encrypted messages.
• Email Proxy, responsible for encrypting and decrypting messages and supporting calls from the clients via POP3 and SMTP protocols.
• Gateway server, responsible for interfacing with the legacy email system.

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:

• Public keys and related data (a public key may be disabled, for example)
• Names. Each name is associated with a public key.
• Addresses. Each address is indexed by name and protocol, and basically means "if you want to communicate with me using this protocol, this is where you can find me".

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:

• Stage 1: Single node identity registry
• Stage 2: Single node identity registry publishing verifiable database snapshots.
• Stage 3: Distributed identity registry with fixed number of nodes.
• Stage 4: Distributed identity registry with dynamic nodes.

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.

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:

• Encrypting and decryption messages
• Registering names
• Registering addresses
• Registering key relationship
• Disabling the key

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.