Je suis agriculteur en Creuse et je code sur mon temps libre. J'ai commencé à m'intéresser à la question de la récupération de compte en développant ARC PVE Hub, un site destiné à fédérer une communauté de joueurs. Je n'ai jamais compris pourquoi il fallait transmettre son email pour régénérer un mot de passe — ça déplace la sécurité du compte vers un fournisseur SMTP tiers, qui n'est pas contrôlé par l'utilisateur.

J'ai donc imaginé un protocole de récupération sans email, sans SMS et sans tiers. Le travail s'est étoffé en partenariat avec un assistant IA (Claude), comme outil de réflexion et de mise en forme — j'y reviens en fin de dépêche dans une note de transparence.

L'incident de sécurité ANTS du 15 avril 2026 a publiquement illustré le problème. J'en ai eu connaissance après avoir développé SelfRecover, ce qui m'a confirmé la pertinence d'un protocole sans dépendance à l'email. SelfRecover est publié sous AGPL-3.0-or-later sur GitHub.

Cette dépêche présente le protocole, ses choix de conception, ses limites assumées, et la comparaison avec les approches existantes (Keycloak Recovery Codes en particulier, qui m'a été suggéré en relecture). Audit communautaire bienvenu.

Sommaire

• • Le contexte
  • Le protocole en deux phrases
  • Deux modes d'adoption
    • Mode Full — Sans email
    • Mode Lite — Avec email + mot mémorisé
    • Synthèse
  • SelfRecover vs Keycloak Recovery Codes
  • Que se passe-t-il si l'utilisateur perd son secret ?
    • Niveau 1 — Passphrase oubliée
    • Niveau 2 — Passphrase perdue, mais identifiant + mot de récupération retenus
    • Niveau 3 — Accès complètement perdu
    • Chat administrateur humain en mode restreint — état actuel
    • Évolution prévue (en réflexion) : pré-traitement optionnel par chatbot LLM local
    • Démo standalone vs implémentation de référence
    • Pourquoi assumer cette friction
    • Pour quel public
  • Modèle de menace assumé
  • Démos en ligne
  • Code et image Docker
  • Licence et philosophie
  • Note de transparence
    • Conception en partenariat avec un assistant IA
    • Plan d'audit
    • Statut du projet
    • Engagement communauté LinuxFr et culture du libre
  • Pour aller plus loin

Le contexte

Depuis l'essor du web, la réponse standard à « l'utilisateur a oublié son mot de passe » est « on lui envoie un lien de réinitialisation par email ». C'est devenu si universel qu'on oublie ce que ça implique :

• La sécurité du compte est déléguée au fournisseur de la boîte mail (Gmail, Outlook, ProtonMail). Si la boîte mail tombe, le compte aussi.
• Le canal email est régulièrement exploité par phishing : campagnes imitant des mails de réinitialisation légitimes pour capturer les mots de passe.
• Les bases de données qui stockent les emails des utilisateurs deviennent une cible massive : leur fuite expose à la fois l'identité et les vecteurs de récupération.

L'incident de sécurité ANTS illustre une autre facette du problème de gestion des données d'authentification dans les services en ligne. Détecté le 15 avril 2026 et rendu public le 20 avril, il a touché 11,7 millions de comptes selon les communiqués officiels. La cause technique identifiée est une faille d'énumération de type IDOR (Insecure Direct Object Reference) : il était possible d'accéder aux données d'un autre compte en modifiant un identifiant dans une URL. La fuite ne concerne ni les mots de passe, ni les pièces justificatives, mais les données personnelles associées aux demandes de titres.

Devant ces limites structurelles autour de l'authentification web, SelfRecover propose une inversion : conserver le secret de récupération chez l'utilisateur, et utiliser le navigateur pour faire les calculs cryptographiques nécessaires à la vérification. Le serveur ne détient plus que des dérivés, jamais les secrets bruts.

Le protocole en deux phrases

Côté navigateur, on calcule HMAC-SHA256(secret, domaine) : une fonction cryptographique standard qui combine le secret de l'utilisateur avec le nom de domaine du site, et produit une empreinte impossible à inverser. Côté serveur, on ne stocke que cette empreinte, en plus protégée par un hash adaptatif et memory-hard : Argon2id, qui est le standard moderne recommandé contre les attaques par brute force.

Deux propriétés découlent de cette construction :

• Le secret brut ne quitte jamais le poste de l'utilisateur.
• Un secret capturé sur un site A (par exemple via phishing) est mathématiquement inutilisable sur un site B : la dérivation HMAC produit des empreintes différentes pour des domaines différents. C'est de l'anti-phishing par construction, pas par convention.

Note conceptuelle : l'inspiration vient des machines à rotors historiques type Enigma. Le principe partagé est qu'une même configuration secrète, présente des deux côtés (émetteur et récepteur), permet de produire et vérifier un message dérivé. La cryptographie moderne (HMAC-SHA256 ici) repose sur des fondations mathématiques différentes, mais ce principe de dérivation contrôlée par un secret commun est resté.

Deux modes d'adoption

SelfRecover propose deux modes selon le contexte de déploiement.

Mode Full — Sans email

L'application abandonne entièrement le flow de réinitialisation par email. L'utilisateur génère une passphrase diceware à l'inscription (liste EFF de 7 776 mots, 4 à 7 mots par défaut), qu'il mémorise ou stocke dans son gestionnaire de mots de passe. Cette passphrase, combinée au nom de domaine du site via HMAC-SHA256, permet de réinitialiser le mot de passe sans aucune dépendance externe.

Pour qui : nouveaux projets qui veulent s'affranchir de SMTP dès la conception, ou services qui adoptent un modèle de menace post-fuite (l'email n'est plus considéré comme un canal de confiance).

Mode Lite — Avec email + mot mémorisé

L'application conserve le flow de réinitialisation par email habituel, mais y ajoute une étape supplémentaire : l'utilisateur saisit un mot mémorisé (choisi à l'inscription) qui est dérivé HMAC-SHA256 côté navigateur. Le mot brut n'est jamais transmis au serveur. La validation combine donc deux facteurs :

1. La possession de la boîte mail (lien reset reçu)
2. La connaissance du mot mémorisé (dérivé HMAC côté client)

Pour qui : applications existantes qui ne peuvent abandonner SMTP du jour au lendemain, mais veulent durcir progressivement leur flow de récupération. Conséquence : un email intercepté seul ne suffit plus à compromettre un compte — il faut aussi connaître le mot mémorisé.

Synthèse

SelfRecover vs Keycloak Recovery Codes

Lors de la relecture de cette dépêche, devnewton a soulevé une question importante : quelle est la différence avec les Recovery Codes de Keycloak ?

Keycloak est l'IAM (Identity and Access Management) open-source de référence, maintenu par Red Hat sous licence Apache 2.0, déployé dans de nombreuses organisations depuis plus d'une décennie. Son mécanisme de Recovery Codes est un fallback d'authentification à deux facteurs : si l'utilisateur perd son téléphone TOTP, il peut saisir un code de secours préalablement généré côté serveur.

Note importante de positionnement : les Recovery Codes Keycloak adressent le cas « j'ai perdu mon 2FA mais je connais toujours mon mot de passe principal ». Le password reset principal de Keycloak utilise, lui, le canal email standard (configuration SMTP dans l'onglet Email de l'admin console).

SelfRecover s'attaque à un cas différent : « j'ai oublié mon mot de passe principal et je ne veux pas dépendre de l'email pour le récupérer ». Concrètement :

Pour la majorité des projets qui acceptent l'email comme canal de récupération, Keycloak (et son écosystème) reste le bon choix. SelfRecover s'adresse aux applications qui veulent réduire ou supprimer leur dépendance à SMTP, et qui n'ont pas besoin de la richesse d'un IAM complet (multi-realm, OIDC/SAML, fédération d'identité, etc.).

Que se passe-t-il si l'utilisateur perd son secret ?

C'est la question critique d'un protocole de récupération. SelfRecover y répond par escalade progressive sur trois niveaux, complétée par un système de litiges et un chat administrateur pour les cas extrêmes.

Niveau 1 — Passphrase oubliée

L'utilisateur saisit son username + sa passphrase diceware (match exact). Sur succès, un nouveau mot de passe est généré et affiché une seule fois. Anti-brute force : 3 tentatives par 15 minutes, 3 blocages successifs → éjection vers L2.

Niveau 2 — Passphrase perdue, mais identifiant + mot de récupération retenus

L'utilisateur saisit son identifiant public (numéro client, identifiant métier — fourni par le site) et son mot de récupération dérivé HMAC-SHA256 côté navigateur. 3 tentatives maximum avec compteur visible. Sur 3 échecs → redirection vers L3. Un litige est automatiquement créé (LIT-XXXX), tracé en base, admin notifié. Les litiges auto-résolus sont purgés après 24 heures.

Niveau 3 — Accès complètement perdu

Entrée par un lien discret « accès perdu » sur la page de connexion. L'utilisateur saisit son identifiant public en premier (anti-timing : délai forcé de 2 à 3 secondes), puis remplit un formulaire de scoring multi-facteur :

Bonus passifs : IP connue (+5), fingerprint connu (+5).

• Score ≥ 60/100 → compte récupéré, nouveau mot de passe généré
• Score < 60/100 après 3 tentatives → le compte passe en mode restreint : l'utilisateur n'a plus accès qu'au chat administrateur, le compte n'est ni utilisable ni écrasable tant que l'admin n'a pas validé
• Cooldown : 1 heure entre tentatives

Chat administrateur humain en mode restreint — état actuel

Dans l'implémentation actuelle (déployée en production sur ARC PVE Hub), le chat L3 est un canal direct entre l'utilisateur en mode restreint et un administrateur humain du site. Pas d'intermédiaire automatisé, pas de bot.

Le canal de chat est bidirectionnel et fonctionne en polling (pas WebSocket temps réel, pour rester simple). L'admin vérifie l'identité par l'échange et décide manuellement :

Accorder la récupération : mot de passe régénéré, compteurs réinitialisés, litige clôturé, mode restreint levé.

Refuser la récupération : ban temporaire de 24 heures, pas de nouveau litige possible pendant cette fenêtre, compteur de refus incrémenté (1/3, 2/3, 3/3). À chaque clic, l'interface admin rappelle explicitement les conséquences via une modale de confirmation (ban 24h aux refus 1 et 2, suppression définitive au 3e refus).

Au 3e refus, le compte est définitivement supprimé : décision exclusivement humaine, prise en pleine connaissance de cause par l'admin via la modale d'avertissement explicite. La suppression libère l'identifiant public pour une nouvelle inscription.

Principe de design MySelf : aucune destruction de données utilisateur n'est déclenchée sans validation humaine consciente. L'interface admin explicite systématiquement les conséquences avant chaque action irréversible. Une IA peut se tromper ou être manipulée ; lui déléguer la décision de supprimer un compte créerait une surface d'attaque.

Ce mécanisme empêche un attaquant de spammer les litiges indéfiniment : chaque refus lui coûte 24 h, et trois échecs effacent toute trace. Un propriétaire légitime bloqué par erreur peut retenter après chaque fenêtre de ban, ou se réinscrire depuis zéro si totalement verrouillé.

Évolution prévue (en réflexion) : pré-traitement optionnel par chatbot LLM local

En complément du chat admin humain (qui resterait toujours disponible), une couche de pré-traitement par un agent conversationnel local (Ollama auto-hébergé) est en cours de design. Le chatbot poserait les questions initiales de vérification d'identité et estimerait si la demande est légitime. Sur estimation positive, le mot de passe serait régénéré directement ; sur doute, l'admin humain reprendrait la main.

Cette option serait configurable par site qui déploie (activable ou non), et le chatbot ne se substituerait jamais à l'admin pour les décisions destructives (suppression de compte) — ces décisions resteraient exclusivement humaines, conformément au principe MySelf énoncé plus haut.

L'enjeu principal en cours de réflexion : calibrer le seuil de confiance du chatbot pour ne pas créer un nouveau vecteur d'attaque par social engineering (un attaquant pourrait essayer de manipuler le LLM par prompts).

Démo standalone vs implémentation de référence

La démo publique (bi-self.my-self.fr/selfrecover/) ne couvre que les niveaux L1 et L2, car L3 nécessite une interface admin, un système de disputes et un dashboard — trop pour une démo à page unique.

L'implémentation de référence en production se trouve sur ARC PVE Hub, un site communautaire de joueurs ARC RAIDERS qui sert de terrain de test à l'écosystème MySelf. L1 + L2 + L3 + mode restreint + chat admin + dispute system y sont fonctionnels.

Pourquoi assumer cette friction

Dans la vie réelle, si l'on perd sa carte bancaire, son code, sa pièce d'identité, son adresse et sa date de naissance, on ne récupère pas son compte bancaire par email. On passe en agence avec preuve d'identité.

SelfRecover applique la même logique en ligne : la sécurité réelle nécessite parfois un passage par l'humain ou un processus d'identification rigoureux. Cette friction est assumée comme un trade-off conscient, pas comme une limitation à compenser.

Pour quel public

Adapté :
- Applications avec un administrateur actif et disponible pour traiter les litiges (forum communautaire, association, e-commerce indépendant, boutique en ligne militante)
- Sites où la sécurité prime sur la fluidité de récupération (services manipulant des données sensibles)
- Communautés à taille humaine (du forum de 50 membres au service de quelques milliers d'utilisateurs)

Non adapté :
- Plateformes à très grande échelle sans admin individuel (réseaux sociaux massifs, services publics avec millions d'utilisateurs) — le volume de litiges dépasse les capacités d'un humain réactif
- Services où une friction de récupération est inacceptable (gaming compétitif, services temps-réel)
- Projets sans maintenance active (l'admin doit pouvoir répondre aux litiges dans des délais raisonnables)

Pour ces cas, un IAM mature comme Keycloak avec ses mécanismes éprouvés reste plus adapté.

Modèle de menace assumé

Pour la transparence, voici les classes d'adversaires explicitement hors périmètre du protocole :

• Compromission du poste utilisateur (logiciels malveillants, RAT, keyloggers) — un attaquant qui contrôle le poste peut capturer la passphrase à la saisie, indépendamment du protocole.
• Compromission du navigateur (extensions malveillantes, exploits 0-day) — même cause, même effet : si le moteur JS qui calcule HMAC est compromis, la sortie l'est aussi.
• Coercition physique — SelfRecover n'offre pas de plausible deniability (pas de second compte caché ou décoy).
• Cryptanalyse théorique de SHA-256 / HMAC / Argon2id — un cassage mathématique de ces primitives mettrait à mal la quasi-totalité des systèmes cryptographiques modernes, pas seulement SelfRecover.

Ces limitations sont le périmètre normal d'un protocole côté navigateur. Pour les usages à plus haute exigence (cérémonies cryptographiques sensibles, génération initiale de clé maître), MySelf-Live est annoncé dans la roadmap V0.2 : une distribution Linux Live USB minimale, RAM-only, signée GPG, qui isolerait les opérations sensibles du système hôte. Pour les usages courants à fort enjeu, Tails ou Qubes OS offrent déjà ce niveau d'isolation et sont recommandés.

Démos en ligne

• Mode Full (sans email) : https://bi-self.my-self.fr/selfrecover/
• Mode Lite (email + mot mémorisé) : https://bi-self.my-self.fr/selfrecover/lite.html
• Comparatif sécurité 8 adversaires × 3 modèles : https://bi-self.my-self.fr/selfrecover/comparison.html

Aucune inscription préalable n'est requise. Les données sont éphémères côté serveur.

Code et image Docker

• Repo : https://github.com/Pierroons/my-self/tree/main/bi-self/selfrecover
• Whitepaper FR : https://github.com/Pierroons/my-self/blob/main/bi-self/selfrecover/docs/whitepaper-fr.md
• Threat model : https://github.com/Pierroons/my-self/blob/main/bi-self/selfrecover/docs/threat-model.md
• Image Docker multi-arch (amd64 + arm64) :

docker run -p 8080:8080 ghcr.io/pierroons/selfrecover:v0.1.1

La démo de référence tourne sur PHP 8.0+ et SQLite (~600 lignes auditables, zéro dépendance externe). Tag GPG-signé v0.1.1, release datée du 5 mai 2026.

Licence et philosophie

AGPL-3.0-or-later. Toute version déployée publiquement doit publier ses modifications sous la même licence. Pas de capture SaaS possible.

SelfRecover est une brique du méta-projet MySelf, un écosystème de modules auto-hébergés qui couvre l'identité, la modération communautaire, le droit, et l'agriculture.

Un module complémentaire répond de manière directe à la problématique illustrée par l'incident ANTS : SelfDataGuard chiffre les données utilisateur côté client de telle sorte qu'une fuite de base de données ne livre que des blobs inexploitables. Le code est public, AGPL, en v0.1.0-beta — une dépêche dédiée pourra suivre quand le module aura plus de maturité (audit communautaire, retours d'intégration).

Note de transparence

Conception en partenariat avec un assistant IA

Ce protocole a été conçu et codé en partenariat avec un assistant IA (Claude), comme outil de réflexion, de revue critique, et d'écriture de code.

Pour être totalement transparent : je ne suis pas développeur de formation. Mon expérience technique vient du dev web amateur (ARC PVE Hub, un site destiné à fédérer une communauté de joueurs ; un outil de gestion de stock pour mon entreprise ; quelques sites perso). Pour SelfRecover, l'écriture des primitives cryptographiques et la mise en œuvre du protocole ont été largement assistées par l'IA, sur la base de mes choix architecturaux et de ma vision.

Ce qui vient de moi (humain) :
- La vision (souveraineté numérique, refus du SMTP comme canal de récupération)
- Les choix philosophiques (AGPL-3.0-or-later, fallback humain assumé, aucune destruction de données sans validation humaine consciente)
- Le contexte initial (besoin né en développant ARC PVE Hub)
- Chaque décision de trade-off d'architecture
- La responsabilité juridique et morale du code publié sous mon nom et signé GPG

Ce qui vient de l'IA :
- L'écriture des primitives cryptographiques (HMAC, dérivations, vérifications)
- L'agencement du code, la structure des fichiers
- La formalisation des paragraphes du whitepaper et de cette dépêche
- La génération de tests unitaires
- La vérification de cohérence interne

Plan d'audit

• Auto-audit interne : en cours et continu (chaque modification est relue critiquement)
• Audit communautaire : ouvert dès maintenant, je réponds aux remarques techniques avec sérieux (cette dépêche en est l'illustration directe)
• Audit tiers certifié : envisagé à moyen terme via un cabinet agréé CESTI ANSSI (Synacktiv, Quarkslab, Wavestone, ou équivalent), sous réserve de financement

Statut du projet

SelfRecover en est à la version 0.1.1, taguée GPG et signée. C'est un état PoC fonctionnel + déployé en production sur un site réel (ARC PVE Hub), mais pas encore mature pour une adoption massive dans des contextes à fort enjeu. La roadmap V0.2 (MySelf-Live, finalisation du chatbot L3, audit tiers) précisera ce périmètre.

Engagement communauté LinuxFr et culture du libre

Mon compte LinuxFr est récent, mais mon ancrage dans la culture du libre ne l'est pas : utilisateur exclusif de distributions Linux depuis quinze ans (principalement Debian), j'ai aidé plusieurs proches à migrer des PC anciens vers Debian pour leur donner une seconde vie au lieu de la déchèterie. J'arrive sur LinuxFr depuis le monde agricole/permaculture et le jeu vidéo (ARC PVE Hub), pas du milieu dev historique.

Je suis salarié couvreur dans une PME et installé en agriculture à temps partiel — mon temps libre pour le développement et la participation communautaire est compté. Je m'engage à répondre aux retours techniques sur cette dépêche et à suivre les disputes sur l'état du projet. Pour le reste (commentaires réguliers, dépêches futures sur d'autres modules MySelf — en particulier SelfDataGuard quand il sera plus mature), ce sera au gré du temps disponible, sans promesse.

Toute critique technique constructive est bienvenue. Pour les critiques sur la légitimité du projet ou la nature humain/IA de la collaboration, j'invite à juger sur les choix concrets, le code public, et la qualité des réponses à vos questions.

Pour aller plus loin

SelfRecover est un module de l'écosystème MySelf, expérimentation citoyenne sur la souveraineté numérique sous licence AGPL-3.0-or-later.

Les retours techniques, audits communautaires, propositions d'intégration et questions de fond sont les bienvenus — en commentaire de cette dépêche ou en issue sur le repo GitHub.

Si une administration ou une organisation souhaite tester le protocole en environnement isolé, l'image Docker et le Dockerfile sont à disposition. Aucune démarche commerciale n'est associée à cette publication.

Merci aux modérateurs et contributeurs de LinuxFr — Pierre Jarillon, devnewton, Florent Zara, bobble bubble — dont les retours pendant la phase de rédaction ont substantiellement amélioré cette dépêche.

Ackify CE est une plateforme open-source (AGPL v3) permettant de générer des preuves de lecture cryptographiquement vérifiables pour des documents internes.

Le problème

Les organisations doivent souvent prouver qu'un collaborateur a lu un document (politique RGPD, charte de sécurité, formation obligatoire). Les solutions existantes sont soit trop lourdes (signature électronique qualifiée comme DocuSign à 10-30€/utilisateur/mois), soit non sécurisées (simple email).

La solution

Ackify génère des preuves de lecture cryptographiques avec :

• Signatures Ed25519 (même algo que SSH)
• Horodatage immutable (PostgreSQL triggers)
• Hash chain blockchain-like
• Vérification offline possible

Cas d'usage

• Validation de politiques internes (sécurité, RGPD)
• Attestations de formation obligatoire
• Prise de connaissance de procédures
• Accusés de réception contractuels

Différence avec DocuSign

Ackify n'est pas une alternative à DocuSign pour des contrats juridiques. C'est une solution simple pour des besoins internes où la signature qualifiée est overkill.

N'hésitez pas si vous avez des questions techniques !

Installation

curl -fsSL https://raw.githubusercontent.com/btouchard/ackify-ce/main/install/install.sh | bash
cd ackify-ce
nano .env  # Configurer OAuth2
docker compose up -d

Installation complète en ~5 minutes.

Stack technique

Backend

• Go 1.24 (Clean Architecture / DDD)
• PostgreSQL 16
• Chi Router
• OAuth2 (Google, GitHub, GitLab, custom) ou Magic Link (passwordless)

Frontend

• Vue 3 + TypeScript
• Tailwind CSS
• i18n (FR, EN, ES, DE, IT)

DevOps

• Docker distroless < 30 MB
• CI/CD GitHub Actions
• Tests : 72,6% couverture (180 tests unitaires + 33 intégration)

Il était une fois un petit ESP32, installé dans une cave, qui voulait communiquer avec son copain sur le toit pour envoyer des données par 4G. Il parlait peu, donc il pouvait utiliser la norme radio LoRa. Elle est à bas débit, mais permet une portée bien plus grande qu’une modulation classique. Le problème, c’est qu’il parlait en clair, et que n’importe qui pouvait écouter ou pire : injecter de fausses données, voire corrompre le serveur distant.

Le protocole de communication à la mode est celui de Signal, utilisé aussi par WhatsApp et Messenger. Un autre protocole en vogue est WireGuard, dont l’objectif est d’offrir un VPN léger pour Linux, en s’appuyant sur un ensemble restreint de briques cryptographiques modernes et fortement recommandées, qui ne sont plus laissées au choix de l’utilisateur.

L’idée était donc de trouver une implémentation de ce type pour l’embarqué. Eh bien, je n’ai presque rien trouvé.

Sommaire

• Briques de base
• Le chiffrement symétrique
• Le hash
• “Password hashing” ou la création de clef à partir de mot de passe
• Chiffrement à clef publique
• Générateur d’aléatoire
• Signature
• Serial Guard, le protocole de communication
• Le rejeu
• Durée de session
• Envoi d’un seul message
• Travail en cours

Briques de base

TLS est la référence absolue pour tous les algos, mais c’est à vous de faire votre choix. Libsodium est une implémentation des derniers algos recommandés et fait le choix pour vous. Ces deux bibliothèques sont énormes et sont optimisées pour PC. Un professeur de cryptographie a écrit une série de tweets qui contient une petite lib qui reprend les algorithmes de libsodium en version auditable (https://tweetnacl.cr.yp.to/). Mais elle est lente.

Une autre personne écrit ce que je cherche : Monocypher. C’est un fichier .c avec les algo principaux de libsodium et qui compile en pur C sans dépendance ! C’est parfait pour mon besoin.

Cette bibliothèque fournit uniquement les briques de base, on est très loin d’un protocole Signal. Quand on parle de cryptographie, on pense à AES pour le chiffrement symétrique, à RSA pour le chiffrement à clef publique et la signature, aux hashs SHA1 ou SHA512 pour un hash de qualité cryptographique. Les propriétés nécessaires sont fascinantes mais cela ne dit pas comment bien les utiliser ensuite.

Le chiffrement symétrique

Il s’agit de chiffrer un bloc avec une clé de taille fixe. Le représentant le plus connu est AES, avec des clés de 128 ou 256 bits. On a un bloc, on a une clé, et on obtient un bloc plus ou moins aléatoire. AES utilise des modes (GCM, XTS, …) pour renforcer le mélange et garantir la sécurité selon différents contextes.

Ici, l’algorithme recommandé est ChaCha20. Pas besoin de mode externe : tout est prévu dans l’algorithme de base.

Au déchiffrement, la brique ne se pose pas de question : si la donnée a été altérée, le résultat le sera aussi.Il faut donc ajouter un protocole d’authentification, qui utilise la même clé et un hash pour vérifier l’intégrité. Les algorithmes classiques sont MAC, HMAC, mais il est facile de faire une erreur dans leur utilisation.

Monocypher utilise Poly1305 pour authentifier le message (AEAD – Authenticated Encryption with Associated Data). Son API combine XChaCha20 et Poly1305, ce qui évite de se poser des questions : en cas de modification du message chiffré, la fonction de déchiffrement renvoie une erreur explicite.

Cette fonction nécessite un NONCE ("Number used once"), qui doit être différent à chaque appel.

Le hash

Un hash prend un bloc de données, fait une grosse salade et rend un chiffre de taille fixe avec de bonnes propriétés crypto. Le but est d’avoir une empreinte de taille fixe pour un bloc de données, et qu’il soit impossible de forger un hash identique en modifiant un peu les données d’origine. En gros.

Le hash recommandé est BLAKE2b : “as secure as SHA-3 and as fast as MD5”. Il fait 256 ou 512 bits.

“Password hashing” ou la création de clef à partir de mot de passe

Lorsqu’un mot de passe est saisi, il n’est jamais utilisé tel quel : il est d’abord transformé en une valeur de taille fixe via une fonction de hachage. Pour contrer les attaques par force brute, on a commencé par appliquer des centaines d’itérations de SHA1, avant d’adopter des fonctions de hachage volontairement lentes, comme bcrypt ou scrypt. Le but étant justement d’éviter qu’elles soient rapides, contrairement aux fonctions de hachage classiques.

Aujourd’hui, Argon2 est recommandé.

Chiffrement à clef publique

L’image est souvent celle d’un cadenas ouvert : n’importe qui peut fermer le cadenas, mais seul le possesseur de la clef peut l’ouvrir. RSA a été le premier algorithme inventé avec cette propriété. Aujourd’hui, la mode est aux courbes elliptiques avec X25519.

La fonction principale est basée sur l’échange Diffie-Hellman (DH). C’est le truc magique de la crypto asymétrique.

DH(Clef publique de A, Clé privée de B) = DH(Clef publique de B, Clé privée de A) = N

Sans une clef privée, il est cryptographiquement impossible de retrouver N.

Comment créer une clef privée ? C’est simplement 32 octets très aléatoires. Toute la sécurité dépend de cela. On se rappelle de la faille Debian utilisant un générateur prévisible en 2008.

Générateur d’aléatoire

Pour faire de la cryptographie sérieusement, il faut un vrai générateur aléatoire de qualité cryptographique. Monocypher, par exemple, n’en fournit pas, car cela dépend trop du matériel utilisé. C’est donc à vous d'en fournir un correct.

Ne surtout pas utiliser random() ou rand() : ces fonctions ne sont pas prévues pour la sécurité. Elles offrent souvent à peine 32 bits d’entropie, ce qui signifie qu’elles peuvent générer des valeurs qui tournent en boucle après seulement 4 milliards de cas, ce qui est trivial à explorer pour un attaquant moderne.

Un bon générateur s’appuie sur des sources d’entropie, autrement dit, des phénomènes imprévisibles : le bruit du système, les délais entre événements, la température, etc. Ensuite, ces sources sont mélangées (souvent via un gros hash) pour produire des nombres avec des propriétés statistiques solides.

Par exemple, Linux collecte plein de métriques internes (activité réseau, mouvements de la souris, etc.) pour alimenter son générateur aléatoire /dev/urandom.

Côté matériel, certaines plateformes proposent un vrai générateur physique : il peut mesurer le bruit électrique à travers une diode via un convertisseur analogique-numérique (ADC), ou encore exploiter les légères variations de vitesse d’oscillateurs internes (anneaux d’inverseurs), qui sont ensuite mélangées avec des circuits comme des LFSR combinés via XOR.

Utilisez le générateur cryptographique fourni par votre plateforme (par exemple getrandom(), arc4random(), ou un TRNG matériel si vous êtes en embarqué).

Il ne faut pas se créer son propre générateur sans savoir exactement ce que l’on fait. Le pire étant de réutiliser des données (des clefs par exemple) pour générer d’autres nombres. On crée ainsi une énorme dépendance entre eux, qui n’ont plus rien d’aléatoire.

Les dernières failles des imprimantes Brother proviennent du fait que les mots de passe d’administration sont dérivés de leur numéro de série (!).

Signature

On a un bloc de données, on signe avec une clef privée, on vérifie la signature avec la clef publique.

Monocypher propose EdDSA.

Serial Guard, le protocole de communication

Il ne faut pas créer sa propre cryptographie, c’est trop facile de se tromper. C’est pourtant exactement ce que j’ai fait. La suite peut donc contenir des erreurs. L’idée est de créer un protocole léger de communication. Si des experts passent par là et voient une horreur, qu’ils n’hésitent pas à crier.

On a maintenant les blocs de base. Et il faut maintenant les agencer comme il faut. On veut que A communique avec B (Alice et Bob), sans que E puisse comprendre les messages, insérer des messages, modifier des messages, rejouer des messages, récupérer les messages dans le futur s’il a tout enregistré et récupérer les clefs privées.

Dans le monde de l’embarqué « simple », on communique avec des read et des write sur lien série. L’idéal est d’avoir à peu près la même API.

Il faut réduire au minimum l’échange d’informations préalable pour être le plus léger possible.

Je laisse de coté le "framing", c'est à dire la mise en paquet pour être envoyé sur un lien physique. Un lien série envoie des octets, serialguard fonctionne par paquets d'octet. Il faut reconstituer un paquet avant de l'envoyer dans la bibliothèque.

La base est d’avoir une clef privée chacun, à longue durée de vie. Cela permet de s’authentifier selon le principe : si c’est toujours la même clef depuis l’installation, c’est toujours le même pair : TOFU.

Si on a besoin de faire mieux, il faudrait qu’une « clef de confiance » signe cette clef. Mais on entre dans les méandres complexes d’une public key infrastructure, des certificats ou des web of trust type GPG.

Pour pouvoir tout de même changer une clef privée à long terme, tout en ayant de la sécurité pour éviter les man-in-the-middle, il faut garder un secret partagé dans tous les pairs. Cela peut être très compliqué sur un réseau de serveurs, mais ici, chaque boîtier est programmé au même endroit.

Il s’agit simplement d’un nombre de 32 octets aléatoire partagé par tous. C’est nommé pompeusement pre-shared key (PSK).

Il faudra éviter de la laisser traîner dans le code source.

Une clef de session est une clef temporaire, renouvelable. L’idée est d’utiliser la cryptographie asymétrique pour se mettre d’accord sur une clef symétrique.

Si on utilise le nombre généré par Diffie-Hellman (DH) directement, il est unique par pair de clefs privées : ce n’est pas top. On pourrait échanger des nombres aléatoires pour se mettre d’accord sur une clef symétrique, mais je veux limiter les échanges au minimum.

Pour cela, je vais utiliser une clef de session asymétrique, qui est l’invention du protocole Signal. Une fois la clef symétrique générée, la clef privée éphémère est jetée. Il sera impossible ensuite de déchiffrer la session, même dans le futur.

On commence donc par un échange de 2 clefs publiques : l’une à durée de vie longue et l’autre éphémère.
On croise les 8 clefs (2 publiques et 2 privées de chaque côté) dans 3 échanges DH, on trie les nombres pour avoir le même ordre des 2 côtés, et le résultat est donné à la fonction de hachage avec la PSK.

On a ainsi notre clef de session symétrique.

Le rejeu

Tant que la session est active, l’envoi d’un message précédent reste valide. Pour éviter cela, un NONCE est utilisé dans le chiffrement symétrique. C’est un nombre fourni quelconque mais qui ne doit jamais être identique d’un paquet à l’autre. Il peut être transmis avec le paquet, mais cela prend de la place.

J’ai choisi d’utiliser un simple compteur, cela évite de devoir se rappeler les NONCE passés pour éviter le rejeu.

Les liaisons n’étant pas fiables, un paquet peut être corrompu : il faut pouvoir décoder le paquet suivant. J’ai simplement choisi de tester les 10 nombres successifs en cas d’erreurs, avant d’échouer.

Durée de session

Une session doit être limitée en temps ou en quantité d’informations transmises. Il faut trouver un événement symétrique des 2 côtés pour redéclencher un handshake. J’ai laissé ce point à l’application. Cela pourrait être inclus dans le protocole réseau de plus haut niveau.

Envoi d’un seul message

Ce schéma ne couvre pas le cas d’envoi d’un seul message.

Dans l’Internet des objets, on pousse un message dans MQTT et on ne s’attend pas à une réponse. Cela serait bien plus pratique de pouvoir le faire. Il faut pouvoir faire l’envoi sans handshake préalable. Mais il faut tout de même envoyer les clefs publiques, ce qui prend de la place.

Le système a besoin de la clef publique du serveur et du PSK, et tout le reste est fourni en plus du chiffré (NONCE, clef publique, et clef publique éphémère) dans le message envoyé.

La différence est qu’il n’y a que 2 DH, et pas de clef éphémère du côté serveur.

Travail en cours

C’est encore un travail en cours. Il manque des tests sur le terrain et l’évaluation des performances sur plusieurs plateformes.

Voici une sélection parmi ma veille du moment, ayant pour objectif de partager des liens mais aussi des sources : il s’agit bien évidemment de liens en rapport avec les thématiques du site (en l’occurrence dans cette fournée on trouvera logiciel libre, opendata, développement et vie privée par exemple), et ils sont plutôt variés ; les sources sont des sites web, des lettres d’actus et des réseaux sociaux (dans le cas présent, tous arrivés jusqu’à moi via des flux RSS/Atom), et c’est aussi une manière de les partager et de vous inviter à les suivre aussi. Dans la suite de la dépêche, on parlera donc en vrac GitHub, sécurité, Ruby, blocage de TikTok, Digital Services Act, biais, test, supervision, IA Act, Ada & Zangemann, pourrissement du web et bien d’autres choses encore.

Sommaire

• En vrac
• Des logiciels libres

En vrac

• forges logicielles et utilisation malveillante : Send()-ing Myself Belated Christmas Gifts - GitHub.com's Environment Variables & GHES Shell (avec une partie sur les attaques par réflexion en Ruby) et GitCaught: Threat Actor Leverages GitHub Repository for Malicious Infrastructure (via badcyber.com)
• une nouvelle liste de diffusion Siren annoncée par l'Open Source Security Foundation (OpenSSF) pour partager le renseignement sur les menaces sur les projets libres (via badcyber.com)
• un sujet qui touche aussi LinuxFr.org, le pourrissement des liens et la décomposition des contenus sur le web : Link Rot and Digital Decay on Government, News and Other Webpages: When Online Content Disappears annonce qu'un quart des pages web qui ont existé à un moment entre 2013 et 2023 ne sont plus disponibles, et ça monte à 38% pour la seule année de 2013. Cela concerne aussi plus de la moitié de liens donnés en référence sur Wikipedia par exemple (via badcyber.com).
• La Quadrature du Net attaque en justice le blocage de TikTok en Nouvelle-Calédonie (via le lien LinuxFr.org et via Olivier Tesquet ou via le flux LQDN ou…), et le Conseil d'État a refusé de lever l’interdiction d’opérer
• IA (et la fIAtigue qui monte)
  • l'Artificial Intelligence Act adopté en Europe (voir EU Approves Historic AI Act: Pioneering Comprehensive AI Regulation, toujours via Bearstech)
  • la réaction de La Quadrature du Net Le règlement IA adopté, la fuite en avant techno-solutionniste peut se poursuivre. Et udm14 pour éviter l'IA sur Google Search (source)
• la dernière édition « Santé mentale, toile d'araignée et larmes d'émeraude » de La cyber-revue hebdo mentionne des sujets peu funky, dont le rôle de la faille JumpServer (solution libre de bastion et audit système) CVE-2024-29201 utilisée en « test » sur les pays du Sud par les cybermalfrats
• Ada & Zangemann - Un conte sur les logiciels, le skateboard et la glace à la framboise (voir la dépêche) sera-t-il adapté en film d'animation ? C'est la volonté de la FSFE, aidez-les (via bearstech et le flux de la FSFE)
• la dernière édition de la revue de presse Khrys’presso datée du 20 mai 2024 mentionne un article scientifique de 2016 Gender bias in open source: Pull request acceptance of women versus men, la censure par le Conseil constitutionnel français (article FranceTV info) d'une partie de la loi pour sécuriser internet (SREN) concernant la création d'un « délit d'outrage en ligne », pour ce qui « porte atteinte à la dignité d'une personne ou présente à son égard un caractère injurieux, dégradant ou humiliant » ou « crée à son encontre une situation intimidante, hostile ou offensante », et un papier intitulé EU Platform Regulation in the Age of Neo-Illiberalism sur les plateformes et la directive Digital Services Act (DSA) européenne.
• le délégué général de l'April Frédéric Couchet rappelle sur son blog que les candidatures pour le prix science ouverte du logiciel libre de la recherche 2024 sont ouvertes, jusqu'au 24 juin, la création de « la lettre d'information Dans les algorithmes » qui « a pour ambition de pointer les problèmes de la société numérique, d’en discuter, de les mettre en débat » (voir l'annonce sur Mastodon et le lien sur la veille faite sur Flus par l'un des auteurs) ; ainsi qu'un entretien avec Delphine Montagne, fonctionnaire et wikimédienne en résidence chez code.gouv.fr (source)
• réparabilité des appareils Samsung : iFixit is ending collaboration with Samsung
• MessageFormat 2.0: a new standard for translatable messages et MessageFormat 2.0: A domain-specific language? (source via Adrien Dorsaz)

Des logiciels libres

• toujours Bearstech et sa liste apparemment infinie de logiciels libres à nous faire découvrir :
  • SolidStart framework Open Source pour applications Solid (source)
  • Bulletproof React pour des applications React prêtes pour la production (source)
  • WezTerm terminal rapide et multiplateforme, en Rust (source)
  • NamViek gestion de projet Open Source pour les petites équipes (source)
  • Activepieces pour automatiser vos workflows (source)
  • Ventoy pour créer des clés USB amorçables (source)
  • CADmium CAD (ou CAO) directement dans le navigateur (source)
  • OpenCart plateforme e-commerce en PHP (source)
  • Apisix passerelle API dynamique et haute performance (source)
  • Parse Server un backend pour Node.js/Express (source)
  • jobq pour une gestion simple des files d'attente de tâches (source)
  • GitUI interface terminal pour Git, en Rust (source)
  • Bend langage de programmation « haut niveau, massivement parallèle, supportant les "higher-order functions" et la récursivité sans annotations parallèles explicites » (source)
  • Firecrawl pour transformer des sites Web en markdown ou en données structurées (source)
  • Isleward un roguelike multijoueur (source),
  • StackStorm une solution automatisée Open Source pour la gestion d'événements, le dépannage, et le déploiement (source)
  • Antora un générateur de sites de documentation open source utilisant AsciiDoc (source)
  • BTW pour créer facilement votre blog personnel (source)
  • Piko pour gérer le trafic de production, notamment sur Kubernetes (source)
  • Jellyfin un système média (source)
  • Botan une bibliothèque de cryptographie complète pour C++ (source)
  • Glance un tableau de bord pour flux (source)
  • docker Selenium pour simplifier l'automatisation des navigateurs (source)
  • Zoraxy pour le routage réseau de votre homelab (source)
  • 100 exercices pour progresser en Rust (source)
  • HVM2 une VM massivement parallèle optimisée pour l'exécution de langages de haut niveau sur du matériel parallèle comme les GPU (source)
• le Framablog a publié deux articles Argos Panoptès : la supervision de sites web simple et efficace et Argos Panoptès, l’interview (à ne pas confondre avec Argo CD ou le langage Argos ou un certain nombre de projets ayant le même nom)
• il y a tellement de logiciels libres mentionnés dans la lettre d'info anglophone « SRE/Devops/Sysadmin » de Xavier Pestel. Sachez qu'on y a parle Kubernetes/Docker, Linux, observabilité, base de données, sécurité, Python, etc.