MCC Protocol
Une couche d'orchestration cryptographique pour les agents — développée en Rust, sécurisée par une vérification basée sur certificats
MCC est une couche d'orchestration cryptographique pour agents et un cadre Trusted Execution Agent implémenté en Rust. La plateforme permet une communication pair-à-pair sécurisée à travers des réseaux distribués grâce à une sécurité basée sur certificats avec chiffrement de bout en bout. MCC est conçu pour les appareils IoT, les réseaux industriels et les systèmes d'agents IA autonomes nécessitant une communication sécurisée et à faible latence, sans dépendre d'une infrastructure centralisée.
Six propriétés qui distinguent MCC d'un VPN ou d'un service mesh.
Chaque décision architecturale de MCC est traçable à l'un de ces six objectifs. Pas d'arguments marketing, pas de promesses vagues — uniquement les propriétés que le protocole applique réellement.
Architecture Verified-Trust
Un cadre Trusted Execution Agent où chaque connexion nécessite une vérification cryptographique. Aucun paquet ne circule sans identité explicite, certificat signé et configuration de tunnel correspondante.
Chiffrement de bout en bout
Chiffrement AEAD ChaCha20-Poly1305 pour tout le trafic. Doublement chiffré : couche tunnel + couche RPC. Même des nœuds intermédiaires compromis ne peuvent pas lire vos données.
Support multiplateforme
Intégration native TUN/TAP sous Linux, Android et macOS. Support Windows prévu via WinTUN. Même noyau Rust partout.
Efficace en ressources
Optimisé pour les systèmes embarqués et les appareils à ressources limitées. Un nœud de base utilise ~10 Mo de mémoire. CPU au repos inférieur à 1 %. Fonctionne sur des routeurs MIPS-32.
Authentification basée sur certificats
Échange de clés à courbe elliptique X25519 avec certificats signés Ed25519. Hiérarchie à trois niveaux : autorité de certification → certificats réseau → certificats de nœud et de tunnel.
Topologie maillée hiérarchique
Routage parent-enfant basé sur un arbre, optimisé pour les déploiements IoT typiques. Moteur de routage Pancake avec calcul du plus court chemin de Dijkstra et mise en cache du prochain saut.
Six modules centraux. Un seul binaire Rust.
MCC est livré sous forme d'un binaire Rust unique exposant une interface web (Vue.js), une API REST (Axum) et une API socket Unix. En interne, le Core Node Engine orchestre le Tunnels Manager, le moteur de routage Pancake et le Crypto Engine, qui pilotent ensemble le périphérique TUN spécifique à la plateforme.
Core Node
Moteur d'orchestration central avec architecture événementielle utilisant mio pour les E/S asynchrones. Gère les connexions entre pairs, le routage, la planification des messages, les mécanismes de maintien en vie et le basculement des parents.
Système de tunnels
Canaux de communication chiffrés sécurisés de point à point. Modèle de tunnel client-serveur avec cibles de ports TCP/UDP configurables. Chaque tunnel possède une identité cryptographique unique. Les tunnels passerelle relient MCC aux réseaux externes.
Moteur de routage — Pancake
Topologie hiérarchique en arbre avec routage au plus court chemin de Dijkstra et mise en cache du prochain saut. Modèle de relation parent-enfant avec basculement automatique des parents par ordre de priorité. Routage basé sur les propriétés via tags et noms DNS.
Module cryptographique
X25519 ECDH pour l'échange de clés (RFC 7748). ChaCha20-Poly1305 AEAD pour le chiffrement symétrique (RFC 7539). HKDF pour la dérivation de clés (RFC 5869). Ed25519 pour la signature des certificats (RFC 8032). Instances de chiffrement séparées par connexion.
Résolution de noms
Découverte de services basée sur DNS avec identifiants de nœuds encodés en BASE32. Intégration dnsmasq pour le DNS local. Répondeur mDNS pour un réseau sans configuration sous macOS. Nommage basé sur des tags pour le regroupement logique.
Interface de périphérique TUN
Abstraction de périphérique TUN multiplateforme. Implémentations natives pour Linux (linux.rs), macOS (macos.rs via utun) et Android (pont JNI). Windows via WinTUN prévu.
Cinq principes, appliqués par le protocole lui-même.
MCC met en œuvre le réseau Verified-Trust sous forme de code, pas de politique. Chaque principe ci-dessous est appliqué au niveau du paquet — il n'existe aucun panneau d'administration permettant de le désactiver.
Ne jamais faire confiance, toujours vérifier
Chaque paquet nécessite une authentification cryptographique. Il n'existe aucune confiance implicite basée sur l'emplacement réseau ou l'origine de l'appareil.
Accès au moindre privilège
Les tunnels définissent des autorisations explicites de port et de protocole. Un tunnel pour tcp:443 ne peut pas transporter de trafic tcp:5432. Toute utilisation abusive entraîne l'abandon du paquet.
Identité basée sur certificats
Tous les nœuds sont authentifiés via des certificats signés, délivrés dans le cadre d'une hiérarchie de certification contrôlée par l'opérateur du réseau.
Chiffrement de bout en bout
Les données sont chiffrées à la source et déchiffrées uniquement à destination. Les nœuds relais intermédiaires peuvent router mais pas lire.
Segmentation réseau
Les tunnels isolent le trafic entre des points de terminaison spécifiques. Une compromission dans un tunnel n'affecte aucun autre tunnel ou service.
Tunnels : sécurisés cryptographiquement, restreints par port, alignés NIS2.
Un tunnel dans MCC est un canal de communication bidirectionnel sécurisé cryptographiquement entre deux points de terminaison, avec des restrictions explicites de protocole et de port. Chaque tunnel possède une identité de point de terminaison Ed25519 unique, un rôle client ou serveur, et une liste blanche explicite de ports TCP/UDP. Les paquets qui ne correspondent pas sont silencieusement abandonnés. L'architecture facilite la conformité avec la directive européenne NIS2 (2023) et le Cyber Resilience Act européen (2024) en isolant les canaux de communication individuels — empêchant les mouvements latéraux, comme les régulateurs l'attendent désormais pour la construction des infrastructures critiques.
De bout en bout pour le trafic tunnelisé
- Chiffrement des données AEAD ChaCha20-Poly1305
- Clé dérivée de X25519 ECDH (local, distant)
- Clé de tunnel dérivée par HKDF avec sel constant
- Chaque tunnel possède des identifiants de point de terminaison Ed25519 uniques
Protection externe entre les sauts
- Tous les messages RPC (sauf Init/InitAck) chiffrés
- Nonce aléatoire de 12 octets ajouté par message
- Sels aléatoires envoyés dans InitAck (différents par connexion)
- Clés distinctes pour les messages entrants et sortants
La couche tunnel (nonce/sel constant pour la performance) est enveloppée dans la couche RPC (nonce/sel aléatoire par message). La couche externe fournit une protection contre le rejeu, des clés fraîches par session et une double vérification — ainsi, même si le tunnel interne réutilise du matériel cryptographique par souci d'efficacité, la protection externe fait qu'un attaquant récupérant le texte chiffré du tunnel n'a toujours rien à rejouer.
Quatre primitives standardisées par l'IETF. Aucune cryptographie maison.
Chaque opération cryptographique de MCC repose sur un standard RFC évalué par des pairs. Nous utilisons les mêmes primitives qui sécurisent Signal, WireGuard et TLS 1.3.
| Composant | Standard | Référence |
|---|---|---|
| X25519 ECDH | RFC 7748 | Curve25519 — sécurité 128 bits |
| HKDF | RFC 5869 | Dérivation de clés basée sur HMAC |
| ChaCha20-Poly1305 | RFC 7539 | AEAD, ~1,5 Go/s en logiciel seul |
| Signatures Ed25519 | RFC 8032 | EdDSA — utilisé pour les certificats |
Courbe elliptique de dernière génération. Niveau de sécurité de 128 bits (équivalent RSA 3072 bits). L'implémentation à temps constant prévient les attaques temporelles. Utilisé par Signal, WireGuard, TLS 1.3.
Aucune accélération matérielle requise (contrairement à AES-NI). ~1,5 Go/s sur les CPU modernes, encore rapide sur du matériel modeste. Temps constant par conception (résistant aux attaques par timing de cache). Idéal pour les routeurs MIPS-32 et systèmes embarqués.
Maillage hiérarchique, pas de DHT plate. Pancake remplace Kademlia.
MCC met en œuvre une topologie hiérarchique en arbre parent-enfant, optimisée pour les déploiements IoT typiques. L'implémentation actuelle abandonne le maillage plat pour une structure arborescente hiérarchique, car la plupart des réseaux IoT forment naturellement des arbres avec 1 à 2 nœuds racines — et le routage DHT plat (style Kademlia) gaspille la bande passante sur des réseaux qui ne sont pas plats.
- Calcul du plus court chemin de Dijkstra
- Mise en cache du prochain saut pour la performance
- Prévention automatique des boucles
- Basculement des parents par ordre de priorité
- Routage basé sur les propriétés via tags et noms DNS
- Les mises à jour de topologie ne remontent que vers la racine, pas de manière bidirectionnelle
- Élimine la surcharge de scan des DHT plates
- Les mises à jour unidirectionnelles sont plus faciles à raisonner
- Reflète la topologie physique réelle des déploiements MCC typiques
Chaque nœud enfant connaît une liste triée de parents par IP:port. En cas de timeout, il bascule vers le parent suivant de la liste. Il envoie périodiquement un ping aux parents de priorité supérieure — lorsque le parent d'origine revient, l'enfant y retourne. Des messages KeepAlive toutes les 20 secondes maintiennent la connectivité bidirectionnelle à travers le NAT. Les parents ne sont jamais retirés de la topologie (configuration persistante).
Conçu pour les plus petits appareils. Testé sur les plus grands réseaux.
MCC a d'abord été conçu pour les appareils périphériques à ressources limitées. Le même binaire Rust s'exécute sur une Raspberry Pi Zero 2W, un routeur Teltonika RUT956 (128 Mio de RAM) et 12 000 nœuds sur un seul serveur cloud.
- Testé avec des centaines de nœuds
- Goulot d'étranglement du nœud racine : stockage complet de la topologie
- Évolue jusqu'à des milliers par région
- Configurable via le certificat réseau
- Typiquement : 10 à 100 tunnels par nœud
- Chaque tunnel ~2 Ko de surcharge mémoire
- L'architecture événementielle gère des milliers/sec.
- Le transport UDP élimine la surcharge de la poignée de main TCP
- Tolérance à la perte de paquets via une nouvelle tentative au niveau applicatif
Linux, Android, macOS — tous en production. Windows prévu.
Le même noyau Rust s'exécute sur chaque plateforme prise en charge avec des implémentations de périphérique TUN légères et spécifiques à chaque plateforme. Le support Windows est prévu via WinTUN.
| Plateforme | Statut | Fonctionnalités |
|---|---|---|
| Linux | Complet | TUN/TAP, intégration iptables, gestion des capacités (CAP_NET_ADMIN, CAP_NET_RAW), kill switch, redirection de port |
| Android | Complet | Intégration du service VPN, liaisons JNI via mcc-android, résolveur DNS natif, routage basé sur les processus |
| macOS | Complet | Support natif du périphérique TUN, répondeur mDNS pour .local, intégration DNS système |
| Windows | Prévu | TUN/TAP via WinTUN |
- Raspberry Pi 4
- Raspberry Pi Zero 2W
- Intel NUC
- Serveurs cloud (AMD EPYC, Intel Xeon)
amd64, arm64, armhf, armel — paquets DEB, RPM, tar.gz
- Teltonika RUT956
- Teltonika RUT950
- Teltonika RUT200
- Teltonika RUTX50
OpenWRT et dérivés — paquets IPK et tar.gz
Trois scénarios de déploiement. Un protocole. Une flotte en production.
MCC s'adapte à trois topologies de déploiement courantes : IoT industriel avec parents sur site, services distribués entre centres de données, et accès distant pour appareils mobiles. Les trois fonctionnent déjà aujourd'hui.
IoT industriel
- Les appareils périphériques (capteurs, actionneurs) se connectent à un parent sur site
- Le parent sur site se connecte à la racine cloud
- Les tunnels passerelle exposent des services spécifiques (Modbus, OPC-UA)
- Certificat réseau privé pour l'isolation
Services distribués
- Microservices répartis sur plusieurs centres de données
- MCC fournit un réseau overlay sécurisé
- Découverte de services basée sur DNS
- Distribution de certificats SSL pour HTTPS
Accès distant
- Les appareils mobiles se connectent via des nœuds parents publics
- Tunnels vers des services spécifiques (SSH, RDP, VNC)
- Contrôle d'accès basé sur certificats via des listes blanches de tunnels
MIBO — flotte de 150 bus, Rhénanie-du-Nord-Westphalie
MCC est la couche de connectivité qui alimente la flotte de 150 bus de MIBO sur le réseau MINT. La télémétrie signée par le véhicule (nombre de passagers, CO₂, GPS) transite par des tunnels MCC vers une chaîne de données ancrée sur Solana et U2U — de niveau production, prête pour l'audit, chaque jour.
Attestation multi-chaînes
Les identités de nœud MCC peuvent être ancrées sur peaq, ICP, Solana, U2U, Linera, Celo, Hedera, Optimism et Lisk — même protocole, plusieurs racines de confiance. Choisissez la chaîne que vos clients et régulateurs auditent déjà.
Vous souhaitez exécuter MCC ?
MCC est la couche de connectivité sous-jacente à chaque produit Staex — Connectivity, Connect & Transfer (MINT) et l'Agentic Suite. Parlez-nous de son déploiement sur votre propre infrastructure, ou plongez directement dans la documentation.