PandoraBox est une borne libre de décontamination de clés USB, une « station blanche » : on insère une clé, la borne analyse chaque fichier avec plusieurs moteurs de détection, affiche les fichiers dangereux sur son écran tactile, puis les supprime quand l'utilisateur touche l'écran. La nouvelle version est une réécriture complète. Elle ne dépend plus du projet Pandora du CIRCL et elle est distribuée sous forme d'image système durcie, construite à partir de Debian 13. Le code est sous licence GPL-3.0 et le boîtier imprimable en 3D sous licence CERN-OHL-S v2.

Pourquoi une borne de décontamination

Les clés USB restent une porte d'entrée courante dans des systèmes d'information par ailleurs bien protégés. Les personnes changent d'organisation, utilisent des ordinateurs qui ne sont pas surveillés et vont sur des réseaux isolés. La borne de décontamination vérifie les objets avant qu’ils arrivent au poste de travail.

PandoraBox propose une solution ouverte, que tout le monde peut vérifier, pour remplacer les bornes du commerce. PandoraBox s’adresse aux lieux qui demandent plus de sécurité, comme les hôpitaux, les usines ou les bureaux de l’État. Elle tourne sur un petit ordinateur reconditionné avec un écran tactile, et fonctionne sans réseau.

Plus de détail sur cette nouvelle version dans la seconde partie de la dépêche.

Sommaire

• • Une version entièrement réécrite.
  • Plusieurs moteurs de détection
  • Une image système durcie
  • Mises à jour signées et maintenance sans session
• Matériel et interface
  • État du projet
  • Essayer et contribuer

Une version entièrement réécrite.

La première version de PandoraBox s'appuyait sur Pandora du CIRCL pour analyser les fichiers. La nouvelle version repart d'une base propre et ne garde que ce qui fonctionnait : la machine à états, la détection USB avec pyudev, la quarantaine et l'interface curses du mode administrateur.

Les principaux changements :

• les appels à pypandora sont remplacés par une chaîne de moteurs de détection intégrée ;
• le moteur Comodo, qui n'est plus maintenu sous Linux, disparaît ;
• le diaporama d'images (fim) laisse la place à une vraie interface graphique tactile ;
• les clés sont montées en lecture seule par la borne elle-même, avec des options de montage durcies ;
• les journaux passent au JSON structuré ;
• la borne n'est plus un logiciel à installer sur un système existant, mais une image système complète.

Plusieurs moteurs de détection

Chaque fichier passe par plusieurs moteurs complémentaires :

• MalwareBazaar propose des empreintes SHA-256 de logiciels malveillants connus.
• Le service CIRCL Hashlookup aide à repérer les fichiers connus grâce à un filtre de Bloom.
• ClamAV : antivirus, y compris dans les archives
• YARA-X : YARA Forge
• Heuristiques : programmes déguisés en documents (double extension, type réel différent de l'extension), PDF avec JavaScript ou actions de lancement

La borne a un mode « fail closed » : si la borne ne peut pas analyser tout le fichier, comme pour une archive protégée par mot de passe, un fichier trop gros ou une erreur dans un moteur, la borne ne dit jamais que le fichier est sûr. Chaque partition de la clé est analysée, et une partition illisible (chiffrée, système de fichiers inconnu) rend la clé « non vérifiée ».

Rien n'est supprimé sans l'utilisateur : les fichiers dangereux sont listés à l'écran, copiés dans la quarantaine de la borne, puis retirés de la clé seulement après un appui sur l'écran. Chaque analyse donne un rapport JSON.

Une image système durcie

La clé USB pose un risque car la clé USB est vue comme un objet dangereux. Les moteurs d'analyse risquent d'être piratés. L'image est construite avec mkosi à partir des paquets Debian 13, et ne contient que ce qui sert à analyser :

• chaîne de démarrage vérifiée : Secure Boot avec la clé de l'image enrôlée à la place de celles de Microsoft, image noyau unifiée (UKI) signée, système de fichiers racine EROFS en lecture seule protégé par dm-verity, noyau en mode lockdown ;
• périphériques USB filtrés : USBGuard n'autorise que le stockage de masse, ce qui bloque les clés qui se font passer pour un clavier (BadUSB), et les pilotes réseau USB, Wi-Fi et Bluetooth sont retirés de l'image ;
• aucune session : pas de compte, pas de programme login, pas de menu de démarrage ;
• un bac à sable par moteur : chaque moteur tourne dans son propre processus, avec bubblewrap, un utilisateur dédié sans privilèges, un filtre seccomp et aucun accès réseau. Un moteur compromis par un fichier piégé ne peut pas falsifier le résultat d'un autre ;
• pare-feu et réglages du noyau inspirés des recommandations de l'ANSSI pour les systèmes GNU/Linux. Lynis donne un indice de durcissement de 73, sans avertissement.

L'interface graphique est dessinée avec Pillow directement dans le framebuffer, sans serveur d'affichage ni navigateur.

Mises à jour signées et maintenance sans session

La borne fonctionne hors ligne par défaut. Tout ce qui la modifie arrive signé :

• Les signatures : le logiciel vérifie un jeu de signatures signé Ed25519 à chaque démarrage. Il s'installe depuis une clé USB de mise à jour, qui n'est jamais analysée, ou en ligne avec le profil online de l'image. Sans jeu valide, la borne n'analyse rien. Un jeu plus ancien est refusé ;
• Le système accepte les mises à jour A/B avec systemd-sysupdate, par clé USB ou en ligne. La nouvelle version est écrite dans l'emplacement libre, et après 3 démarrages ratés, systemd-boot revient à la version précédente ;
• journaux : une clé de maintenance signée récupère les journaux de la borne (journal systemd, noyau, USBGuard, matériel) sans ouvrir de session et sans rien modifier.

Une borne en ligne peut aussi envoyer ses journaux à un SIEM (Wazuh, Elastic, Graylog, Splunk) en syslog RFC 5424 ou en JSON, sur TLS. En ligne, seuls le service de mise à jour, l'export SIEM et NTP peuvent sortir à travers le pare-feu. La borne elle-même n'a toujours pas accès au réseau.

Matériel et interface

La borne de référence est un Lenovo ThinkCentre M720q Tiny reconditionné (Core i5-9400T, 6 cœurs), avec un écran tactile Waveshare de 7 pouces (1024x600). L'image fonctionne sur tout ordinateur x86_64 UEFI, avec 2 Go de mémoire au minimum. Le boîtier de bureau s'imprime en 3D en une seule pièce.

L'interface est pensée pour le tactile, sans bouton : attente d'une clé, progression de l'analyse, liste des fichiers dangereux, appui n'importe où sur l'écran pour nettoyer, puis résultat. Chaque organisation peut y mettre son logo, ses couleurs, ses textes et sa langue (français et anglais fournis).

L'image est testée de bout en bout dans une machine virtuelle QEMU/KVM. Le test démarre l'image avec Secure Boot, insère des clés USB émulées (vfat, exFAT, NTFS, ext4), vérifie le verdict de chaque moteur, le nettoyage, les mises à jour et le retour à la version précédente.

État du projet

Le projet est en développement actif. L'analyse marche bien. L'image durcie fonctionne comme attendu. L'interface tactile répond comme il faut. Les mises à jour passent sans souci. L'export SIEM est validé. Le matériel de référence a permis de tout vérifier.

Une limite importante reste à lever : l'image et les jeux de signatures ne sont signés pour l'instant qu'avec des clés de développement, générées sur la machine qui construit l'image. Les clés de publication du projet et leur stockage ne sont pas encore définis.

Les prochaines étapes de la feuille de route :

• analyse des macros Office avec oletools et des exécutables avec capa ;
• désarmement et reconstruction de contenu (CDR) avec Dangerzone ;
• serveur central facultatif : inventaire des bornes, rapports, état des signatures ;
• modèle de menace documenté, fuzzing des points d'entrée et audit de sécurité externe ;
• correspondance avec les exigences NIS2 et ISO 27001 (mesure 7.10 « Supports de stockage »).

Essayer et contribuer

Il suffit de Docker pour construire l'image et la tester dans une machine virtuelle :

git clone https://github.com/sourcentis/pandora-box.git
cd pandora-box
image/build.sh                            # construit l'image
image/build-test.sh && image/vm.sh test   # la teste dans une machine virtuelle

Les contributions sont les bienvenues : retours d'expérience sur d'autres matériels, règles de détection, traductions de l'interface, revue de sécurité. Les vulnérabilités se signalent selon la politique de sécurité.

287ème émission Libre à vous ! de l’April. Podcast et programme :

• sujet principal : Journées Nationales de la Réparation : les logiciels libres ont un rôle à jouer !, avec Tiphaine Breton, bénévole de l’association Les Petits Pois Sont Verts, et Koffi Hukportie, président de l’association Générations Solidaires Val d’Oise (GSVO)
• la chronique Pépites libres de Jean-Christophe Becquet sur le thème « *.data.gouv.fr : 10 ans de données ouvertes »
• la chronique La Pituite de Luk sur le thème « Le réseau de confiance de mes rêves »

Rendez‑vous en direct chaque mardi de 15 h 30 à 17 h sur 93,1 FM en Île‑de‑France. L’émission est diffusée simultanément sur le site Web de la radio Cause Commune.

Vous pouvez laisser un message sur le répondeur de la radio, pour réagir à l’un des sujets de l’émission ou poser une question. Le 287éro du répondeur : +33 9 72 51 55 46.

(NdM : Tempo est une offre commerciale d'EDF, cette dépêche traite des API et flux de données ouverts permettant de connaître et prédire les coûts du kWh.)

En avril 2025, une dépêche faisait le point sur les sources accessibles sans jeton pour connaître la couleur Tempo du jour, après la fermeture des anciennes URL d'EDF. La saison des jours rouges reprend le 1er novembre : voici une mise à jour, avec une nouveauté, des prévisions au delà de demain en JSON et en données ouvertes. Transparence d'abord : je fais partie de l'équipe de Calendrier Tempo EDF, l'une des sources présentées plus bas.

Rappel du contexte

L'option Tempo d'EDF compte 300 jours bleus, 43 blancs et 22 rouges par saison. Les jours rouges tombent entre le 1er novembre et le 31 mars, jamais un samedi ni un dimanche, et le kWh y coûte nettement plus cher. La couleur du lendemain est fixée par RTE et annoncée la veille. Pour piloter un chauffage ou une machine à laver depuis une box domotique, il faut donc une source lisible par une machine.

La couleur officielle (aujourd'hui et demain)

• RTE : la source officielle. Son API passe par un compte et un jeton sur le portail data de RTE. Les couleurs passées sont aussi publiées en données ouvertes : Tempo Like Supply Contract sur data.gouv.fr.
• api-couleur-tempo.fr : déjà citée en 2025, toujours là. JSON simple, sans clé, très utilisé dans les forums domotiques.
• Calendrier Tempo EDF : relaie la couleur officielle (via api-couleur-tempo.fr) sur /api/today et /api/tomorrow, qui renvoie "status": "unavailable" tant que la couleur de demain n'est pas publiée. Si vous lisez déjà RTE directement, gardez cette source : c'est l'originale.

Exemple :

curl https://www.calendrier-tempo.fr/api/today
{"status": "ok", "date": "2026-10-09", "couleur": "BLEU", "code": 1}

Les prévisions (après demain)

C'est ce qui a changé depuis 2025 : on trouve maintenant des prévisions en JSON, sans compte.

• Open DPE publie un fichier de prévisions jour par jour, avec une probabilité : https://open-dpe.fr/assets/tempo_days_lite.json
• Calendrier Tempo EDF publie /api/predictions : une prévision par jour jusqu'à J+15, avec la probabilité de chaque couleur et la température moyenne prévue, recalculée chaque soir à partir des prévisions de consommation de RTE, de la météo (Open‑Meteo) et des règles officielles de Tempo. /api/remaining donne les jours restants par couleur dans la saison.

Une prévision reste une prévision, et seule la couleur publiée fait foi. Plus l'échéance est lointaine, plus c'est une tendance qu'une certitude.

Vérifier avant de faire confiance

Plusieurs fils de forums domotiques l'ont montré l'hiver dernier : des prévisions affichées sans historique, on ne sait jamais ce qu'elles valent. Chez Calendrier Tempo EDF, chaque prévision est figée au moment où elle est émise, de J‑15 à la veille, puis comparée à la couleur réelle. L'historique complet, erreurs comprises, est consultable en ligne et téléchargeable en CSV sous licence CC BY 4.0 :

• Historique des prévisions sur data.gouv.fr
• CSV mis à jour chaque jour : https://www.calendrier-tempo.fr/historique-previsions.csv

De quoi mesurer soi‑même la fiabilité par échéance, et comparer les sources cet hiver.

Côté domotique

L'API ne demande ni compte ni clé, et les réponses sont en cache deux minutes : une requête toutes les trente minutes suffit largement. Des configurations prêtes à copier pour Home Assistant (intégration installable via HACS, sous licence MIT), Jeedom et Domoticz sont réunies sur une page : intégrations domotique. Documentation de l'API : https://www.calendrier-tempo.fr/api-tempo

Pour finir

Comme en 2025 : si vous connaissez d'autres sources sans jeton, ou si vous suivez la fiabilité des prévisions de votre côté, les commentaires sont là pour ça.