Conteneurs chiffrés fiables avec support FIDO2 et cryptographie post-quantique

Les fournisseurs de cloud adorent répéter la phrase « vos données sont chiffrées au repos ». Cela semble rassurant, jusqu'à ce que vous vous souveniez de qui détient les clés de ce chiffrement. Si le fournisseur hébergeur possède les clés, alors toute demande réglementaire, fuite interne ou jeton d'accès compromis peut ouvrir vos fichiers à des tiers.

Pour éviter de faire confiance au service de quelqu'un d'autre, les données sont chiffrées côté client avant d'être envoyées sur le réseau. Des outils comme VeraCrypt, gocryptfs ou age existent pour cela, mais chacun présente des compromis : formats obsolètes, absence de support des clés matérielles, ou complications lors du montage du conteneur comme un disque ordinaire.

J'ai récemment découvert LUKSbox, un projet écrit en Rust. C'est un outil de création de conteneurs de fichiers chiffrés qui reprend les meilleures idées du monde LUKS2 mais les adapte au stockage cloud, aux clés USB et aux méthodes d'authentification modernes.

---

Ce qu'il y a à l'intérieur du conteneur

Le concept central est simple : toutes les données sont regroupées dans un seul fichier .lbx. Pour un observateur extérieur ou un lecteur cloud, ce fichier ressemble à du bruit aléatoire sans en-têtes ni métadonnées évidents, à condition que l'en-tête soit stocké dans un fichier séparé.

En même temps, le conteneur se monte dans le système d'exploitation comme un disque ordinaire via FUSE (sur Linux et macOS) ou WinFsp (sur Windows). Vous travaillez avec comme avec une clé USB ordinaire.

L'objectif principal du projet, tel que le décrivent ses auteurs, est de créer une copie sécurisée portable. Vous téléchargez .lbx vers S3, Dropbox ou un lecteur réseau partagé et dormez sur vos deux oreilles : l'hébergeur est physiquement incapable de lire le contenu.

---

Méthodes de déverrouillage et protection contre les ordinateurs quantiques

Généralement, le stockage chiffré nécessite un mot de passe. LUKSbox a aussi des mots de passe, hachés via Argon2id avec des paramètres par défaut sérieux, mais les développeurs sont allés plus loin en ajoutant des emplacements pour les clés matérielles.

Voici les options prises en charge pour déverrouiller le stockage :

1. Authentificateurs FIDO2. Vous pouvez lier un YubiKey, Nitrokey ou Google Titan via le protocole HMAC-secret. Sans toucher physiquement la clé, le conteneur ne s'ouvrira pas.
2. TPM 2.0. Liaison à la puce matérielle de votre carte mère sur Linux et Windows. Pratique si le conteneur ne doit s'ouvrir que sur votre poste de travail.
3. Mode hybride post-quantique. Protection contre le scénario « collecter maintenant, déchiffrer plus tard sur un ordinateur quantique ». LUKSbox peut combiner des algorithmes classiques avec l'algorithme ML-KEM (FIPS 203, anciennement Kyber). Un fichier de clé séparé .kyber est créé à cet effet, que vous pouvez conserver séparément du conteneur.

Aucun de ces emplacements ne chiffre directement les fichiers. Ils encapsulent la clé maître du volume. Après validation réussie de n'importe quel emplacement, la clé maître est déchiffrée, et les clés pour les métadonnées, les blocs de fichiers et la vérification d'intégrité en sont dérivées via HKDF-SHA256.

+-------------------------------------------------------------+
| Пароль / FIDO2 / TPM 2.0 / ML-KEM (.kyber)                 |
+------------------------------+------------------------------+
                               |
                               v
               +-------------------------------+
               | Master Volume Key (MVK)       |
               +---------------+---------------+
                               |
         +---------------------+---------------------+
         v                     v                     v
+-----------------+   +-----------------+   +-----------------+
| Header HMAC Key |   | Metadata Key    |   | Per-file Keys   |
+-----------------+   +-----------------+   +-----------------+

---

Sécurité au niveau des détails

Le dépôt impressionne par l'attention portée aux détails que de nombreux développeurs négligent.

Par défaut, AES-256-GCM-SIV est utilisé pour le chiffrement des blocs. L'ajout SIV fournit une résistance à la réutilisation du nonce, ce qui est utile lors des écrasements fréquents. Vous pouvez également choisir ChaCha20-Poly1305 ou AES-256-GCM standard.

Quelques découvertes intéressantes du code source :

• Protection contre la substitution de blocs. Chaque bloc chiffré d'un fichier est équipé de données authentifiées supplémentaires (AAD), incluant l'ID du fichier, l'index du bloc et le compteur de génération. Un attaquant basé sur le cloud ne pourra pas remplacer silencieusement un nouveau bloc par une version plus ancienne ni échanger des morceaux.
• Nettoyage de la mémoire. Sous Linux, l'appel système memfd_secret exclut la clé maître des dumps mémoire du noyau et des images d'hibernation. Sur les autres systèmes, une combinaison de verrouillage mémoire et de mise à zéro des tampons via les traits Zeroize est utilisée.
• Protection contre les attaques par retour en arrière. Un fichier sidecar optionnel .anchor stocke un compteur de modifications signé. Si un fournisseur revient à une version antérieure de l'ensemble du conteneur, le programme le remarquera.
• En-tête séparé. Si vous déplacez l'en-tête vers un fichier .hdr, le conteneur principal .lbx devient un tableau d'octets sans signatures.

---

Démarrage rapide

Le projet est écrit en Rust, vous pouvez donc le compiler depuis les sources de la manière standard cargo build. Des paquets pré-construits .deb, .rpm, des installateurs Windows et des bundles macOS sont disponibles pour la plupart des plateformes.

Vous pouvez gérer les conteneurs de trois manières : via la CLI, un assistant TUI interactif, ou une interface graphique construite avec egui.

Création d'un conteneur ordinaire et montage :

# Создаем хранилище с настройками по умолчанию
luksbox create my-vault.lbx

# Монтируем как директорию в Linux/macOS
luksbox mount my-vault.lbx /mnt/vault

# Или в отдельный диск в Windows
luksbox mount my-vault.lbx Z:

Ajout d'une clé matérielle FIDO2 à un conteneur existant :

luksbox enroll my-vault.lbx --kind fido2

Création d'un conteneur post-quantique avec une clé hybride sur une clé USB séparée :

luksbox create secure-data.lbx --kind hybrid-pq --pq-hybrid /media/usb/key.kyber

Si vous ne voulez pas mémoriser les drapeaux de ligne de commande, la commande luksbox wizard lance un dialogue pas à pas dans le terminal.

---

Scénarios pratiques

LUKSbox résout le problème du transport sécurisé et du stockage à distance. Voici des situations où le projet semble bien adapté :

1. Synchronisation via des clouds tiers. Vous stockez votre base de données de mots de passe, vos clés personnelles ou vos documents de travail dans un seul fichier .lbx dans un dossier Google Drive ou Yandex Disk.
2. Sauvegardes sur des serveurs externes. Un script de sauvegarde monte le conteneur, y place les nouveaux dumps, puis démonte le disque.
3. Partage d'archives secrètes. Envoi de fichiers à un collègue avec exigence de confirmation physique via un jeton matériel.

---

État actuel du projet

Le projet est en phase pré-1.0. Le format du conteneur v3 est déjà figé, le fuzzing est configuré dans le dépôt via libFuzzer et AFL++ avec des millions d'itérations. Quatorze rounds d'audit de sécurité internes ont été effectués, bien qu'un audit indépendant par un tiers soit encore à venir.

Les auteurs mettent en garde honnêtement : un conteneur chiffré est un point de défaillance unique. Si le fichier est corrompu ou si toutes les clés sont perdues, les données sont irrécupérables. Par conséquent, LUKSbox est conçu pour des copies portables protégées, et non comme emplacement de stockage unique pour des fichiers critiques.

Si vous avez besoin d'un outil de chiffrement moderne et multiplateforme avec support FIDO2 et une sécurité post-quantique, le dépôt mérite définitivement un coup d'œil. Le code source est publié sous licence Apache-2.0.