Overview ​

The objective of the Seald technology is to protect data in an application by assuming that the application's servers can become malicious.

Weakness of encryption in transit & at rest ​

Generally speaking, when an application is developed, it is used to intermediate data between several users.

A classical methodology to integrate an encryption policy in such an application is to add encryption in transit and at rest (possibly with an off-site key management in a KMS) as described in the diagram below.

Using only encryption in transit and at rest introduces a structural weakness: the back-end has the data in clear text (at least during execution).

Defensive attitude towards the hosting provider ​

What Seald proposes is to adopt a defensive attitude towards the hosting provider and consider that it can be compromised.

For more information on the motivations behind this seemingly radical attitude, please refer to our white paper.

Client-side encryption ​

The only way to ensure that a hosting provider (which is considered malicious) cannot read the data is to not allow it to read the data it manipulates by using "end-to-end" encryption that is performed on the client side.

Seald provides a turnkey solution for implementing client-side encryption in web, mobile and desktop applications.

Diagram ​

In a simplified way, here is how the Seald-SDK integrates:

Data is encrypted using the Seald-SDK from the front-end of the application (web, mobile, desktop).

To perform encryption, the Seald-SDK uses the user's identity which is generated when the account is created and can be retrieved using one of three methods:

• secure storage: the identity is stored locally on the device (using a persistent local database);
• password protection : the identity is encrypted with a password known by the user using @seald-io/sdk-plugin-ssks-password;
• 2-man-rule protection : the identity is split into two "halves" and distributed between two trusted entities using @seald-io/sdk-plugin-ssk-2mr;

The Seald-SDK distributes keys to recipients through the Seald API, which allows to:

• retrieve the public identities of other users;
• create a new key and distribute it encrypted end-to-end to other users;
• authorize, revoke other users or groups to access previously encrypted data;
• get a key encrypted for yourself to decrypt encrypted data.

For more information, see the specification of the cryptographic algorithms used, as well as the specification of the encryption protocols