Oui, non, peut-être

Sur X, un échange entre un ingénieur et Proton a remis la sécurité des messages chiffrés du réseau social sur le devant de la scène. Même si la solution adoptée n’est pas aussi simple que l’ingénieur le pensait, elle reste très critiquée.

Au cours des derniers mois, X a diffusé auprès d’un nombre croissant d’utilisateurs sa fonction de messagerie sécurisée X chat, présentée comme ayant un chiffrement de bout en bout (E2EE).

• XChat : la nouvelle messagerie d’Elon Musk au système de chiffrement qui laisse dubitatif

« Toutes les affirmations sur le chiffrement de bout en bout ne se valent pas »

Ce 1ᵉʳ décembre, Ansgar, chercheur à la fondation Ethereum, a publié un message sur X pour s’en prendre à cette sécurité, qu’il a qualifiée de « ridicule ». Il pointait deux défauts majeurs dans l’implémentation faite par X : la clé privée de chiffrement est stockée sur les serveurs de l’entreprise et les conversations ne sont protégées que par un code PIN à quatre chiffres.

Cette communication a rapidement été reprise par le compte officiel de Proton, avec un message simple : « Malheureusement, toutes les affirmations sur le chiffrement de bout en bout ne se valent pas ». Il enchainait sur la propension des « géants de la tech » à « vendre du vent en matière de confidentialité en prétendant offrir chiffrement et protection de la vie privée, alors qu’en réalité, ils détiennent la clé principale et peuvent accéder à vos contenus ».

Rappelons que l’objectif du chiffrement de bout en bout est de transmettre une information que seul le destinataire pourra lire. Dans une solution E2EE solide, aucun des intermédiaires impliqués dans la transmission de ces données ne peut lire l’information, car seul le destinataire possède la clé privée pour déchiffrer le message. Quand l’un des acteurs dispose de la clé, il a la capacité d’accéder aux informations, brisant la promesse initiale.

Sécurité matérielle, mais code à quatre chiffres

En pratique, c’est un peu plus complexe. Au lancement, X reconnaissait déjà que son implémentation ne disposait pas d’une sécurité persistante, ce qui la rendait plus sensible aux attaques par l’homme du milieu (MITM). Cependant, en réponse à un tweet du chercheur en sécurité Matthew Green, un ingénieur de chez X avait confirmé l’utilisation de serveurs HSM (Hardware Security Modules) pour stocker les clés privées. X se sert de Juicebox (pdf) pour la sécurité des clés, un projet open source divisant les secrets en plusieurs morceaux, stockés par les HSM. Ils ne peuvent être reconstruits qu’avec le code PIN.

Si Ansgar a reconnu dans un premier temps que l’implémentation n’était pas aussi simple qu’il le pensait, elle augmentait la pression sur le code PIN, limité à quatre chiffres et donc sujet aux attaques par force brute. Quatre chiffres, cela ne laisse que 10 000 possibilités, ce qui se casse quasi instantanément s’il n’y a pas de protections supplémentaires.

Dans un autre message avertissant Proton de son changement d’avis, il signalait également que les HSM, qui permettent de faciliter l’utilisation, sont de moins bonnes protections que des clés privées stockées directement chez les utilisateurs. Proton a remercié le chercheur mais assume son message initial, puisque des géants « comme Google, Microsoft, etc » peuvent accéder aux e-mails, fichiers sur le cloud et autres.

Les éléments mis en avant ne sont cependant pas nouveaux. Matthew Garrett, un autre chercheur en sécurité, les avait déjà mentionnés dans un billet de blog daté du 5 juin. D’autres étaient revenus sur la question, par exemple le compte Mysk le 4 septembre pour affirmer que X n’implémentait pas correctement Juicebox.

L’équipe de FreeBSD vient d’annoncer la disponibilité de la version finale pour la quinzième édition majeure du système Unix.

La plupart des évolutions sont largement liées à la modernisation générale des paquets. On trouve cependant plusieurs améliorations notables, dont une génération des artefacts (images d’installations, de machines virtuelles et autres) sans requérir de droits administrateur. On peut également voir une implémentation native d’inotify, ou encore le passage à la version 2.4.0-rc4 de ZFS.

FreeBSD 15 introduit surtout deux changements majeurs. D’abord, l’introduction d’une nouvelle méthode pour l’installation et la gestion du système, basée sur le gestionnaire de paquets pkg. Lors de l’installation, les utilisateurs peuvent choisir entre la nouvelle méthode et l’ancienne (distribution sets). L’équipe précise cependant que cette dernière sera supprimée avec FreeBSD 16.

L’autre grande nouveauté est l’arrivée des builds reproductibles. Aussi appelée compilation déterministe, cette méthode permet de s’assurer que le code binaire pourra être reproduit par d’autres personnes. Il s’agit d’une étape importante pour la confiance, car la conséquence principale est que les utilisateurs peuvent s’assurer notamment que les images fournies par l’équipe sont bien ce qu’elles prétendent être et correspondent aux sources.

Signalons également une progression significative du support des ordinateurs portables par le système grâce à l’initiative FreeBSD-on-laptops, surtout pour le matériel Wi-Fi et graphique.

Le monde Linux finit l’année avec une nouvelle version majeure du noyau riche en nouveautés. Selon Phoronix, elle affiche de bonnes performances, ne semble pas contenir de régression par rapport au noyau 6.17 et semble avoir tout ce qu’il faut pour devenir la nouvelle mouture LTS (Long Term Support).

Comme toujours, les améliorations concernent pour beaucoup le support du matériel, mais pas seulement. Plusieurs améliorations de performances sont présentes, notamment pour le swap, lors de la réception des paquets UDP ou encore de l’allocation de la mémoire. On y trouve également le support du chiffrement PSP pour les connexions TCP, la prise en charge de la fonction Secure AVIC d’AMD ainsi que des améliorations dans celle d’Ext4. On note aussi l’apparition du pilote Rust Binder.

Le noyau 6.18 contient aussi plusieurs améliorations liées à la sécurité. Il supporte par exemple le sous-système d’audit pour gérer plusieurs modules de sécurité en même temps, ou encore la signature des programmes BPF.

La nouvelle version supprime également le support de Bcachefs. Ce système de fichiers était pris en charge par le noyau Linux depuis sa version 6.7. De type copy-on-write, il avait été pensé par son développeur principal, Kent Overstreet, comme une alternative à d’autres systèmes de fichiers modernes comme ZFS ou Btrfs. Mais en juin dernier, arguant de violations répétées d’Overstreet aux règles de maintenance du noyau, Linus Torvalds a fait passer le statut de Bcachefs de « Supporté » à « Maintenu extérieurement ».

• Systèmes de fichiers : ext4 et Btrfs, les « frères ennemis » du monde Linux

Comme toujours, la récupération du nouveau noyau dépend essentiellement de la distribution utilisée. Si vous utilisez un système « classique » comme Ubuntu, Fedora ou autre, vous resterez probablement sur la version déjà utilisée. Dans le cas d’une rolling release, les chances sont beaucoup plus élevées.