E2EE ou chiffrement de bout en bout… mais de quel « bout » parle-t-on ?
J’suis à bout
Proton affirmait récemment que « toutes les affirmations sur le chiffrement de bout en bout ne se valent pas ». C’est vrai, mais la problématique est plus large : qu’entend-t-on exactement par E2EE ou chiffrement de bout en bout ? Tout le monde n’est pas d’accord.
Coup sur coup, deux affaires sont apparues dans la presse sur la question du chiffrement de bout en bout, ou E2EE pour End-to-End Encryption.
X Chat et caméra pour WC : l'E2EE soulève des questions
Il y a la messagerie X Chat de X dont les clés sont fragmentées sur des serveurs HSM nécessitant un code PIN de l’utilisateur pour être reconstituées. Toute la sécurité du E2EE repose alors sur la confidentialité d’un code à quatre chiffres, ce qui fait dire à Proton que « toutes les affirmations sur le chiffrement de bout en bout ne se valent pas ». C’est vrai, ne serait-ce qu’à cause des implémentations qui en sont faites.
Dans un registre différent, il y a le cas de la société Kohler avec son Dekoda, une petite caméra à fixer sur votre cuvette des WC pour surveiller… l’intérieur de vos toilettes. Plus précisément, il s’agit de proposer un suivi de la santé de votre intestin, de votre hydratation et potentiellement de détecter la présence de sang, le tout évidemment avec de la détection d’image et de l’IA.
Le traitement ne se fait pas en local, mais sur des serveurs gérés par l’entreprise. Cela soulève bien sûr des questions sur le caractère privé des données de santé (on vous laisse imaginer le reste), qui nécessitent donc une grande confidentialité. L’entreprise annonce du « End-to-end Encryption » dans sa politique de confidentialité. Et c’est là que le bât blesse.
Comme le rapporte l’expert, chercheur et développeur Simon Fondrie-Teitler sur son blog (via TechCrunch), « Kohler peut accéder aux données et aux images de la caméra des toilettes qu'elle décrit comme "chiffrées de bout en bout" ». C’est en contradiction avec la promesse généralement admise de l'E2EE qui est que les données ne sont accessibles à aucun tiers.
Kholer a une définition bien particulière de son E2EE : « Nous chiffrons les données sensibles des utilisateurs au repos, lorsqu'elles sont stockées sur votre téléphone portable, votre caméra connectée des WC et sur nos systèmes. Nous chiffrons également les données de bout en bout lors de leur transmission, entre vos appareils et nos systèmes où elles sont déchiffrées et traitées afin de vous proposer nos services et les améliorer ».
Pour TechCrunch, « il est clair que l'entreprise fait référence au type de chiffrement qui sécurise les données lors de leur transmission sur Internet, connu sous le nom de TLS – qui est derrière les sites en HTTPS ». Kholer chiffre donc les données pendant leur transfert sur Internet (encore heureux), ainsi que sur ses serveurs (encore heureux, bis), mais il dispose de toutes les clés nécessaires pour accéder aux données en clair. Est-ce du chiffrement de bout en bout ? Non, en tout cas pas de la manière dont ce terme est généralement utilisé.
Il y a une différence fondamentale entre les deux affaires : XChat est une messagerie entre deux clients qui passent par des serveurs intermédiaires, Kohler est un fournisseur de service avec une relation entre un client et un serveur ; il n’y a pas de communication entre clients.
50 nuances de « chiffrement de bout en bout »
Commentaires (18)
Le 04/12/2025 à 15h23
Proton n'a pas les clefs pour les déchiffrer, seul l'utilisateur les a.
Le 04/12/2025 à 16h12
Le 04/12/2025 à 16h22
D'après la présentation initiale c'est « X Chat » : https://nitter.poast.org/chat/status/1989465741444485180#m
Non parce que non content de plagier le logo de X.org, ils volent ensuite le nom d'un client IRC, qui date d'au moins 2002 (https://sourceforge.net/p/xchat/svn/1/log/?path). Et c'était sa migration vers SVN. Ah, tiens, non, en fait, c'est juin 1999 (https://web.archive.org/web/19990921202352/http://xchat.org/)
Donc si vous pouviez éviter de participer au pillage, ça serait sympa. Bon, sinon, l'article est top, hein, merci !
Le 04/12/2025 à 16h44
Le 04/12/2025 à 16h24
De la même façon, si Bob envoie un message via Proton à Alice, Alice peut avoir besoin de sortir le fichier (pour l'imprimer, pour le passer dans un outil, etc.) et va éventuellement rompre le chiffrement à un moment.
Le 04/12/2025 à 17h14
Modifié le 04/12/2025 à 22h39
...
...
... Désolé, plus fort que moi...
Le 04/12/2025 à 17h01
Le chiffrement de bout-en-bout, c'est quand la clé des données partagées est détenue EXCLUSIVEMENT par l'utilisateur final. Donc la question cruciale est celle de la distribution des clés avec des mécanismes de pair-à-pair, c'est-à-dire en garantissant que les utilisateurs qui partagent se sont prélablement reconnus PHYSIQUEMENT comme étant les bons interlocuteurs. Pour cela, il faut : soit s'appuyer sur une fonction de PKI (Public Key Infrastructure) ; soit embarquer sa propre PKI (via protocole SAS code par exemple qui peut être synchrone ou asynchrone).
2) C'EST QUOI LE BOUT-EN-BOUT ?
Il faut distinguer :
— Chiffrement du transport, qui est un problème résolu depuis longtemps par TLS et HTTPS, en passant par des certificats acceptés par le navigateur.
— Chiffrement du partage, qui est un problème autrement complexe, surtout si on veut le rendre simple d'emploi pour l'utilisateur de base.
3) LES FONCTIONS DE SÉCURITÉ APPLICABLES AUX DONNÉES PARTAGÉES
Trop souvent, on se limite à la seule CONFIDENTIALITÉ. Mais ce n'est qu'une des fonctions de sécurité. Pour maîtriser les données sensibles, il faut :
- Souveraineté & Conformité : Étanchéité extraterritoriale • Contrôle d’exportation
- Robustesse opérationnelle : Résilience • Connexion dégradées • Immuabilité
- Droit-à-en-Connaître : Habilitation • Classification • Data Centric Security • Data Loss Prevention
- Garanties cryptographiques : Intégrité • Confidentialité • Traçabilité • Non-répudiation • Révocation • Fin de vie des données • Authenticité
Le 04/12/2025 à 19h40
Plus sérieusement, dans le cas de la caméra des WC, le serveur qui analyse est bien un des 2 bouts, c'est donc bien du E2EE.
Par contre, je pense qu'ils chiffrent bien au niveau applicatif (et pas TLS) les échanges avec leurs serveurs, ce qui me fait dire cela est la citation d'e-mail échangé avec eux par l'auteur du blog : J'en tire une conclusion différente de la sienne. C'est la partie que j'ai mise en gras qui me laisse penser que ce n'est pas juste du TLS, mais c'est plus du feeling qu’une certitude parce qu'ils ne sont pas assez précis dans cette réponse et encore moins sur leur site qui lui vise tout public. D'ailleurs, la conclusion de TechCrunch qui s'appuie sur juste une phrase de leur privacy policy pour dire que c'est uniquement du TLS me semble
ridiculeosée. Cette phrase ne donne pas assez d'informations pour conclure.Modifié le 04/12/2025 à 20h06
Le 04/12/2025 à 21h42
Le 05/12/2025 à 08h27
Le 05/12/2025 à 08h38
J'ai de plus en plus de mal avec ce concept de "non mais on vous jure !", quand elles viennent de la bouche des sociétés qui vivent de cette parole.
En extrapolant, même un produit open source, visible et accessible à toustes, ne garantit pas que la version qui tourne en production soit issue EXACTEMENT du même code.
Je vais trop loin dans la parano ?
Le 05/12/2025 à 09h47
ça me rappelle une histoire avec Snapchat (2014 ?) qui affirmait qu'ils ne gardaient rien sur leurs serveurs, vu que les messages et contenus échangés étaient "éphémères". Mais ça, c'était avant que moult stars et autres personnes ne se retrouvent à poil sur internet. Pourtant, les utilisateurs leurs faisaient confiance...
Le 05/12/2025 à 08h59
Il faut séparer le cas des messageries chiffrées User to user, ainsi que tout ce que st transfert de fichier User to User, et les échanges User to Server.
Ensuite, il faut distinguer où le chiffrement est appliqué, sur la donnée avant transport, sur la couche transport , sur les deux.
Si je reprends l'article, aucune transaction bancaire n'est sécurisée puisque ce n'est pas du User to User mais du User to Server. De même pour la logique de fonctionnement dans le domaine du paiement sur PCI-P2PE ou bien sur le "Sans Contact +"
L'article me semble approximatif dans son traitement de la notion de End-to-End-Encryption et ne répond finalement pas à la question posée dans le titre de l'article.
Le 05/12/2025 à 11h05
Le 05/12/2025 à 11h34
Est-ce que tu as compris de quoi je parle ? je ne crois pas non plus ...
Modifié le 05/12/2025 à 14h20
Il dit juste que du user-server c'est pas du E2EE (mais que ça peut être sécurisé quand même)…
Signaler un commentaire
Voulez-vous vraiment signaler ce commentaire ?