Proton Mail, le service de messagerie chiffré qui vend de la confidentialité à tout prix, a transmis des données de paiement aux autorités suisses. Ces données ont ensuite atterri entre les mains du FBI, qui a pu identifier la personne derrière un compte mail anonyme lié au mouvement Stop Cop City à Atlanta.

Une carte bancaire et c'est plié

Le FBI enquêtait sur Defend the Atlanta Forest, un groupe affilié au mouvement Stop Cop City qui s'opposait à la construction d'un centre d'entraînement de police dans un parc d'Atlanta. Pour identifier qui se cachait derrière une adresse Proton Mail utilisée par le groupe, les Américains sont passés par un traité d'entraide judiciaire avec la Suisse (le MLAT).

Le 25 janvier 2024, les autorités suisses ont donc renvoyé au FBI le nom complet de la personne qui avait payé l'abonnement Proton avec sa carte bancaire. Les mails restent chiffrés, personne n'a lu quoi que ce soit, mais le simple fait d'avoir utilisé une carte de crédit a suffi à lever l'anonymat.

Déjà vu en 2021

Proton avait déjà fait parler en 2021, quand l'entreprise avait fourni l'adresse IP d'un militant écologiste français du collectif Youth for Climate, sur ordre d'un tribunal suisse. L'information avait transité par Europol et avait conduit à des arrestations en France.

Proton avait ensuite discrètement retiré de son site la mention "nous n'enregistrons pas votre adresse IP". Côté communication, le discours est rodé : Edward Shone, responsable de la comm chez Proton, assure que l'entreprise n'a rien transmis directement au FBI et ne fournit que "les informations limitées dont elle dispose" quand la justice suisse l'exige.

Ce que Proton sait de vous

Le chiffrement de bout en bout, ça fonctionne. Proton ne peut pas lire vos mails, et personne ne remet ça en question. Mais l'entreprise conserve les données de facturation, et si vous avez payé par carte bancaire, votre nom et vos coordonnées sont dans leurs fichiers.

Proton propose des moyens de paiement anonymes (cryptomonnaies, espèces par courrier), mais dans les faits, peu d'utilisateurs y pensent. La personne identifiée dans cette affaire n'a d'ailleurs jamais été inculpée, mais son identité est entre les mains du FBI.

Il faut vraiment garder en tête que le chiffrement protège le contenu de vos messages, pas votre identité. Proton a beau vendre de la confidentialité, l'entreprise reste soumise au droit suisse comme toutes les autres. Payer un service "confidentiel" avec sa carte Visa et espérer rester anonyme, autant mettre un cadenas sur une porte vitrée...

Sources : 404Media , YCombinator

Le chiffrement complet du disque, tout le monde vous dit que c'est la base. LUKS sous Linux, BitLocker sous Windows, FileVault sous macOS... sauf que personne vous dit quoi faire quand votre serveur reboot à 3h du mat et qu'il attend sagement sa passphrase.

Là, vous êtes coincé !!!!

Parce que oui, le truc vicieux avec le chiffrement intégral, c'est qu'au démarrage, le système ne peut pas lire le disque tant que vous n'avez pas tapé le mot de passe. Du coup, si votre machine est dans un datacenter ou chez un hébergeur, ben... faut se déplacer physiquement. Et ça c'est bien relou !!!

La solution, c'est d'embarquer un serveur SSH directement dans l' initramfs (oui, le mini OS qui tourne AVANT votre vrai système, sur le port 22). En gros, votre machine boot, charge l'initramfs, lance un serveur SSH... et vous n'avez plus qu'à vous connecter à distance pour taper la passphrase. Comme ça le disque se déverrouille et le boot continue. Voilà quoi, c'est simple la vie quand on lit Korben.info !! loool

L'initramfs, c'est quoi exactement ?

Alors pour ceux qui débarquent, l'initramfs c'est une archive compressée dans /boot/initramfs-linux.img qui contient un système Linux minimal. Son boulot, c'est de préparer le terrain avant de passer la main au vrai OS, genre charger les modules noyau, détecter le matériel, monter les systèmes de fichiers... et dans notre cas, demander la passphrase LUKS. Genre un second OS, mais en version bonsaï !

Installer Dropbear dans l'initramfs

Dropbear , c'est un serveur SSH ultra-léger (environ 110 Ko) parfait pour l'initramfs. L'article de jyn qui m'a inspiré pour cet article , recommande Arch Linux avec mkinitcpio, mais sachez que sous Debian/Ubuntu le paquet dropbear-initramfs fait le même boulot avec update-initramfs.

Sur Arch, vous installez mkinitcpio-systemd-extras puis vous modifiez /etc/mkinitcpio.conf pour ajouter les hooks réseau et Dropbear :

HOOKS=(base systemd autodetect microcode modconf kms keyboard sd-vconsole block sd-encrypt filesystems fsck systemd-network dropbear)

Attention, l'ordre des hooks compte. Le réseau doit être configuré AVANT Dropbear, sinon votre serveur SSH démarre sans interface réseau. Pas super utile donc !

Configurer le réseau dans l'initramfs

Ensuite faut créer un fichier de config réseau dans /etc/systemd/network-initramfs/. En fait, c'est du systemd-networkd classique, donc si vous avez déjà configuré ça, c'est pareil. Un simple fichier .network avec DHCP fait le job en Ethernet (et pour un serveur, c'est clairement recommandé). Pour les plus paranos, une IP statique marche aussi, sauf que faudra pas oublier de la mettre à jour si vous changez de réseau.

La touche Tailscale

Après si votre serveur est derrière un NAT ou un firewall, bah... le SSH classique ne passe pas. Du coup, jyn a eu la bonne l'idée d'embarquer Tailscale dans l'initramfs aussi. Comme ça, la machine rejoint votre réseau privé Tailscale dès le boot, même avant le déchiffrement du disque.

Vous lancez setup-initcpio-tailscale, ça vous donne un lien d'authentification sur login.tailscale.com et c'est réglé. Après faut penser à configurer les ACL Tailscale pour que SEULE votre machine d'admin puisse se connecter à l'initramfs car OUI ON NE LAISSE PAS UN PUTAIN DE SSH ouvert sur un système pré-boot sans protection, HEIN ?? HEIN ?? Donc faites ça !!

Les précautions de sécurité

Vous vous en doutez, y'a quand même quelques pièges à éviter. D'abord, les clés SSH de Dropbear dans l'initramfs (stockées dans /etc/dropbear/) doivent être DIFFÉRENTES de celles d'OpenSSH dans /etc/ssh/. Parce que l'initramfs n'est pas chiffré (bah oui, il doit tourner avant le déchiffrement), donc ces clés sont techniquement accessibles à quelqu'un qui a un accès physique au disque.

Ensuite, attention, limitez ce que Dropbear peut faire. Pas de shell complet, juste la commande systemd-tty-ask-password-agent qui sert uniquement à taper la passphrase. Comme ça, même si quelqu'un arrive à se connecter, il ne peut rien faire d'autre.

Et désactivez aussi l'expiration des clés Tailscale pour la machine initramfs via --auth-key avec un token non-éphémère, sinon votre serveur va se retrouver éjecté du réseau au pire moment.

Reconstruire et tester

Une fois tout configuré, un petit mkinitcpio -P pour reconstruire l'initramfs et c'est bon. Si ça ne marche pas du premier coup, vérifiez les logs avec journalctl -b. Mais attention, testez ça sur une VM ou une machine avec accès console (IPMI, iDRAC, KVM-over-IP) d'abord, parce que si le réseau de l'initramfs ne monte pas, votre serveur devient une brique inaccessible... et là, c'est le vrai drame de votre vie qui commence (et la découverte de France Travail) !

Au prochain reboot, votre serveur va donc démarrer, charger l'initramfs, se connecter à Tailscale, lancer Dropbear... et attendre patiemment que vous tapiez la passphrase depuis votre canapé.

Si vous gérez des serveurs chiffrés à distance, c'est le genre de setup un peu touchy à la base mais qui change la vie. Comme ça, plus besoin de supplier / soudoyer / menacer (chacun sa technique) le technicien du datacenter d'astreinte de brancher un clavier ^^.

Découvrir le tuto complet de Jyn ici !

Envoyer un mot de passe par email en clair, on l'a tous fait au moins une fois dans notre vie (oui, oui vous aussi !!). C'est pourquoi ITYLOS propose une alternative radicale où vos messages s'autodétruisent après lecture afin que personne, pas même le serveur, ne puisse les lire.

Vous écrivez votre message sur itylos.com, vous choisissez une durée de vie (1h, 24h ou 7 jours), et youpla, vous récupérez un lien unique à envoyer. Et ensuite, une fois lu, le message est détruit ! Tout ça, sans compte à créer, sans app à installer... Vous ouvrez juste le site, vous collez votre texte et c'est parti.

Côté technique, c'est du lourd puisque le chiffrement se fait ENTIÈREMENT dans votre navigateur avec de l'AES-256-GCM, et la dérivation de clé passe par Argon2ID. Du coup, le serveur ne voit jamais votre message en clair... il ne fait que stocker un blob chiffré qu'il est incapable de déchiffrer. C'est du vrai zero-knowledge, mais ça reste bien sûr une webapp, donc si votre navigateur ne supporte pas la Web Crypto API (genre un vieux Firefox ESR), ça ne marchera pas.

Et le truc qui va plaire aux plus paranos d'entre vous, c'est le traffic padding où chaque requête est gonflée à 15 Ko de bruit aléatoire pour rendre l'analyse de taille de vos messages bien plus compliquée côté réseau. Oui, c'est un vrai vecteur d'attaque et oui, ils y ont pensé. D'ailleurs, les données ne touchent pas le disque selon eux puisque tout transite en RAM, ne laissant ainsi aucune trace. Bon, sauf si vous faites un copier-coller du message dans un fichier texte, là c'est de votre faute.

Le service tourne sur une infrastructure souveraine à Genève, en Suisse. Pas sur un VPS chez AWS ou Google Cloud, hein... et y'a aussi un warrant canary PGP, signé et mis à jour chaque mois. Comme ça, si le canari disparaît, vous saurez que quelqu'un est venu taper à la porte.

Et côté conformité, ITYLOS délivre même des certificats de destruction au format JSON (oui oui, un vrai fichier .json), dans l'esprit de l'article 17 du RGPD . Perso, c'est la première fois que je vois une messagerie éphémère aller aussi loin dans la traçabilité de l'effacement, donc chapeau !

L'histoire derrière Itylos est cool aussi d'ailleurs. Tout est parti quand le créateur a récupéré un disque dur d'occasion et s'est retrouvé avec la vie entière de l'ancien proprio dessus... photos, documents, tout le bazar. Ça l'a décidé à créer un outil où les données n'existent tout simplement pas assez longtemps pour fuiter.

Et en plus c'est gratuit, open source (le code est sur GitHub sous licence MIT), et si vous êtes du genre à chiffrer vos échanges (un peu comme les utilisateurs de Kloak ), ça vaut le coup d’œil !

Merci à Mehdi pour la découverte !

Si vous avez lu mon article sur Meshtastic , vous savez déjà que les réseaux mesh LoRa, c'est le genre de truc qui fait rêver tous les geeks en manque de hors-piste numérique. Mais y'a un cran au-dessus, et ça s'appelle Reticulum .

En gros, c'est une stack réseau chiffré de bout en bout qui fonctionne sur n'importe quel support physique : LoRa, WiFi, Ethernet, liaison série, radio amateur en packet... TOUT y passe. Du coup, là où Meshtastic reste avant tout taillé pour les messages texte sur LoRa, ici vous pouvez faire transiter des fichiers, des appels vocaux, des pages web et même un shell distant à travers votre mesh. En fait au début je pensais que c'était juste un Meshtastic sous stéroïdes, mais non... c'est carrément une couche réseau complète.

Sideband, l'app de messagerie mesh pour Reticulum

L'avantage c'est surtout la flexibilité car plutôt que d'être coincé sur un seul médium, vous pouvez mixer LoRa longue portée et WiFi courte portée dans le même réseau via un simple fichier ~/.reticulum/config, et les paquets se débrouillent tout seuls comme des grands pour trouver le chemin le plus efficace.

Côté chiffrement, c'est du lourd : X25519 pour l'échange de clés, Ed25519 pour les signatures, AES-256-CBC pour le chiffrement symétrique, et du forward secrecy par-dessus. Le truc malin, c'est que les paquets ne contiennent aucune adresse source. Votre identité sur le réseau, c'est juste une paire de clés au niveau du protocole, donc personne ne peut remonter à l'expéditeur.

L'écosystème d'apps est même plutôt costaud. Y'a Sideband, une app dispo sur Android via F-Droid, Linux et macOS, qui gère les messages, les appels vocaux, le transfert de fichiers et même les cartes, le tout à travers le mesh. Y'a aussi NomadNet pour héberger des pages sur un réseau totalement hors-ligne, et rnsh qui permet de lancer un shell distant (oui, du SSH sans Internet, sur le port que vous voulez... ça fait rêver ^^).

D'ailleurs pour les radioamateurs, tout ça tourne nickel sur des bonnes vieilles liaisons packet radio en AX.25. Modems KISS, TNCs classiques... tout est supporté, j'vous dit !

Et pour l'installer, c'est d'une simplicité presque suspecte : un pip install rns et hop, vous avez votre noeud Reticulum dans /home/user/.reticulum/. Ça tourne sur un Raspberry Pi 3 ou 4, un vieux laptop sous Debian, votre téléphone via Sideband... et si vous voulez du LoRa, vous branchez un RNode sur l'USB et c'est parti.

Attention quand même, sous Windows c'est un poil plus compliqué (Faut passer par WSL2, sauf si vous avez déjà un Python 3.x bien configuré dans le PATH), et la doc est intégralement en anglais.

Notez que la bande passante s'adapte sans problème au support, de 150 bps en LoRa longue portée sur 868 MHz (faut pas s'attendre à du Netflix non plus) jusqu'à 500 Mbps en Ethernet local. Et un lien chiffré s'établit en seulement 3 paquets pour 297 octets. C'est pas gourmand.