Le chiffrement de bout en bout, expliqué simplement

Une fiduciaire à Sion envoie chaque année le même formulaire : revenus, immeubles, enfants, déductions. Sur le site de l’outil de formulaires, il est écrit « chiffré ». C’est rassurant, et cela ne répond pas à la question qui compte : qui se retrouve, au bout du compte, avec les réponses en clair ?

Le mot figure aujourd’hui sur presque toutes les pages produit, et il signifie autre chose selon l’endroit où il s’applique. La différence n’est pas un détail d’ingénieur : elle décide qui peut lire le contenu. Et elle a un revers que les explications passent généralement sous silence : à quoi renonce-t-on lorsque personne, hormis le destinataire, ne peut rien lire ? Cette seconde partie est la plus intéressante.

Trois sens du mot « chiffré »

Terme	Ce qui est protégé	Qui peut déchiffrer
En transit	Le trajet entre l’appareil et le serveur	Les deux extrémités : le navigateur et le serveur
Au repos	Les supports sur lesquels les données sont stockées	Le service qui gère la clé
De bout en bout	Le contenu lui-même, de la saisie à la lecture	Uniquement qui détient la clé

En transit, c’est le cas normal aujourd’hui : le cadenas dans la barre d’adresse désigne TLS. La spécification de TLS 1.3 l’énonce sans ambiguïté — après l’établissement du canal, les données qui y circulent ne sont visibles que par les extrémités. C’est précisément le point : le serveur est l’une de ces extrémités. Là, le contenu se retrouve en clair, avant que quoi que ce soit d’autre lui arrive.

Au repos signifie que les données ne reposent pas sur les disques sous forme de texte lisible. La clé correspondante est gérée par le service qui livre ces données. Cela protège contre un support volé ou mis au rebut. Cela ne protège pas contre le logiciel qui utilise la clé de toute façon.

De bout en bout déplace une seule chose : l’endroit où le chiffrement a lieu. Pas sur le serveur, mais sur l’appareil de la personne qui saisit — et le déchiffrement n’intervient que sur l’appareil de la personne autorisée à lire. Entre les deux, le contenu n’est en clair nulle part.

Où le chiffrement a lieu — et qui détient la clé

Les navigateurs savent le faire nativement. La Web Cryptography API est une recommandation du W3C depuis le 26 janvier 2017 ; elle décrit une interface JavaScript pour les opérations cryptographiques de base — hachage, signatures, chiffrement et déchiffrement — ainsi que la gestion du matériel de clé nécessaire. Le chiffrement lui-même utilise le plus souvent AES, défini par la norme américaine FIPS 197 dans les variantes AES-128, AES-192 et AES-256, le nombre indiquant la longueur de la clé.

Dans une construction courante, il existe deux clés appariées. L’une est publique et se trouve dans le formulaire ; le navigateur de la personne qui répond s’en sert pour chiffrer ses saisies. L’autre est privée, reste chez le destinataire, et est la seule à rendre le résultat de nouveau lisible.

La question de la confiance se déplace alors. Qu’un fournisseur lise ou non cesse d’être une promesse pour devenir une question de construction : il n’a pas la clé privée, parce qu’il ne l’a jamais reçue. C’est une différence — mais pas une garantie. Qui détient la clé lit ; qui la perd ne lit plus ; et le logiciel qui chiffre dans le navigateur vient toujours du fournisseur. C’est pourquoi ceux qui construisent ainsi documentent en général la manière dont ils le font.

Une chose que le chiffrement de bout en bout ne fait expressément pas : il protège le contenu, pas les circonstances. Qu’un formulaire ait été envoyé, quand, à quelle fréquence et quelle était la taille d’une pièce jointe — tout cela continue de s’accumuler. Qui juge ces indications négligeables gagnerait à les noter une fois : sur un formulaire d’annonce interne, l’heure à elle seule dit quelque chose.

Un formulaire d’inscription, étape par étape

Une école de musique à Vevey reçoit des inscriptions : nom de l’enfant, adresse, instrument, indications pour un éventuel tarif réduit. Voici le parcours lorsque le chiffrement est de bout en bout.

1. L’école crée le formulaire. Une paire de clés est générée. La partie publique appartient au formulaire, la partie privée appartient à l’école.
2. Un père ouvre le lien. Son navigateur charge le formulaire avec la clé publique.
3. Il remplit et envoie. Avant l’envoi, son navigateur chiffre les réponses. Ce qui quitte la ligne n’est plus du texte lisible.
4. Le serveur reçoit le résultat et l’enregistre. Il peut le classer, le compter, l’horodater — il ne voit pas le contenu.
5. La secrétaire de l’école ouvre la vue d’ensemble. Son navigateur récupère les entrées enregistrées et les déchiffre localement avec la clé privée.
6. L’inscription s’affiche sur son écran. Depuis l’étape 3, elle n’était lisible nulle part ailleurs.

Pour le père, l’usage ne change en rien. Pour la secrétaire, il change beaucoup — et c’est là le véritable sujet.

Ce à quoi vous renoncez

Une clé perdue reste perdue. Dans un tel système, le mot de passe n’est pas la clé, et réinitialiser le mot de passe ne rétablit pas l’accès aux données. Proton le décrit ouvertement pour ses propres comptes : après une réinitialisation, il faut une option de récupération configurée au préalable — une phrase de récupération, un fichier de récupération, une sauvegarde d’appareil ou l’ancien mot de passe — faute de quoi l’on risque de perdre définitivement l’accès au compte et aux données. Le fournisseur ne peut pas s’en charger ; c’est exactement en cela que consiste la construction.

Le serveur ne peut ni chercher, ni trier, ni prévisualiser. Tout ce qui, autrement, s’exécute côté serveur sur le contenu disparaît ou migre dans le navigateur. Google le décrit explicitement pour son propre chiffrement côté client dans Workspace : le contenu de ces fichiers ne peut pas être recherché, ni filtré par type de fichier, ni affiché en aperçu ; les analyses de prévention des pertes de données n’ont pas accès au contenu ; et les fichiers et courriels chiffrés côté client ne sont pas analysés à la recherche d’hameçonnage ou de logiciels malveillants, parce que les serveurs ne voient pas le contenu. Ce n’est pas une particularité d’un fournisseur, mais la conséquence logique de la construction.

Le courriel de notification ne contient pas le contenu. « Nouvelle inscription reçue » — il ne peut guère en dire plus, puisqu’il part d’un serveur incapable de lire la réponse. Qui a l’habitude de survoler le contenu directement dans sa boîte de réception travaille autrement.

Les analyses se font dans le navigateur. Une statistique sur 4000 réponses n’est pas calculée sur le serveur, mais sur l’appareil, après déchiffrement. Avec une poignée d’inscriptions, cela ne se remarque pas. Avec un très grand nombre d’entrées, si.

L’accès à plusieurs est une tâche en soi. Si trois personnes du secrétariat doivent lire les réponses, toutes trois doivent accéder à la clé. C’est faisable, mais c’est une étape de plus que la création d’un compte — et au départ d’une collaboratrice, c’est de nouveau une étape de plus.

Quand l’effort n’en vaut pas la peine

Tous les formulaires n’y gagnent pas. Un sondage public sur le menu de midi d’une cantine, anonyme et sans données personnelles, en paie le prix sans rien recevoir en retour. Un bon de commande dont les indications doivent alimenter automatiquement la comptabilité ou un service d’expédition suppose, quelque part, un logiciel capable de lire le contenu — la chaîne est alors de toute façon interrompue. Et partout où les réponses doivent rester accessibles en cas d’urgence même lorsque la seule personne détenant la clé est absente, c’est la gestion des clés qui constitue le vrai travail, pas le chiffrement.

Le calcul s’inverse dès que les réponses contiennent des choses qui ne regardent personne à l’extérieur : anamnèses, candidatures, annonces internes, documents fiscaux.

Ce que dit le droit suisse

La loi sur la protection des données ne prescrit aucune technique. Elle exige que le responsable du traitement et le sous-traitant assurent, par des mesures techniques et organisationnelles appropriées, une sécurité adéquate des données par rapport au risque, et laisse les exigences minimales au Conseil fédéral (art. 8 LPD). L’ordonnance sur la protection des données nomme ensuite des objectifs plutôt que des outils : selon leur besoin de protection, les données traitées doivent être accessibles aux seules personnes autorisées (confidentialité), disponibles lorsqu’elles sont nécessaires (disponibilité), non modifiées sans autorisation (intégrité) et traitées de manière traçable (traçabilité) (art. 2 OPDo). Dans le choix des mesures, l’état de la technique et les coûts de mise en œuvre comptent parmi les éléments à prendre en compte (art. 1 al. 4 OPDo).

Le mot « chiffrement » ne figure pas dans ces dispositions. Ce qui est révélateur, c’est que confidentialité et disponibilité y figurent côte à côte — et que l’ordonnance exige également que l’accès aux données puisse être rétabli rapidement après un incident (art. 3 al. 2 let. d OPDo). La décision dont traite cet article se situe exactement entre ces deux objectifs.

Ce que cela donne

« Chiffré » n’est pas une propriété, mais une question portant sur deux choses : à quel endroit le chiffrement a-t-il lieu, et qui détient la clé ? Les deux figurent dans la documentation d’un fournisseur, ou nulle part. Le bout en bout est la réponse au lectorat le plus restreint — et aux contraintes quotidiennes les plus nombreuses. Les deux vont ensemble ; ne raconter que la première moitié, c’est raconter la moitié.

Nous développons Formulaires, une application dans laquelle les réponses sont chiffrées dans le navigateur de la personne qui répond et où la clé privée reste du côté qui reçoit. L’application est prévue et n’est pas encore disponible ; la manière dont le chiffrement est construit en détail, et ce qu’il implique à l’usage, nous l’exposerons avant le lancement.