Seald: documentation

Français

English

Français

English
Sur cette page

Réversibilité ​

Le chiffrement effectué avec Seald-SDK est réversible sous certaines conditions.

La réversibilité consiste à déchiffrer l'ensemble des données chiffrées avec Seald pour les ré-enregistrer d'une autre façon. La procédure de réversibilité peut être effectuée de deux façons :

  • soit côté client, ce qui maintient la garantie que rien n'est accessible côté serveur ;
  • soit côté serveur, mais cela peut engendrer une violation de la confidentialité des données.

Une donnée chiffrée avec Seald pour un Utilisateur de votre application peut-être déchiffrée hors-ligne en réunissant les éléments suivants :

  • sur le backend : la donnée chiffrée elle-même contenant son identifiant unique messageId ;
  • sur l'API Seald : la clé symétrique chiffrée avec la clé publique de l'Utilisateur associée à ce messageId ;
  • sur le frontend : l'identité Seald de l'Utilisateur contenant ses clés privées.

À partir de ces 3 élements, il est possible de déchiffrer la donnée hors-ligne par exemple avec l'outil en ligne de commande Seald.

DANGER

Dans le cas où l'identité Seald de l'Utilisateur est inaccessible, le déchiffrement des données - et donc la réversibilité - devient impossible.

Données chiffrées ​

Les données chiffrées ne sont jamais hébergées par Seald. Il appartient donc au développeur de les maintenir disponibles.

Clés symétriques chiffrées ​

Les clés symétriques chiffrées pour des Utilisateurs sont stockées sur l'API Seald.

Ces clés sont exportables sur demande aux équipes Seald pour un sealdId donné.

Identité de l'utilisateur ​

L'identité Seald de l'Utilisateur est récupérable de façon différente selon le mode de protection choisi.

Protection par mot de passe ​

Lorsque le plugin @seald-io/sdk-plugin-ssks-password est utilisé, l'identité de l'Utilisateur est chiffrée à l'aide d'une clé symétrique dérivée du mot de passe password connu de l'Utilisateur uniquement, et cette identité chiffrée est stockée sur le service SSKS hébergé par Seald.

Sur demande, Seald peut vous exporter ces identités chiffrées à partir de la liste des userId des Utilisateurs.

WARNING

Dans ce mode, sans le mot de passe connu de l'Utilisateur uniquement, il est impossible de récupérer l'identité de l'Utilisateur.

Protection en 2-man-rule ​

Lorsque le plugin @seald-io/sdk-plugin-ssks-2-mr est utilisé, l'identité de l'utilisateur est chiffrée avec une clé symétrique twoManRuleKey connue du backend, et cette identité chiffrée est stockée sur le service SSKS hébergé par Seald.

Sur demande, Seald peut vous exporter ces identités chiffrées à partir de la liste des userId et adresses e-mail des Utilisateurs.

En combinant cet export avec les twoManRuleKey stockées pour chaque Utilisateur sur le backend, il est possible de reconstituer les identités des Utilisateurs.

TIP

C'est le seul mode où une procédure de réversibilité complète côté serveur peut être mise en œuvre, parce que ce mode n'est pas strictement "de bout-en-bout".

DANGER

En activant la procédure de réversibilité dans le cas d'une protection en 2-man-rule, vous disposerez alors de tous les secrets nécessaires au déchiffrement des données.

Il convient alors de :

  • prévenir ses Utilisateurs que vous pourrez lire leurs données (ce qui peut être contraire à votre politique de confidentialité) ;
  • effectuer cette opération sur une infrastructure sécurisée décorrélée de votre infrastructure de production.

Base de données locale persistante ​

Lorsqu'une base de données locale persistante est utilisée, l'identité de l'Utilisateur est présente dans le navigateur de l'Utilisateur. Celle-ci est dans une base de donnée NeDB, stockée dans le navigateur avec localforage dans le databasePath donnée à l'initialisation du SDK. Cette base de données est chiffrée en AES avec SSCrypto, avec une clé dérivée de la databaseKey donnée à l'initialisation du SDK avec comme sel seald-db-encryption|${appId}.

WARNING

Fonder sa procédure de réversibilité sur la récupération de la clé stockée en base de donnée locale persistante n'est pas recommandé, étant donné que celle-ci peut être effacée par inadvertance par l'Utilisateur final.

Export manuel d'identité ​

Lorsque l'export manuel d'identité est utilisé depuis le SDK, la responsabilité de sauvegarder de façon sécurisée (au sens de la disponibilité, intégrité, confidentialité et traçabilité) incombe au développeur.