MCC Protocol
Eine kryptografische Orchestrierungsschicht für Agenten — entwickelt in Rust, abgesichert durch zertifikatsbasierte Verifizierung
MCC ist eine kryptografische Orchestrierungsschicht für Agenten und ein in Rust implementiertes Trusted-Execution-Agent-Framework. Die Plattform ermöglicht sichere Peer-to-Peer-Kommunikation über verteilte Netzwerke hinweg — mit zertifikatsbasierter Sicherheit und Ende-zu-Ende-Verschlüsselung. MCC ist konzipiert für IoT-Geräte, industrielle Netzwerke und autonome KI-Agentensysteme, die sichere, latenzarme Kommunikation ohne zentrale Infrastruktur benötigen.
Sechs Eigenschaften, die MCC von einem VPN oder Service Mesh unterscheiden.
Jede architektonische Entscheidung in MCC lässt sich auf eines dieser sechs Ziele zurückführen. Keine Marketing-Versprechen, keine vagen Zusagen — nur die Eigenschaften, die das Protokoll tatsächlich durchsetzt.
Verified-Trust-Architektur
Ein Trusted-Execution-Agent-Framework, bei dem jede Verbindung eine kryptografische Verifizierung erfordert. Kein Paket bewegt sich ohne explizite Identität, signiertes Zertifikat und passende Tunnelkonfiguration.
Ende-zu-Ende-Verschlüsselung
ChaCha20-Poly1305-AEAD-Verschlüsselung für den gesamten Traffic. Doppelt verschlüsselt: Tunnel-Ebene + RPC-Ebene. Selbst kompromittierte Zwischenknoten können Ihre Daten nicht lesen.
Multi-Plattform-Unterstützung
Native TUN/TAP-Integration unter Linux, Android und macOS. Windows-Unterstützung über WinTUN geplant. Derselbe Rust-Kern überall.
Ressourceneffizient
Optimiert für eingebettete Systeme und ressourcenbeschränkte Geräte. Basisknoten nutzt ~10 MB Arbeitsspeicher. Idle-CPU unter 1 %. Läuft auf MIPS-32-Routern.
Zertifikatsbasierte Authentifizierung
X25519-Elliptic-Curve-Schlüsselaustausch mit Ed25519-signierten Zertifikaten. Dreistufige Hierarchie: Zertifizierungsstelle → Netzwerkzertifikate → Knoten- & Tunnelzertifikate.
Hierarchische Mesh-Topologie
Baumbasiertes Parent-Child-Routing, optimiert für typische IoT-Deployments. Pancake-Routing-Engine mit Dijkstra-Kürzestwegberechnung und Next-Hop-Caching.
Sechs Kernmodule. Eine Rust-Binärdatei.
MCC wird als einzelne Rust-Binärdatei ausgeliefert, die eine Web-UI (Vue.js), eine REST-API (Axum) und eine Unix-Socket-API bereitstellt. Intern orchestriert die Core Node Engine den Tunnels Manager, die Pancake-Routing-Engine und die Crypto Engine, die gemeinsam das plattformspezifische TUN-Gerät ansteuern.
Core Node
Zentrale Orchestrierungs-Engine mit ereignisgesteuerter Architektur, die mio für asynchrone I/O nutzt. Verwaltet Peer-Verbindungen, Routing, Nachrichtenplanung, Keep-Alive-Mechanismen und Parent-Failover.
Tunnel-System
Sichere, verschlüsselte Kommunikationskanäle zwischen zwei Endpunkten. Client-Server-Tunnelmodell mit konfigurierbaren TCP/UDP-Portzielen. Jeder Tunnel besitzt eine eindeutige kryptografische Identität. Gateway-Tunnel verbinden MCC mit externen Netzwerken.
Routing-Engine — Pancake
Hierarchische, baumbasierte Topologie mit Dijkstra-Kürzestwegroutung und Next-Hop-Caching. Parent-Child-Beziehungsmodell mit automatischem Parent-Failover nach Prioritätsreihenfolge. Eigenschaftsbasiertes Routing über Tags und DNS-Namen.
Kryptografiemodul
X25519-ECDH für Schlüsselaustausch (RFC 7748). ChaCha20-Poly1305-AEAD für symmetrische Verschlüsselung (RFC 7539). HKDF für Schlüsselableitung (RFC 5869). Ed25519 für Zertifikatssignaturen (RFC 8032). Separate Chiffrier-Instanzen pro Verbindung.
Namensauflösung
DNS-basierte Service-Discovery mit BASE32-kodierten Knoten-IDs. dnsmasq-Integration für lokales DNS. mDNS-Responder für Zero-Configuration-Networking unter macOS. Tag-basierte Benennung für logische Gruppierung.
TUN-Geräte-Schnittstelle
Plattformübergreifende TUN-Geräteabstraktion. Native Implementierungen für Linux (linux.rs), macOS (macos.rs über utun) und Android (JNI-Bridge). Windows über WinTUN geplant.
Fünf Prinzipien, durchgesetzt vom Protokoll selbst.
MCC implementiert Verified-Trust-Networking als Code, nicht als Richtlinie. Jedes Prinzip unten wird auf Paketebene durchgesetzt — es gibt kein Admin-Panel, um es zu deaktivieren.
Niemals vertrauen, immer verifizieren
Jedes Paket erfordert kryptografische Authentifizierung. Es gibt kein implizites Vertrauen basierend auf Netzwerkstandort oder Geräteherkunft.
Zugriff nach dem Prinzip der geringsten Rechte
Tunnel definieren explizite Port- und Protokollberechtigungen. Ein Tunnel für tcp:443 kann keinen tcp:5432-Traffic transportieren. Missbrauch verwirft das Paket.
Zertifikatsbasierte Identität
Alle Knoten werden über signierte Zertifikate authentifiziert, die im Rahmen einer vom Netzwerkbetreiber kontrollierten Zertifikatshierarchie ausgestellt werden.
Ende-zu-Ende-Verschlüsselung
Daten werden an der Quelle verschlüsselt und erst am Ziel entschlüsselt. Zwischengeschaltete Relay-Knoten können weiterleiten, aber nicht lesen.
Netzwerksegmentierung
Tunnel isolieren den Traffic zwischen bestimmten Endpunkten. Eine Kompromittierung in einem Tunnel wirkt sich auf keinen anderen Tunnel oder Dienst aus.
Tunnel: kryptografisch gesichert, portbeschränkt, NIS2-konform.
Ein Tunnel in MCC ist ein kryptografisch gesicherter, bidirektionaler Kommunikationskanal zwischen zwei Endpunkten mit expliziten Protokoll- und Portbeschränkungen. Jeder Tunnel besitzt eine eindeutige Ed25519-Endpunktidentität, eine Client- oder Server-Rolle und eine explizite TCP/UDP-Port-Whitelist. Pakete, die nicht übereinstimmen, werden stillschweigend verworfen. Die Architektur unterstützt die Einhaltung der EU-NIS2-Richtlinie (2023) und des EU Cyber Resilience Act (2024), indem sie einzelne Kommunikationskanäle isoliert — und so laterale Bewegungen verhindert, so wie Regulierungsbehörden es heute für kritische Infrastruktur erwarten.
Ende-zu-Ende für getunnelten Traffic
- ChaCha20-Poly1305-AEAD-Nutzdatenverschlüsselung
- Schlüssel abgeleitet aus X25519-ECDH (lokal, remote)
- HKDF-abgeleiteter Tunnelschlüssel mit konstantem Salt
- Jeder Tunnel besitzt eindeutige Ed25519-Endpunkt-IDs
Äußerer Schutz zwischen Hops
- Alle RPC-Nachrichten (außer Init/InitAck) verschlüsselt
- Zufälliger 12-Byte-Nonce pro Nachricht vorangestellt
- Zufällige Salts in InitAck gesendet (pro Verbindung unterschiedlich)
- Getrennte Schlüssel für eingehende und ausgehende Nachrichten
Die Tunnel-Ebene (konstanter Nonce/Salt aus Performancegründen) ist in die RPC-Ebene (zufälliger Nonce/Salt pro Nachricht) eingebettet. Die äußere Ebene bietet Replay-Schutz, frische Schlüssel pro Sitzung und doppelte Verifizierung — sodass ein Angreifer, der Tunnel-Chiffretext erbeutet, trotz der aus Effizienzgründen wiederverwendeten kryptografischen Materialien der inneren Ebene nichts zum Wiedereinspielen in der Hand hat.
Vier IETF-standardisierte Primitiven. Keine hausgemachte Kryptografie.
Jede kryptografische Operation in MCC basiert auf einem peer-reviewten RFC-Standard. Wir verwenden dieselben Primitiven, die Signal, WireGuard und TLS 1.3 absichern.
| Komponente | Standard | Referenz |
|---|---|---|
| X25519 ECDH | RFC 7748 | Curve25519 — 128-Bit-Sicherheit |
| HKDF | RFC 5869 | HMAC-basierte Schlüsselableitung |
| ChaCha20-Poly1305 | RFC 7539 | AEAD, ~1,5 GB/s reine Softwareimplementierung |
| Ed25519-Signaturen | RFC 8032 | EdDSA — verwendet für Zertifikate |
Aktueller Stand der Technik bei elliptischen Kurven. Sicherheitsniveau von 128 Bit (entspricht 3072-Bit-RSA). Zeitkonstante Implementierung verhindert Timing-Angriffe. Verwendet von Signal, WireGuard, TLS 1.3.
Keine Hardwarebeschleunigung erforderlich (im Gegensatz zu AES-NI). ~1,5 GB/s auf modernen CPUs, weiterhin schnell auf schwacher Hardware. Zeitkonstant per Design (resistent gegen Cache-Timing-Angriffe). Ideal für MIPS-32-Router und eingebettete Systeme.
Hierarchisches Mesh statt flacher DHT. Pancake ersetzt Kademlia.
MCC implementiert eine hierarchische Parent-Child-Baumtopologie, optimiert für typische IoT-Deployments. Die aktuelle Implementierung verzichtet auf ein flaches Mesh zugunsten einer hierarchischen Baumstruktur, da die meisten IoT-Netzwerke natürlich Bäume mit 1–2 Root-Knoten bilden — und flaches DHT-Routing (Kademlia-Stil) Bandbreite in Netzwerken verschwendet, die nicht flach sind.
- Dijkstra-Kürzestwegberechnung
- Next-Hop-Caching für Performance
- Automatische Schleifenvermeidung
- Parent-Failover nach Prioritätsreihenfolge
- Eigenschaftsbasiertes Routing über Tags und DNS-Namen
- Topologie-Updates fließen nur nach oben zum Root, nicht bidirektional
- Eliminiert den Scan-Overhead flacher DHTs
- Updates in eine Richtung sind einfacher nachzuvollziehen
- Spiegelt die tatsächliche physische Topologie typischer MCC-Deployments wider
Jeder Child-Knoten kennt eine nach IP:Port sortierte Liste von Parents. Bei Timeout wechselt er zum nächsten Parent in der Liste. Er pingt periodisch höher priorisierte Parents an — kommt der ursprüngliche Parent zurück, wechselt der Child-Knoten wieder zurück. KeepAlive-Nachrichten alle 20 Sekunden erhalten die bidirektionale Konnektivität durch NAT. Parents werden nie aus der Topologie entfernt (persistente Konfiguration).
Entwickelt für die kleinsten Geräte. Getestet auf den größten Netzwerken.
MCC wurde zunächst für ressourcenbeschränkte Edge-Geräte entwickelt. Dieselbe Rust-Binärdatei läuft auf einem Raspberry Pi Zero 2W, einem Teltonika-RUT956-Router (128 MiB RAM) und 12.000 Knoten auf einem einzigen Cloud-Server.
- Getestet mit Hunderten von Knoten
- Root-Knoten-Engpass: vollständige Topologiespeicherung
- Skaliert auf Tausende pro Region
- Konfigurierbar über Netzwerkzertifikat
- Typisch: 10–100 Tunnel pro Knoten
- Jeder Tunnel ~2 KB Speicher-Overhead
- Ereignisgesteuerte Architektur verarbeitet Tausende/Sek.
- UDP-Transport eliminiert TCP-Handshake-Overhead
- Paketverlusttoleranz durch Retry auf Anwendungsebene
Linux, Android, macOS — alle produktionsreif. Windows geplant.
Derselbe Rust-Kern läuft auf jeder unterstützten Plattform mit schlanken, plattformspezifischen TUN-Geräteimplementierungen. Windows-Unterstützung ist über WinTUN geplant.
| Plattform | Status | Merkmale |
|---|---|---|
| Linux | Vollständig | TUN/TAP, iptables-Integration, Capability-Management (CAP_NET_ADMIN, CAP_NET_RAW), Kill Switch, Portumleitung |
| Android | Vollständig | VPN-Service-Integration, JNI-Bindings über mcc-android, nativer DNS-Resolver, prozessbasiertes Routing |
| macOS | Vollständig | Native TUN-Geräteunterstützung, mDNS-Responder für .local, System-DNS-Integration |
| Windows | Geplant | TUN/TAP über WinTUN |
- Raspberry Pi 4
- Raspberry Pi Zero 2W
- Intel NUC
- Cloud-Server (AMD EPYC, Intel Xeon)
amd64, arm64, armhf, armel — DEB-, RPM-, tar.gz-Pakete
- Teltonika RUT956
- Teltonika RUT950
- Teltonika RUT200
- Teltonika RUTX50
OpenWRT und Derivate — IPK- und tar.gz-Pakete
Drei Deployment-Szenarien. Ein Protokoll. Eine Produktionsflotte.
MCC passt zu drei gängigen Deployment-Topologien: industrielles IoT mit lokalen Parents, verteilte Services über Rechenzentren hinweg und Fernzugriff für mobile Geräte. Alle drei sind bereits heute im Einsatz.
Industrielles IoT
- Edge-Geräte (Sensoren, Aktuatoren) verbinden sich mit lokalem Parent
- Lokaler Parent verbindet sich mit Cloud-Root
- Gateway-Tunnel legen bestimmte Dienste offen (Modbus, OPC-UA)
- Privates Netzwerkzertifikat zur Isolierung
Verteilte Services
- Microservices über mehrere Rechenzentren hinweg
- MCC stellt ein sicheres Overlay-Netzwerk bereit
- DNS-basierte Service-Discovery
- SSL-Zertifikatsverteilung für HTTPS
Fernzugriff
- Mobile Geräte verbinden sich über öffentliche Parent-Knoten
- Tunnel zu bestimmten Diensten (SSH, RDP, VNC)
- Zertifikatsbasierte Zugriffskontrolle über Tunnel-Whitelists
MIBO — 150-Busse-Flotte, Nordrhein-Westfalen
MCC ist die Konnektivitätsschicht, die die 150-Busse-Flotte von MIBO im MINT-Netzwerk antreibt. Fahrzeugsignierte Telemetriedaten (Fahrgastzahl, CO₂, GPS) fließen über MCC-Tunnel in eine auf Solana & U2U verankerte Datenkette — produktionsreif, auditbereit, jeden Tag.
Multi-Chain-Attestierung
MCC-Knotenidentitäten können auf peaq, ICP, Solana, U2U, Linera, Celo, Hedera, Optimism und Lisk verankert werden — dasselbe Protokoll, mehrere Vertrauensanker. Wählen Sie die Chain, die Ihre Kunden und Regulierungsbehörden bereits prüfen.
MCC einsetzen?
MCC ist die Konnektivitätsschicht unter jedem Staex-Produkt — Connectivity, Connect & Transfer (MINT) und der Agentic Suite. Sprechen Sie mit uns über den Einsatz auf Ihrer eigenen Infrastruktur, oder tauchen Sie direkt in die Dokumentation ein.