# 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 userId 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 (opens new window),
stockée dans le navigateur avec localforage (opens new window)
dans le databasePath donnée à l'initialisation du SDK.
Cette base de données est chiffrée en AES
avec SSCrypto (opens new window),
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.