Seald: documentation

English

Français

English

Français

Protocols ​

From the Seald application ​

Registration ​

The registration to the Seald solution is done as follows:

  1. When a user first installs Seald, the application generates two asymmetric key pairs. The first is used to prove his identity, called signingKey, and the second is used for encryption, called encryptionKey;
  2. The two public keys are then sent to the Seald servers, and a Seald identity is created for this user (SealdID);
  3. The account chain of signatures is initialized with a key creation transaction, adding these keys.
  4. To authenticate, the user makes a request to the Seald servers, which will answer a "challenge" to be signed with his signingKey in order to prove his identity. This operation is completely transparent to the user, and does not require any password;
  5. At its first use, there is still no email address attached to the user's account. The application will therefore invite the user to enter his email address, which will then be verified by a one-time password. This link allows any user to retrieve the public keys of the message recipients.

When a user installs Seald on an additional device (mobile or computer), two new public/private key pairs are generated on the new device, and can be linked to the existing SealdID via a mutual signature protocol.

File encryption ​

There are two modes of encryption for files :

  • End-to-end encryption mode: This mode is used when both the sender and recipient have the Seald application. Seald secures emails and documents using symmetric encryption. Message keys are then secured with asymmetric encryption, using a private key that never passes through our servers.
  • Authenticated encryption mode : this mode is used when the recipient does not have the Seald application. Seald secures emails and documents only with symmetric encryption and Seald servers become trusted third parties, the decryption will be performed by authenticating the recipient in the browser.

End-to-end encryption mode ​

Encryption ​

The encryption of a Message by a user with the Seald solution for users with Seald is done as follows:

  1. A MessageKey is generated locally on the user's computer wishing to protect a document;
  2. If the recipients of the message are not cached in the application, the public keys to their encryptionKey are retrieved from Seald's servers (from their email addresses);
  3. For each public key thus retrieved, an EncryptedMessageKey is thus generated locally on the user's computer wishing to encrypt the Message;
  4. The Seald client then makes a request to the Seald servers to generate a MessageID. To this request is also attached all EncryptedMessageKey so that they can be retrieved by their respective recipients;
  5. From the Message encrypted using the MessageKey and MessageID, the file in the proprietary Seald format is then generated, ready to be sent to the recipients.
Decryption ​

Once a Message is protected with Seald, the decryption of this document by a user with the Seald solution is done as follows:

  1. The MessageID and the encrypted form of the Message can be retrieved from the file in the proprietary Seald format;
  2. A request is made to the Seald servers to check if an EncryptedMessageKey corresponding to the MessageID exists for the user;
  3. From the EncryptedMessageKey, and using the private key of the encryptionKey, the user can retrieve the MessageKey required to decrypt the file;
  4. The Seald software decrypts the file in a temporary directory, and checks if the file name matches the original. If this is not the case, an alert asking the user to check if the file is the one he wants to open (and not a ".exe", ".vbs", etc.);
  5. The decrypted document is then opened, the decrypted version will be deleted once the work on this document is completed.

Authenticated encryption mode ​

Encryption ​

The encryption of a Message by a user with the Seald solution for users who do not have Seald is done as follows:

  1. A MessageKey is generated locally on the user's computer wishing to protect a document;
  2. The Seald client then makes a request to the Seald servers to generate a MessageID. To this request is also attached the MessageKey for each recipient who does not have Seald in order to be converted into EntrustedMessageKey so that it can be retrieved by their respective recipients;
  3. From the document encrypted using MessageKey and MessageID, the file in the proprietary Seald format is then generated, ready to be sent to the recipients.
Decryption ​

Once a Message is protected with Seald, the decryption of this document by a user who does not have the Seald solution is done as follows:

  1. The file in the proprietary "Seald" format is presented under the extension ".seald", to decrypt the file, users without Seald need to use the decryption page available here;
  2. The user will be invited to click on a button, thus retrieving the cryptographic primitives allowing to decrypt the message from our web servers. The MessageID and the encrypted form of the Message are injected into the context of the decryption page opened in the browser;
  3. The user must then authenticate himself on Seald's servers by email in order to prove his identity;
  4. Once authenticated, the user sends a request to Seald's servers to verify that an EntrustedMessageKey is assigned to him;
  5. From the EntrustedMessageKey, the Seald servers send him the MessageKey of the document, necessary for decrypting the file;
  6. Still in the browser, the file is then decrypted, and if the format allows it (PDF, Office documents,...), it is displayed directly in the browser, otherwise it is offered for download.

Access control ​

With Seald's encryption protocols, it is possible to do a number of operations afterwards on EntrustedMessageKey and EncryptedMessageKey or a Message, for example event logging, revoking or adding a recipient.

Add a recipient ​

A Seald user who is recipient of a Message can add another recipient, with or without Seald:

  1. Get, like when decrypting, the EncryptedMessageKey of the Message destined for the user.
  2. Decrypt the EncryptedMessageKey in order to get the MessageKey of the Message.
  3. If the recipient has Seald (end-to-end encryption mode), encrypt the MessageKey for the public keys of the user's encryptionKey to generate an EncryptedMessageKey for each of their public keys. If not (authenticated encryption mode), convert the MessageKey into a EntrustedMessageKey for the recipient.
  4. Send each EncryptedMessageKey or the EntrustedMessageKey to Seald's servers along with the MessageID.

Revoke a recipient ​

A Seald user who has authorized someone else (with either the end-2-end or authenticated encryption mode) can revoke their access.

The user only needs to contact Seald's servers saying they want to revoke a specific Message for a specific recipient. The server will remove each corresponding EncryptedMessageKey or EntrustedMessageKey.

Sending files ​

From the Seald desktop application, it is possible to generate a sharing link that looks like this:

https://decrypt.seald.io/decrypt/#LGknPgbURSCvfcIGNR56Ba_h9v+WYlpwaX8mbqNZRQchwArVK2sG1XiMULlamXRYBLUTyFDMMw+Q3XMJiwUAB58+EpmP6HsXeOjutvdsJRrEw

Persons authorized to decrypt the document will be able to download the encrypted file and open it either via the desktop application either via the authenticated mode.

  1. the file is encrypted for recipients to give an end-to-end encrypted seald file for the recipients with a Seald account, and in the authenticated mode for recipients without one;
  2. a new MessageKey2 is generated locally on the computer of the user wishing to generate a link for a document ;
  3. the Seald client encrypts this MessageKey2 for its own public keys to obtain an EncryptedMessageKey2 and sends it to the server which assigns it a MessageID2. This is only done so that the link can be reconstructed afterwards ;
  4. the Seald client encrypts the file (already encrypted normally with Seald) with this MessageKey2 to give a super-encrypted file ;
  5. the Seald client asks the server for an UploadID;
  6. the Seald client sends the super-encrypted file to the server;
  7. the Seald client creates a link in https://send.seald.io/decrypt/#UploadID_MessageKey2 format where MessageKey2 and UploadID are encoded in base64.

Let's underline that in this protocol the server does not know about MessageKey2 since only the URL hash of the link contains it, and this URL hash does not pass through the server.

Let's also underline that the sole knowledge of the link is not enough to read the document, since the file sent to the server is already encrypted with the classic Seald file encryption protocol.

This means that the file, although hosted on the Seald server, is unreadable by the server, and the sharing link is not transferable.

  1. the user opens the link in the format https://send.seald.io/decrypt/#UploadID_MessageKey2 in a recent browser (Internet Explorer is not supported) ;
  2. the Seald lightweight client in Javascript downloads the super-encrypted file associated with the UploadID ;
  3. the Seald lightweight client in Javascript decrypts this super-encrypted file with MessageKey2 ;
  4. the seald file is available for download or preview by following the usual Seald file decryption methods (either end-2-end or authenticated).

Event logging ​

Each action that involves Seald's servers on a Message — like an encryption, decryption, revocation or adding a recipient — is logged. The full list of the events is available here.

From Seald Filedrop ​

Encryption ​

The encryption of a file or several files by a person with the link of a Seald Filedrop page is done in the following way (for 1 given file) :

  1. The public keys for the page's recipients are retrieved from the Seald servers (which have been previously associated with the Seald Filedrop page);
  2. A symmetric MessageKey is generated in the browser;
  3. For each public key thus retrieved, an EncryptedMessageKey is generated ;
  4. The file is encrypted using the MessageKey and sent encrypted to the Seald servers;
  5. The Seald servers form the Seald document from the raw encrypted file in the page, and a newly generated MessageID.