USB Secure Detonation Drive : isoler, observer et contrôler les échanges de fichiers
Le projet USB Secure Detonation Drive est né d’un besoin simple mais critique : permettre l’échange de fichiers entre un système hôte Windows et un Raspberry Pi tout en garantissant une isolation stricte, une traçabilité complète et un contrôle total sur ce qui transite. L’objectif n’est pas la performance ou la transparence utilisateur, mais la sécurité et la maîtrise du flux de données via une interface USB standard.
Le principe fondamental repose sur l’émulation, par le Raspberry Pi, de deux périphériques de stockage USB distincts exposés simultanément au système Windows. Ces deux volumes représentent deux zones logiques séparées, chacune ayant un rôle bien défini dans la chaîne de transfert. Le Raspberry Pi agit alors comme une barrière matérielle active, et non comme un simple support passif.
Contrairement à un partage réseau ou à une clé USB classique, le Raspberry Pi conserve un contrôle total du cycle de vie des fichiers. Les volumes exposés à Windows ne sont que des représentations logiques de stockages internes, montés, analysés et éventuellement filtrés côté Linux. Aucune exécution directe ni interaction système n’est possible sans passer par la couche de contrôle du Pi.
L’ambition initiale du projet était d’atteindre un comportement quasi instantané : toute modification de fichier effectuée côté Windows devait apparaître immédiatement côté Raspberry Pi, et inversement. Dans la pratique, cette ambition s’est heurtée à une réalité technique liée à la manière dont le stockage USB de type Mass Storage est conçu et géré par les systèmes d’exploitation.
En effet, le protocole USB Mass Storage repose sur une prise de contrôle exclusive du support par l’hôte. Une fois le disque monté par Windows, le système considère le média comme statique et ne s’attend pas à des modifications externes en temps réel. Cela impose des opérations de démontage, de reconnexion ou de réinitialisation du périphérique pour que les changements soient pris en compte correctement.
Cette contrainte révèle une limite structurelle : le problème ne relève ni d’un script, ni d’un bug logiciel, ni d’un mauvais montage des LUNs, mais bien du modèle USB lui-même. Tant que le périphérique se présente comme un disque de stockage bloc classique, la synchronisation bidirectionnelle dynamique reste fondamentalement incompatible avec les attentes du système hôte.
Ainsi, USB Secure Detonation Drive ne doit pas être vu comme un outil de synchronisation temps réel, mais comme un sas matériel sécurisé, destiné à l’analyse, la validation ou la neutralisation de données avant qu’elles ne franchissent une frontière de confiance. Dans ce cadre, les limitations observées ne sont pas des échecs, mais des propriétés intrinsèques du modèle choisi.
Protocole USB adapté au concept
Le protocole USB le plus cohérent pour le concept USB Secure Detonation Drive reste le USB Mass Storage Class (MSC), utilisant le transport Bulk-Only Transport (BOT) ou USB Attached SCSI (UAS). MSC est le seul protocole universellement supporté nativement par Windows sans pilote spécifique, ce qui garantit une compatibilité maximale et un comportement prévisible.
Toutefois, MSC impose une gestion en mode bloc avec verrouillage implicite côté hôte. Pour dépasser cette limite, il faudrait abandonner le paradigme du stockage bloc au profit d’un protocole de communication de fichiers ou de messages (USB CDC, USB Ethernet/RNDIS, ou un pilote propriétaire), ce qui transformerait fondamentalement le projet en interface de transfert contrôlée plutôt qu’en périphérique de stockage.