Seald: documentation

English

Français

English

Français

Egress procedure ​

The encryption performed with Seald-SDK is reversible under certain conditions.

The egress procedure consists in decrypting all the data encrypted with Seald to re-encrypt them in another way. The egress procedure can be performed in two different ways:

  • either on the client side, which still guarantees that nothing is accessible on the server side;
  • or on the server side, but this can lead to a breach of confidentiality.

Data encrypted with Seald for a User of your application can be decrypted offline by putting together the following elements:

  • on the backend: the encrypted data itself containing its unique identifier messageId;
  • on the Seald API: the symmetric key encrypted with the User's public key associated with this messageId;
  • on the frontend: the Seald identity of the User containing his private keys.

From these 3 elements, it is possible to decrypt the data offline for example with the Seald command line tool.

DANGER

In the event that the User's Seald identity is inaccessible, data decryption - and therefore the egress procedure - becomes impossible.

Encrypted data ​

Encrypted data is never hosted by Seald. It is therefore up to the developer to keep it available.

Encrypted symmetric keys ​

Encrypted symmetric keys for Users are stored on the Seald API.

These keys are exportable upon request to Seald teams for a given sealdId.

User's identity ​

The User's Seald identity is retrievable in different ways depending on the protection mode chosen.

Password protection ​

When the @seald-io/sdk-plugin-ssks-password plugin is used, the User's identity is encrypted using a symmetric key derived from the password password known only to the User, and this encrypted identity is stored on the SSKS service hosted by Seald.

Upon request, Seald can export these encrypted identities to you for a given list of userId.

WARNING

In this mode, without the password known only to the User, it is impossible to recover the User's identity.

Protection with 2-man-rule ​

When the @seald-io/sdk-plugin-ssks-2-mr plugin is used, the user's identity is encrypted with a symmetric key twoManRuleKey known to the backend, and this encrypted identity is stored on the SSKS service hosted by Seald.

Upon request, Seald can export these encrypted identities to you from the list of userId and email addresses of the Users.

By combining this export with the twoManRuleKey stored for each User on the backend, it is possible to reconstruct the Users' identities.

TIP

This is the only mode where a full server-side egress procedure can be implemented, because this mode is not strictly "end-to-end".

DANGER

By triggering the egress procedure in the case of 2-man-rule protection, you will then have all the secrets necessary to decrypt the data.

You should then:

  • warn its Users that you will be able to read their data (which may be contrary to your privacy policy);
  • perform this operation on a secure infrastructure that is not connected to your production infrastructure.

Persistent local database ​

When a persistent local database is used, the User's identity is stored in the User's browser. It is in an NeDB database, stored in the browser with localforage at the databasePath passed during the SDK's initialization. This database is encrypted in AES with SSCrypto, with a key derived from the databaseKey passed during the SDK's initialization with salt seald-db-encryption|${appId}.

WARNING

Basing your egress procedure on retrieving the key stored in a local persistent database is not recommended, since it can be inadvertently deleted by the end User.

Manual identity export ​

When manual identity export is used from the SDK, the responsibility to save securely (in the sense of availability, integrity, confidentiality and traceability) lies with the developer.