Sécurité & nœuds Obambu

1. Vue générale : qu’est-ce qu’un nœud Obambu ?

Un nœud 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 nœud 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.

À l’enregistrement d’un document via l’API admin (/api/v1/admin/docs), le nœud :

• 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, l’API « coté appareil » permet simplement de :

• dire « bonjour » au nœud (/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

L’outil admin_sign.py génère une paire de clés (secrète + publique) et signe les requêtes d’administration :

• la clé privée reste sur la machine de l’admin (jamais sur le nœud),
• la clé publique est enregistrée dans la configuration du nœud, 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 l’admin,
• X-Timestamp : horodatage (en secondes),
• X-Signature : signature ed25519 en base64.

Le nœud vérifie que :

• l’admin existe (clé publique connue),
• l’horodatage n’est 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 d’un bundle

L’API /api/v1/bundles/export fabrique un bundle à partir des documents du nœud :

• sélection des documents (liste limitée, priorité, région, etc.),
• construction d’un « blob » JSON {docs: [...]} puis compression gzip,
• encodage en base64 pour pouvoir voyager dans un fichier texte,
• création d’un 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é).

L’outil bundle_carrier.py permet de faire très simplement :

• export : récupérer un bundle depuis un nœud A et l’écrire en fichier (bundle.json) ;
• import : envoyer ce bundle vers un nœud 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 d’agent minimal pour une station K (mairie/relais) sur laptop ou RPi :

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

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

5. Feuille de route logicielle (version lisible)

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

Phase 0 – Nœud de base (déjà présent)

Objectif simple : un nœud 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 l’accès admin avant de multiplier les nœuds.

• Génération des paires de clés ed25519 pour les admins (admin_sign.py).
• Configuration des clés publiques sur chaque nœud 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 nœuds (laptops) en mode région/commune.
• Utiliser bundle_carrier.py pour simuler bus/moto entre nœuds.
• 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 d’un 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 nœuds

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 l’inté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 l’installation des nœuds.
• 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 nœud détruit ou confisqué (restauration depuis bundles + clés).

6. Conclusion

Le système actuel n’est pas encore une « blockchain complète » au sens académique. C’est volontaire : la priorité est de disposer d’un nœud 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 nœuds par LuckyBlocks et liens Wi-Fi.