Comment les données sont chiffrées
Le chiffrement repose sur la paire de clés d'une identité : la clé publique verrouille, la clé privée déverrouille. Quand votre application chiffre quelque chose, votre clé est la paire de clés de l'identité au nom de laquelle agit le client — l'identité de l'utilisateur dans votre application, ou l'un de ses groupes. Le SDK reçoit ces clés à la connexion. Sur cette base, Secrecy chiffre les données en deux couches.
Deux couches : une clé de donnée, verrouillée par votre clé
- La donnée est chiffrée avec sa propre clé. Chaque donnée — un fichier, une version de fichier, le nom d'un nœud — reçoit une clé de donnée neuve et aléatoire. Le SDK chiffre le contenu avec elle, sur l'appareil.
- La clé de donnée est verrouillée avec votre clé publique. La clé de donnée est à son tour chiffrée, de sorte que seule votre clé privée puisse l'ouvrir.
Les serveurs stockent côte à côte la donnée chiffrée et la clé de donnée verrouillée. Détenir les deux ne suffit pas : sans votre clé privée, la clé de donnée reste verrouillée, et sans la clé de donnée, la donnée reste illisible.
Pour relire la donnée, le SDK fait l'inverse : il déverrouille la clé de donnée avec votre clé privée, puis déchiffre le contenu avec la clé de donnée.
Pourquoi deux couches
La séparation entre la donnée et sa clé est ce qui fait fonctionner le reste de Secrecy.
- Partager ne rechiffre pas la donnée. Pour donner accès à quelqu'un, le SDK verrouille à nouveau la même clé de donnée, cette fois avec la clé publique du destinataire — celle d'un utilisateur ou d'un groupe. Un gros fichier n'est jamais rechiffré ni renvoyé pour être partagé : seule sa petite clé l'est. Voir les modèles de partage.
- Chaque donnée est indépendante. Comme chaque fichier, version et nom a sa propre clé, donner accès à l'un ne révèle rien des autres.
- La clé peut voyager sans l'utilisateur. Une clé de donnée peut aussi être verrouillée par un mot de passe plutôt que par une clé publique. C'est ainsi qu'un lien s'ouvre pour quelqu'un qui n'a pas de compte Secrecy.
Fichiers, noms et mails
Le même modèle s'applique dans tout le SDK, avec quelques variantes :
- Les fichiers sont chiffrés en flux, par morceaux, pour que les gros fichiers puissent être envoyés et téléchargés avec un suivi de progression. Au téléchargement, chaque partie est vérifiée par une somme de contrôle avant d'être déchiffrée.
- Les noms des fichiers et des dossiers sont chiffrés eux aussi : les serveurs voient un libellé chiffré, pas
dossier-patient.pdf. - Les mails : sujets et corps sont chiffrés séparément pour chaque destinataire, avec sa clé publique dans votre application. Les pièces jointes suivent le modèle des fichiers : leur clé de donnée est verrouillée à nouveau pour chaque destinataire.
Ce que vous faites dans le code
Rien de particulier. Le client fait tout cela autour de chaque appel, et n'expose jamais les clés : votre application ne voit que des données en clair à l'entrée et à la sortie. Le seul chiffrement que vous appelez directement est la fonction de chiffrement anonyme, parce que son expéditeur n'a pas de client.