MCC Protocol
Una capa de orquestación criptográfica para agentes, desarrollada en Rust y protegida mediante verificación basada en certificados
MCC es una capa de orquestación criptográfica para agentes y un marco de agentes de ejecución confiable implementado en Rust. La plataforma permite la comunicación segura entre pares en redes distribuidas mediante seguridad basada en certificados con cifrado de extremo a extremo. MCC está diseñado para dispositivos IoT, redes industriales y sistemas de agentes de IA autónomos que requieren comunicación segura y de baja latencia sin depender de infraestructura centralizada.
Seis propiedades que hacen que MCC sea distinto de una VPN o de un service mesh.
Cada decisión arquitectónica de MCC se puede rastrear hasta uno de estos seis objetivos. Sin afirmaciones de marketing, sin promesas vagas: solo las propiedades que el protocolo realmente aplica.
Arquitectura de Confianza Verificada
Un marco de agentes de ejecución confiable donde cada conexión requiere verificación criptográfica. Ningún paquete se mueve sin identidad explícita, certificado firmado y configuración de túnel coincidente.
Cifrado de Extremo a Extremo
Cifrado AEAD ChaCha20-Poly1305 para todo el tráfico. Doblemente cifrado: capa de túnel + capa RPC. Ni siquiera los nodos intermedios comprometidos pueden leer sus datos.
Compatibilidad Multiplataforma
Integración nativa TUN/TAP en Linux, Android y macOS. Soporte para Windows planificado vía WinTUN. El mismo núcleo en Rust en todas partes.
Eficiente en Recursos
Optimizado para sistemas embebidos y dispositivos con recursos limitados. Un nodo base utiliza ~10 MB de memoria. CPU en reposo por debajo del 1 %. Funciona en routers MIPS-32.
Autenticación Basada en Certificados
Intercambio de claves de curva elíptica X25519 con certificados firmados con Ed25519. Jerarquía de tres niveles: Autoridad de Certificación → Certificados de Red → Certificados de Nodo y Túnel.
Topología de Malla Jerárquica
Enrutamiento jerárquico padre-hijo basado en árbol, optimizado para implementaciones IoT típicas. Motor de enrutamiento Pancake con cálculo de ruta más corta de Dijkstra y almacenamiento en caché del siguiente salto.
Seis módulos centrales. Un solo binario en Rust.
MCC se distribuye como un único binario en Rust que expone una interfaz web (Vue.js), una API REST (Axum) y una API de socket Unix. Internamente, el Core Node Engine orquesta el Tunnels Manager, el motor de enrutamiento Pancake y el Crypto Engine, que juntos controlan el dispositivo TUN específico de la plataforma.
Core Node
Motor de orquestación central con arquitectura basada en eventos que utiliza mio para E/S asíncrona. Gestiona conexiones entre pares, enrutamiento, programación de mensajes, mecanismos de keep-alive y conmutación por error del nodo padre.
Sistema de Túneles
Canales de comunicación cifrados y seguros de extremo a extremo. Modelo de túnel cliente-servidor con destinos de puerto TCP/UDP configurables. Cada túnel tiene una identidad criptográfica única. Los túneles gateway conectan MCC con redes externas.
Motor de Enrutamiento — Pancake
Topología jerárquica basada en árbol con enrutamiento de ruta más corta de Dijkstra y almacenamiento en caché del siguiente salto. Modelo de relación padre-hijo con conmutación por error automática del nodo padre por orden de prioridad. Enrutamiento basado en propiedades mediante etiquetas y nombres DNS.
Módulo de Criptografía
X25519 ECDH para el intercambio de claves (RFC 7748). AEAD ChaCha20-Poly1305 para el cifrado simétrico (RFC 7539). HKDF para la derivación de claves (RFC 5869). Ed25519 para la firma de certificados (RFC 8032). Instancias de cifrado independientes por conexión.
Resolución de Nombres
Descubrimiento de servicios basado en DNS mediante IDs de nodo codificados en BASE32. Integración con dnsmasq para DNS local. Respondedor mDNS para redes de configuración cero en macOS. Nomenclatura basada en etiquetas para agrupación lógica.
Interfaz de Dispositivo TUN
Abstracción de dispositivo TUN multiplataforma. Implementaciones nativas para Linux (linux.rs), macOS (macos.rs vía utun) y Android (puente JNI). Windows vía WinTUN planificado.
Cinco principios, aplicados por el propio protocolo.
MCC implementa el modelo de redes de confianza verificada como código, no como política. Cada principio a continuación se aplica a nivel de paquete: no existe un panel de administración donde se pueda desactivar.
Nunca Confiar, Siempre Verificar
Cada paquete requiere autenticación criptográfica. No existe confianza implícita basada en la ubicación de la red o el origen del dispositivo.
Acceso con Privilegio Mínimo
Los túneles definen permisos explícitos de puerto y protocolo. Un túnel para tcp:443 no puede transportar tráfico tcp:5432. El uso indebido descarta el paquete.
Identidad Basada en Certificados
Todos los nodos se autentican mediante certificados firmados, emitidos bajo una jerarquía de certificación controlada por el operador de la red.
Cifrado de Extremo a Extremo
Los datos se cifran en el origen y se descifran únicamente en el destino. Los nodos de retransmisión intermedios pueden enrutar, pero no pueden leer.
Segmentación de Red
Los túneles aíslan el tráfico entre puntos finales específicos. Una vulneración en un túnel no afecta a ningún otro túnel ni servicio.
Túneles: protegidos criptográficamente, restringidos por puerto, alineados con NIS2.
Un túnel en MCC es un canal de comunicación bidireccional protegido criptográficamente entre dos puntos finales, con restricciones explícitas de protocolo y puerto. Cada túnel tiene una identidad de punto final Ed25519 única, un rol de cliente o servidor, y una lista blanca explícita de puertos TCP/UDP. Los paquetes que no coinciden se descartan silenciosamente. La arquitectura contribuye al cumplimiento de la Directiva NIS2 de la UE (2023) y la Ley de Ciberresiliencia de la UE (CRA, 2024) al aislar los canales de comunicación individuales, evitando el movimiento lateral, tal como los reguladores esperan hoy que se construya la infraestructura crítica.
Extremo a extremo para el tráfico tunelizado
- Cifrado AEAD ChaCha20-Poly1305 de la carga útil
- Clave derivada de X25519 ECDH (local, remoto)
- Clave de túnel derivada con HKDF con salt constante
- Cada túnel tiene IDs de punto final Ed25519 únicos
Protección externa entre saltos
- Todos los mensajes RPC (excepto Init/InitAck) cifrados
- Nonce aleatorio de 12 bytes antepuesto por mensaje
- Salts aleatorios enviados en InitAck (distintos por conexión)
- Claves separadas para mensajes entrantes y salientes
La capa de túnel (nonce/salt constante por rendimiento) se envuelve dentro de la capa RPC (nonce/salt aleatorio por mensaje). La capa externa proporciona protección contra repetición, claves nuevas por sesión y doble verificación, de modo que, aunque el túnel interno reutiliza material criptográfico por eficiencia, la protección externa hace que un atacante que recupere el texto cifrado del túnel no tenga nada que repetir.
Cuatro primitivas estandarizadas por el IETF. Sin criptografía propia.
Cada operación criptográfica en MCC se basa en un estándar RFC revisado por pares. Utilizamos las mismas primitivas que protegen Signal, WireGuard y TLS 1.3.
| Componente | Estándar | Referencia |
|---|---|---|
| X25519 ECDH | RFC 7748 | Curve25519 — seguridad de 128 bits |
| HKDF | RFC 5869 | Derivación de claves basada en HMAC |
| ChaCha20-Poly1305 | RFC 7539 | AEAD, ~1,5 GB/s solo por software |
| Firmas Ed25519 | RFC 8032 | EdDSA — utilizado para certificados |
Curva elíptica más avanzada actualmente. Nivel de seguridad de 128 bits (equivalente a RSA de 3072 bits). La implementación de tiempo constante evita ataques de temporización. Utilizada por Signal, WireGuard y TLS 1.3.
No requiere aceleración por hardware (a diferencia de AES-NI). ~1,5 GB/s en CPU modernas, y sigue siendo rápido en hardware limitado. De tiempo constante por diseño (resistente a ataques de temporización de caché). Ideal para routers MIPS-32 y sistemas embebidos.
Malla jerárquica, no DHT plana. Pancake reemplaza a Kademlia.
MCC implementa una topología de árbol jerárquico padre-hijo, optimizada para implementaciones IoT típicas. La implementación actual abandona la malla plana en favor de una estructura de árbol jerárquico, porque la mayoría de las redes IoT forman naturalmente árboles con 1 o 2 nodos raíz, y el enrutamiento DHT plano (estilo Kademlia) desperdicia ancho de banda en redes que no son planas.
- Cálculo de ruta más corta de Dijkstra
- Almacenamiento en caché del siguiente salto para mejor rendimiento
- Prevención automática de bucles
- Conmutación por error del nodo padre por orden de prioridad
- Enrutamiento basado en propiedades mediante etiquetas y nombres DNS
- Las actualizaciones de topología fluyen solo hacia arriba, hasta la raíz, no de forma bidireccional
- Elimina la sobrecarga de escaneo de las DHT planas
- Las actualizaciones unidireccionales son más fáciles de razonar
- Refleja la topología física real de las implementaciones típicas de MCC
Cada nodo hijo conoce una lista ordenada de nodos padre por IP:puerto. Al agotarse el tiempo de espera, cambia al siguiente padre de la lista. Hace ping periódicamente a los padres de mayor prioridad; cuando el padre original vuelve a estar disponible, el hijo regresa a él. Los mensajes KeepAlive cada 20 segundos mantienen la conectividad bidireccional a través de NAT. Los padres nunca se eliminan de la topología (configuración persistente).
Diseñado para los dispositivos más pequeños. Probado en las redes más grandes.
MCC fue diseñado primero para dispositivos edge con recursos limitados. El mismo binario en Rust funciona en una Raspberry Pi Zero 2W, un router Teltonika RUT956 (128 MiB de RAM) y 12.000 nodos en un solo servidor en la nube.
- Probado con cientos de nodos
- Cuello de botella del nodo raíz: almacenamiento de la topología completa
- Escala a miles por región
- Configurable mediante el certificado de red
- Típico: entre 10 y 100 túneles por nodo
- Cada túnel supone ~2 KB de sobrecarga de memoria
- La arquitectura basada en eventos maneja miles por segundo
- El transporte UDP elimina la sobrecarga del handshake TCP
- Tolerancia a pérdida de paquetes mediante reintentos a nivel de aplicación
Linux, Android, macOS: todas en producción. Windows planificado.
El mismo núcleo en Rust funciona en todas las plataformas compatibles, con implementaciones de dispositivo TUN específicas y ligeras para cada una. El soporte para Windows está planificado mediante WinTUN.
| Plataforma | Estado | Características |
|---|---|---|
| Linux | Completo | TUN/TAP, integración con iptables, gestión de capacidades (CAP_NET_ADMIN, CAP_NET_RAW), kill switch, redirección de puertos |
| Android | Completo | Integración con el servicio VPN, bindings JNI vía mcc-android, resolutor DNS nativo, enrutamiento basado en procesos |
| macOS | Completo | Soporte nativo de dispositivo TUN, respondedor mDNS para .local, integración con el DNS del sistema |
| Windows | Planificado | TUN/TAP vía WinTUN |
- Raspberry Pi 4
- Raspberry Pi Zero 2W
- Intel NUC
- Servidores en la nube (AMD EPYC, Intel Xeon)
amd64, arm64, armhf, armel — paquetes DEB, RPM, tar.gz
- Teltonika RUT956
- Teltonika RUT950
- Teltonika RUT200
- Teltonika RUTX50
OpenWRT y derivados — paquetes IPK y tar.gz
Tres escenarios de implementación. Un protocolo. Una flota en producción.
MCC se adapta a tres topologías de implementación comunes: IoT industrial con nodos padre en las instalaciones, servicios distribuidos entre centros de datos, y acceso remoto para dispositivos móviles. Los tres están en funcionamiento hoy.
IoT Industrial
- Los dispositivos edge (sensores, actuadores) se conectan a un nodo padre local
- El nodo padre local se conecta a la raíz en la nube
- Los túneles gateway exponen servicios específicos (Modbus, OPC-UA)
- Certificado de red privado para aislamiento
Servicios Distribuidos
- Microservicios en múltiples centros de datos
- MCC ofrece una red superpuesta segura
- Descubrimiento de servicios basado en DNS
- Distribución de certificados SSL para HTTPS
Acceso Remoto
- Los dispositivos móviles se conectan a través de nodos padre públicos
- Túneles hacia servicios específicos (SSH, RDP, VNC)
- Control de acceso basado en certificados mediante listas blancas de túneles
MIBO — flota de 150 autobuses, Renania del Norte-Westfalia
MCC es la capa de conectividad que impulsa la flota de 150 autobuses de MIBO en la red MINT. La telemetría firmada por el vehículo (conteo de pasajeros, CO₂, GPS) fluye a través de túneles MCC hacia una cadena de datos anclada en Solana y U2U: de nivel de producción, lista para auditoría, todos los días.
Certificación multicadena
Las identidades de nodo de MCC pueden anclarse en peaq, ICP, Solana, U2U, Linera, Celo, Hedera, Optimism y Lisk: mismo protocolo, múltiples raíces de confianza. Elija la cadena que sus clientes y reguladores ya auditan.
¿Quiere ejecutar MCC?
MCC es la capa de conectividad que sustenta todos los productos de Staex: Connectivity, Connect & Transfer (MINT) y el Agentic Suite. Hable con nosotros sobre cómo implementarlo en su propia infraestructura, o entre directamente en la documentación.