La clé USB qui ne s’ouvre que dans son boîtier

On coupe le réseau pour protéger un système. Puis on branche une clé USB dessus, parce qu’il faut bien le mettre à jour. L’air-gap ne supprime pas le risque : il le concentre sur un seul canal, physique, et souvent le moins surveillé de tous. Présenté à BarbHack 2026, BindKey (« Security at your fingertip ») s’attaque à ce canal. C’est un projet étudiant, mené par cinq élèves de 4^e année de l’ISEN Méditerranée en option cybersécurité, dans une enveloppe de 200 euros pour trois prototypes. Le niveau d’ingénierie mérite qu’on s’y arrête.

Sixième volet de notre couverture de BarbHack, et le premier consacré à une défense plutôt qu’à une attaque.

Le problème : le seul canal qui reste

Sous-marins, navires en mission, usines sensibles : les environnements isolés dépendent physiquement de supports amovibles pour leurs mises à jour logicielles. Et sur ce chemin, il n’existe aucun contrôle par conception. Un intermédiaire physique peut intercepter, lire, modifier ou supprimer les données, sans qu’aucune traçabilité simple ne l’en empêche ni ne le révèle. Le support voyage, change de mains, attend dans un tiroir. Il est fait pour ça.

La réponse habituelle consiste à chiffrer la clé. BindKey déplace le curseur : la clé n’est plus l’objet de confiance.

L’idée : dissocier l’élément chiffrant de l’élément chiffré

Un boîtier matériel, le proxy, s’intercale entre l’ordinateur hôte et un périphérique USB standard. Le support de stockage reste l’élément chiffré, banal et remplaçable ; le boîtier est l’élément chiffrant, et il ne quitte pas son porteur. Trois piliers :

• une authentification biométrique par empreinte digitale, gérée localement ;
• un chiffrement matériel transparent et à la volée, sans pilote sur l’hôte ;
• un contrôle d’intégrité en temps réel, pour détecter toute altération des fichiers pendant le transport.

Conséquence directe, démontrée sur scène : branchée directement sur un système d’exploitation, sans passer par le boîtier, la clé USB chiffrée n’est ni montable ni lisible. Elle redevient ce qu’elle aurait toujours dû être, un conteneur inerte.

Le scénario d’usage, et pourquoi il tient debout

L’accès aux volumes repose sur une authentification à triple facteur : les identifiants d’entreprise (adresse e-mail et mot de passe), la possession du boîtier matériel, et la validation par empreinte digitale.

Le partage est la partie la mieux pensée. Un développeur monte ses partitions chiffrées, par exemple une partition personnelle et une partition de mise à jour. Pour transmettre un fichier à un technicien, il ne partage pas la clé USB : il partage les droits cryptographiques de la seule partition concernée, en cherchant le destinataire par son nom dans l’annuaire de l’entreprise.

S’ensuivent deux propriétés qui font toute la différence sur le terrain :

• L’asynchronisme. Le technicien récupère les droits sur son propre boîtier avant même de recevoir physiquement la clé. Le support et l’autorisation voyagent séparément, ce qui est exactement ce qu’on attend d’un transfert sensible.
• L’isolation logique. Une fois sur le site de l’automate cible, seule la partition explicitement partagée est montée et visible. Le reste du contenu de la clé demeure inaccessible et impossible à monter, y compris pour un porteur légitime du boîtier.

L’architecture matérielle

Le microcontrôleur principal est un ESP32S3, retenu pour son support natif de Rust, ses interfaces USB-OTG et son accélération AES matérielle. Un microcontrôleur esclave pilote les composants et actionneurs physiques du boîtier.

Le capteur d’empreintes est un modèle à 15 euros, choix assumé pour tenir le budget. Un capteur bon marché se remplace facilement : l’équipe a donc prévu la parade. Un élément sécurisé dérive une preuve cryptographique qui lie de manière unique le capteur à la carte mère. Substituer le lecteur d’empreintes ne donne rien.

Côté hôte, l’émulation du périphérique de stockage de masse s’appuie sur TinyUSB. Le proxy est donc reconnu nativement par n’importe quel système d’exploitation, sans pilote, ce qui est une condition non négociable en environnement isolé : on n’installe rien sur l’automate qu’on vient mettre à jour. Le point d’interception est élégant : les appels de lecture et d’écriture de blocs émis par l’hôte sont capturés en réécrivant les callbacks bas niveau du protocole USB. C’est là, et nulle part ailleurs, que le chiffrement et le déchiffrement à la volée s’appliquent.

Cryptographie et carte électronique

Un composant ATECC608A, relié en I2C, assure le stockage sécurisé des clés. Il héberge deux emplacements pour les clés asymétriques (courbe P256, signatures ECDSA et dérivation de clé de chiffrement de clé), un emplacement pour un secret racine aléatoire généré à l’initialisation, et cinq emplacements réservés aux clés de partage reçues par le réseau.

Les secteurs du support sont chiffrés en AES-256, avec une dérivation de clés symétriques par KDF fondée sur SHA256, à partir du secret racine et de l’identifiant unique du volume. Chaque secteur physique reçoit un vecteur d’initialisation unique et déterministe.

Le détail qui trahit une vraie réflexion sur le modèle de menace se trouve entre les deux puces. Les échanges inter-microcontrôleurs passent par SPI, en trames de 16 octets d’en-tête et 1892 octets de charge utile, et ce bus est lui-même intégralement chiffré en AES-256-GCM. Autrement dit : l’équipe considère qu’un attaquant peut poser une sonde sur les pistes du circuit imprimé. C’est le même modèle d’adversaire que celui de la conférence sur l’injection de faute, et il est rare de le voir pris au sérieux à ce niveau de projet.

Le prix est annoncé sans détour : 1,75 Mbit/s de débit effectif mesuré. C’est la limite du montage, et l’équipe identifie déjà la piste d’optimisation, un microcontrôleur unique disposant de deux interfaces USB. Le PCB embarque par ailleurs des diodes de protection ESD, des fusibles réarmables contre les attaques par perturbation d’alimentation, et un interrupteur logique permettant de couper l’alimentation du périphérique USB pour éviter les désynchronisations à l’énumération.

Le client « aveugle », la décision qu’on retient

L’application cliente est écrite en Rust, sur le runtime asynchrone Tokio, en application native pour pouvoir exécuter les appels système bas niveau vers les périphériques USB. Mais l’essentiel est ailleurs : elle est conçue sans état.

Aucune clé de chiffrement n’est stockée ni manipulée dans ses variables applicatives. Elle se borne à convoyer des enveloppes cryptographiques chiffrées entre le matériel et le serveur distant. L’hypothèse de départ est explicite et saine : le poste de travail hôte peut être compromis, et une extraction de mémoire vive ne doit alors rien rapporter. Un orchestrateur aveugle, littéralement.

L’interface délègue les traitements lourds à des threads séparés et communique avec eux par canaux de messages, ce qui évite tout gel de l’affichage. Détail de confort, mais qui compte pour un outil destiné à être utilisé debout, en salle machine.

Le serveur, relais et rien de plus

Le serveur ne fait que relayer aveuglément les enveloppes de droits entre utilisateurs, pour rendre le partage asynchrone possible. Il n’a aucun accès aux clés ni aux données. Il conserve seulement, en base, la disponibilité des cinq emplacements de clés partagées de chaque boîtier, ce qui permet d’attribuer et de vérifier les ressources libres sans interroger le matériel.

La pile est déployée sur Kubernetes, contrainte académique assumée : Ingress Nginx pour la terminaison TLS, un service vers l’API d’arrière-plan, et PostgreSQL managé par l’opérateur CloudNativePG pour les métadonnées d’orchestration.

Ce qu’on en retient chez Humanix

• L’air-gap n’est pas une propriété de sécurité, c’est une contrainte d’exploitation. Il ne supprime pas la surface d’attaque, il la réduit à un canal unique, physique, asynchrone et rarement journalisé. Si vous exploitez des systèmes isolés, la vraie question n’est pas « sont-ils déconnectés » mais « que prouve le support qui entre » : d’où il vient, qui l’a autorisé, ce qu’il contient réellement.
• Séparer le porteur du secret et le porteur de la donnée est une idée transposable bien au-delà de l’USB. Elle rend le support volable sans conséquence, et permet de faire voyager l’autorisation et la donnée par des chemins distincts.
• Poser « l’hôte est compromis » comme hypothèse de départ change la conception, pas seulement le discours. C’est ce qui produit un client sans état plutôt qu’un client qui « protège bien » ses clés en mémoire. Cette décision-là est gratuite si elle est prise au début, et très coûteuse si elle est prise après.
• Le modèle d’adversaire doit descendre jusqu’au circuit imprimé dès lors que le matériel est manipulable par un tiers. Chiffrer un bus interne et lier le capteur à la carte mère ne sont pas des raffinements : ce sont les deux contournements les plus évidents, et ils sont traités.
• Deux cents euros, trois prototypes, cinq étudiants de 4^e année. C’est le chiffre à garder en tête la prochaine fois qu’un fournisseur expliquera que ce niveau de protection est hors budget. Et c’est aussi, pour nous, la meilleure illustration de ce que produit une pédagogie par le projet réel : on comprend une menace en construisant la défense.

Note. Compte-rendu, à visée pédagogique, d’une revue de projet présentée à BarbHack 2026 : BindKey, proxy matériel de sécurisation des transferts en environnement air-gap, réalisé par cinq étudiants de 4^e année de l’ISEN Méditerranée en option cybersécurité. Il s’agit d’un prototype académique et non d’un produit commercialisé ; les caractéristiques citées sont celles présentées par l’équipe. Sixième volet de notre couverture de l’événement. Des transferts physiques à sécuriser sur un site isolé ? Contactez-nous.