Sécurité & nuds Obambu

1. Vue générale : quest-ce quun nud Obambu ?

Un nud Obambu est un petit serveur (laptop, mini-PC, RPi, etc.) qui joue trois rôles :

• serveur de contenus (documents, émissions, messages structurés),
• registre local de ce qui existe (index des documents et métadonnées),
• point de passage pour des bundles (LuckyBlocks) qui circulent entre zones.

Techniquement, le nud actuel est une application FastAPI avec un stockage SQLite, quelques dossiers de fichiers, et une couche de sécurité admin.

2. Stockage : fichiers + métadonnées

Le code de stockage (storage.py) organise les données dans une arborescence très simple :

• storage/docs/ : les fichiers binaires (.bin) des documents,
• storage/meta/ : les métadonnées en JSON,
• storage/obambu.sqlite : la base de données SQLite pour suivre les appareils, les plans de contenus, les profils de stations.

lenregistrement dun document via lAPI admin (/api/v1/admin/docs), le nud :

• décode le fichier reçu (base64) et lécrit dans storage/docs/<doc_id>.bin,
• calcule un hash et la taille,
• met à jour la métadonnée complète du document dans SQLite et dans un fichier .json. :contentReference[oaicite:1]{index=1}

Pour les boîtiers ou téléphones, lAPI « coté appareil » permet simplement de :

• dire « bonjour » au nud (/api/v1/device/hello) ;
• demander une config ou un plan de contenu selon le type de station (S, H, K) ;
• demander les documents dont ils ont besoin (/api/v1/device/content ou .../content_stream). :contentReference[oaicite:2]{index=2}

3. Sécurité admin : token & signatures ed25519

Les opérations sensibles (ajouter des documents, gérer les profils de station, importer des bundles) sont protégées par une double mécanique :

• un token admin simple (X-Admin-Token), pour les premiers tests,
• une signature numérique plus robuste, basée sur ed25519.

3.1. Principe des signatures admin

Loutil admin_sign.py génère une paire de clés (secrète + publique) et signe les requêtes dadministration :

• la clé privée reste sur la machine de ladmin (jamais sur le nud),
• la clé publique est enregistrée dans la configuration du nud, dans la variable ADMIN_PUBKEYS.

Pour chaque requête sensible, on calcule une signature sur :

METHOD + "\n" + PATH + "\n" + TIMESTAMP + "\n" + BODY

Les en-têtes envoyés deviennent alors :

• X-Admin-Id : identifiant de ladmin,
• X-Timestamp : horodatage (en secondes),
• X-Signature : signature ed25519 en base64.

Le nud vérifie que :

• ladmin existe (clé publique connue),
• lhorodatage nest pas trop ancien ou trop futur (clock skew limité),
• la signature est valide pour cette méthode, ce chemin et ce corps. :contentReference[oaicite:5]{index=5}

4. Bundles « LuckyBlocks » : transport opportuniste sécurisé

Pour traverser les zones sans réseau permanent, Obambu utilise des bundles, aussi appelés LuckyBlocks : des paquets de documents compressés, signés et transportés physiquement (USB) ou via des porteurs (téléphones, laptops, boîtiers S/H).

4.1. Contenu dun bundle

LAPI /api/v1/bundles/export fabrique un bundle à partir des documents du nud :

• sélection des documents (liste limitée, priorité, région, etc.),
• construction dun « blob » JSON {docs: [...]} puis compression gzip,
• encodage en base64 pour pouvoir voyager dans un fichier texte,
• création dun manifest avec :
  • destinations (pays, région, maire, station K/H la plus proche, proxies éventuels),
  • priorité (P0..P3),
  • nombre de documents / taille,
  • hash global du blob (intégrité).

Loutil bundle_carrier.py permet de faire très simplement :

• export : récupérer un bundle depuis un nud A et lécrire en fichier (bundle.json) ;
• import : envoyer ce bundle vers un nud B, qui décompresse et réinjecte les documents.

4.2. Rôle de la station K agent

Le script station_k_agent.py joue le rôle dagent minimal pour une station K (mairie/relais) sur laptop ou RPi :

• init : enregistre son identité (station_id, région, commune), lAPI locale et le token,
• ingest : lit un bundle, regarde le manifest, et décide :
  • « cest pour moi » import via /api/v1/bundles/import,
  • « cest pour ailleurs » place le bundle en outbox/ pour le relayer plus tard.
• export : demande un bundle à son nud local, à destination dune région/maire, et lécrit en fichier. :contentReference[oaicite:8]{index=8}

Cet agent représente le comportement minimal dune mairie dans la couche LuckyBlock : absorber ce qui la concerne, relayer le reste.

5. Feuille de route logicielle (version lisible)

La base actuelle (nud FastAPI + stockage + bundles + scripts de transport) est déjà suffisante pour tester le modèle en labo. La roadmap suivante détaille comment passer dun « serveur de fichiers intelligent » à une blockchain locale des maires.

Phase 0 Nud de base (déjà présent)

Objectif simple : un nud qui répond, stocke des documents et alimente les boîtiers.

• API appareil : /device/hello, /device/config, /device/content*.
• Stockage : fichiers .bin + métadonnées en JSON + index SQLite.
• Admin simple : upload/liste/suppression de documents.

Phase 1 Sécurité admin robuste

Rendre sérieux laccès admin avant de multiplier les nuds.

• Génération des paires de clés ed25519 pour les admins (admin_sign.py).
• Configuration des clés publiques sur chaque nud via ADMIN_PUBKEYS.
• Utilisation systématique de X-Admin-Id, X-Timestamp, X-Signature pour toutes les opérations sensibles.

Phase 2 Bundles & ferries en conditions réelles

Tester les LuckyBlocks avec de vrais transports humains (USB, Termux, laptops).

• Mettre en place plusieurs nuds (laptops) en mode région/commune.
• Utiliser bundle_carrier.py pour simuler bus/moto entre nuds.
• Ajouter des ACK plus riches pour pouvoir purger les bundles délivrés (API /api/v1/bundles/ack).

Phase 3 Journal dévénements type blockchain

Passer dun simple stockage de fichiers à un vrai journal dévénements signés.

• Introduire une table events ou blocks dans SQLite (ou fichiers JSON structurés) pour stocker :
  • transactions ID_CLAIM (identités),
  • transactions ACTE_ADMIN (actes officiels),
  • transactions FORUM_POST (messages du forum des maires).
• Signer chaque transaction (clé du maire ou de la mairie).
• Former des « blocs » réguliers (toutes les X transactions ou X minutes).

Phase 4 Synchro de la chaîne entre nuds

Propager les événements (blocs) en plus des documents.

• tendre les bundles LuckyBlocks pour inclure des blocs de chaîne.
• Ajouter un mécanisme de résolution de conflits simple (par exemple « chaîne la plus longue et la plus signée » PoA léger).
• Permettre aux mairies de vérifier localement lintégrité de la chaîne (hash, signatures).

Phase 5 Forum des maires & votes

Utiliser la chaîne pour des usages politiques concrets.

• UI simple pour le forum des maires (threads, réponses, résolutions).
• Transactions de vote chiffrées, avec dépouillement transparent.
• Gestion des rôles : maire, préfet, expert, simples observateurs.

Phase 6 Optimisation & simplification pour terrain

Aller vers un système que des non-techniciens peuvent maintenir.

• Automatiser au maximum linstallation des nuds.
• Rendre les scripts station_k_agent.py et bundle_carrier.py utilisables par un agent local non technique (menus, messages clairs).
• Documenter la procédure pour remplacer un nud détruit ou confisqué (restauration depuis bundles + clés).

6. Conclusion

Le système actuel nest pas encore une « blockchain complète » au sens académique. Cest volontaire : la priorité est de disposer dun nud simple, transportable et sécurisé que les mairies peuvent utiliser, même avec trois laptops et deux ESP32.

La blockchain locale des maires émergera progressivement en ajoutant un journal dévénements signés, des blocs, puis une synchronisation entre nuds par LuckyBlocks et liens Wi-Fi.