# 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
- on the Seald API: the symmetric key encrypted with the User's public key associated with this
- 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.
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
# User's identity
The User's Seald identity is retrievable in different ways depending on the protection mode chosen.
# Password protection
@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
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
@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.
This is the only mode where a full server-side egress procedure can be implemented, because this mode is not strictly "end-to-end".
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:
- 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 (opens new window)
database, stored in the browser with
localforage (opens new window)
databasePath passed during the SDK's initialization.
This database is encrypted in AES
SSCrypto (opens new window),
with a key derived
databaseKey passed during the SDK's initialization with salt
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.