Chiffrement de bout en bout

La plupart du web chiffre déjà de deux autres façons. Le chiffrement en transit (TLS, le cadenas) protège les données entre ton appareil et un serveur, mais le serveur les lit ensuite. Le chiffrement au repos protège un disque, pourtant l’entreprise qui détient le disque détient en général aussi la clé. Le chiffrement de bout en bout sort la clé des mains de l’entreprise : même une intrusion dans le serveur, une réquisition adressée à l’exploitant ou un employé trop curieux n’obtient que des octets brouillés. Les messageries ont rendu l’idée familière : un message est scellé sur un téléphone et ouvert sur un autre, si bien que même l’entreprise qui le transporte ne sait pas ce qu’il dit, seulement qu’un message a circulé.

En pratique, un appareil fabrique une clé, s’en sert pour chiffrer chaque élément avant l’envoi, et ne la confie qu’aux appareils que tu approuves. Le plus dur n’est pas le chiffre, qui est standard (AES-256-GCM est très répandu), mais les clés : comment un nouvel appareil en reçoit une, et que se passe-t-il quand tu les perds toutes. Les vrais systèmes de bout en bout répondent par une clé d’accès, une clé de secours ou un appareil déjà de confiance, et assument un compromis. Comme personne d’autre ne peut ouvrir tes données, personne d’autre ne peut non plus les sauver. Pense à une lettre dans une boîte verrouillée : le coursier manipule la boîte tout au long du trajet, mais seule la personne qui détient la clé correspondante peut lire le contenu.

Il faut connaître les limites. Le chiffrement protège les données du serveur, pas d’un appareil compromis, d’un téléphone volé et déverrouillé ou d’un logiciel malveillant. Et un chat IA ne peut pas être de bout en bout jusqu’au modèle : le modèle doit lire ton texte pour y répondre. Le terme convient donc au stockage, à la synchronisation, aux sauvegardes et au partage, pas à l’échange en direct avec le modèle. Un bon test consiste à demander qui détient la clé. Si c’est l’exploitant, le service peut être chiffré, mais pas de bout en bout, et l’exploitant peut être contraint ou piraté.

À la première utilisation, ton navigateur crée une clé AES-256-GCM non exportable : la page peut s’en servir pour chiffrer et déchiffrer, mais aucun script ne peut la lire en octets, pas même le nôtre. Tes conversations, images, personnages et ta mémoire sont chiffrés avec elle avant d’être écrits dans la base de ton navigateur. Si tu actives la synchronisation dans les Réglages, chaque élément est chiffré dans ton navigateur sous une clé de données que nos serveurs n’ont jamais, et son identifiant est rendu opaque. Cette clé est enveloppée par ta clé d’accès et ta clé de secours, et scellée pour chaque appareil approuvé ; chaque requête de synchronisation doit être signée par un appareil approuvé. Sans clé d’accès, sans clé de secours ni autre appareil approuvé, notre copie ne peut plus être ouverte.

Les liens de partage et ta sauvegarde sont chiffrés aussi, la sauvegarde avec ta phrase secrète. Cela explique aussi pourquoi nous ne stockons que des éléments scellés : une fuite de base ne montrerait que des octets brouillés, des tailles arrondies et des horodatages, aucun des mots que tu as écrits.