Zero-knowledge
Secrecy est un service zero-knowledge (à connaissance nulle) : il stocke et transporte les données de vos utilisateurs sans jamais pouvoir les lire. Les données sont chiffrées sur l'appareil, par le SDK, avant d'être envoyées, et les clés qui permettent de les ouvrir n'arrivent jamais sous une forme lisible sur les serveurs Secrecy : Secrecy ne les stocke que verrouillées, et ne peut pas les déverrouiller. Ce qui arrive sur les serveurs est du texte chiffré, et rien d'autre.
Ce que cela change pour votre application
Dans un service classique, le chiffrement a lieu chez le fournisseur : votre application envoie des données lisibles, et le fournisseur les chiffre au repos avec des clés qu'il contrôle. Avec Secrecy, cette étape se déplace dans votre application, à l'intérieur du SDK.
| API cloud / mail classique | Avec Secrecy | |
|---|---|---|
| Où les données sont chiffrées | Sur les serveurs du fournisseur, après l'envoi | Sur l'appareil, par le SDK, avant l'envoi |
| Qui détient les clés | Le fournisseur | Les appareils des utilisateurs uniquement — Secrecy les stocke verrouillées |
| Ce que reçoit l'API | Des données lisibles | Du texte chiffré |
| Ce qu'expose une fuite serveur | Des données lisibles | Du texte chiffré |
| Qui peut traiter le contenu | Le fournisseur, côté serveur | Votre application, après déchiffrement sur l'appareil |
Ce que cela signifie dans le code
Vous ne gérez jamais le chiffrement vous-même. Le client obtenu à la connexion détient les clés de l'utilisateur, et chiffre et déchiffre autour de chaque appel : vous passez des données en clair à secrecyClient.cloud et secrecyClient.mail, et vous récupérez des données en clair. Le fonctionnement interne est décrit dans comment les données sont chiffrées.
Le modèle a quelques conséquences :
- Pas de client, pas de déchiffrement. Lire une donnée chiffrée demande toujours un client connecté en tant qu'utilisateur ayant reçu l'accès. Ni votre backend ni Secrecy ne peuvent la lire à la place de l'utilisateur.
- Le contenu est traité sur l'appareil. Secrecy ne peut ni rechercher, ni indexer, ni transformer le contenu qu'il stocke. Tout traitement de ce type a lieu dans votre application, après déchiffrement.
- Le partage fait partie du chiffrement. Donner accès à quelqu'un, c'est rendre la donnée lisible pour lui : chaque modèle de partage est donc aussi une façon de transmettre une clé.
Ce qui reste lisible
Le zero-knowledge couvre le contenu : les fichiers et leurs noms, les sujets, corps et pièces jointes des mails, les envois anonymes. Ce dont le service a besoin pour stocker et acheminer ce contenu n'est pas chiffré : qui partage avec qui, les tailles, les dates, et les droits accordés sur chaque élément.
Lorsqu'un utilisateur signale un fichier, le SDK transmet volontairement la clé de ce fichier à Secrecy afin qu'il puisse être modéré. Cela n'arrive que sur un signalement explicite, et pour le seul fichier signalé.