MCC Protocol
Uma camada de orquestração criptográfica para agentes — construída em Rust, protegida por verificação baseada em certificados
O MCC é uma camada de orquestração criptográfica para agentes e uma estrutura Trusted Execution Agent implementada em Rust. A plataforma permite comunicação peer-to-peer segura em redes distribuídas, utilizando segurança baseada em certificados com encriptação de ponta a ponta. O MCC foi concebido para dispositivos IoT, redes industriais e sistemas de agentes de IA autónomos que requerem comunicação segura e de baixa latência, sem depender de infraestrutura centralizada.
Seis propriedades que distinguem o MCC de uma VPN ou service mesh.
Cada decisão arquitetónica do MCC é rastreável até um destes seis objetivos. Sem afirmações de marketing, sem promessas vagas — apenas as propriedades que o protocolo efetivamente impõe.
Arquitetura Verified-Trust
Uma estrutura Trusted Execution Agent onde cada ligação requer verificação criptográfica. Nenhum pacote circula sem identidade explícita, certificado assinado e configuração de túnel correspondente.
Encriptação de ponta a ponta
Encriptação AEAD ChaCha20-Poly1305 para todo o tráfego. Duplamente encriptado: camada de túnel + camada RPC. Mesmo nós intermédios comprometidos não conseguem ler os seus dados.
Suporte multiplataforma
Integração nativa TUN/TAP no Linux, Android e macOS. Suporte para Windows planeado via WinTUN. O mesmo núcleo Rust em todo o lado.
Eficiente em recursos
Otimizado para sistemas embarcados e dispositivos com recursos limitados. Um nó base utiliza ~10 MB de memória. CPU em repouso abaixo de 1 %. Funciona em routers MIPS-32.
Autenticação baseada em certificados
Troca de chaves em curva elítica X25519 com certificados assinados por Ed25519. Hierarquia de três níveis: autoridade certificadora → certificados de rede → certificados de nó e túnel.
Topologia em malha hierárquica
Encaminhamento parent-child baseado em árvore, otimizado para implementações IoT típicas. Motor de encaminhamento Pancake com cálculo de caminho mais curto de Dijkstra e cache do próximo salto.
Seis módulos centrais. Um único binário Rust.
O MCC é distribuído como um único binário Rust que expõe uma interface web (Vue.js), uma API REST (Axum) e uma API de socket Unix. Internamente, o Core Node Engine orquestra o Tunnels Manager, o motor de encaminhamento Pancake e o Crypto Engine, que em conjunto controlam o dispositivo TUN específico da plataforma.
Core Node
Motor de orquestração central com arquitetura orientada a eventos, utilizando mio para I/O assíncrono. Gere ligações entre pares, encaminhamento, agendamento de mensagens, mecanismos de keep-alive e failover de parent.
Sistema de túneis
Canais de comunicação seguros e encriptados de ponto a ponto. Modelo de túnel cliente-servidor com destinos de porta TCP/UDP configuráveis. Cada túnel tem uma identidade criptográfica única. Túneis gateway ligam o MCC a redes externas.
Motor de encaminhamento — Pancake
Topologia hierárquica baseada em árvore, com encaminhamento de caminho mais curto de Dijkstra e cache do próximo salto. Modelo de relação parent-child com failover automático de parent por ordem de prioridade. Encaminhamento baseado em propriedades através de tags e nomes DNS.
Módulo de criptografia
X25519 ECDH para troca de chaves (RFC 7748). ChaCha20-Poly1305 AEAD para encriptação simétrica (RFC 7539). HKDF para derivação de chaves (RFC 5869). Ed25519 para assinatura de certificados (RFC 8032). Instâncias de cifra separadas por ligação.
Resolução de nomes
Descoberta de serviços baseada em DNS, utilizando IDs de nó codificados em BASE32. Integração com dnsmasq para DNS local. Respondedor mDNS para redes sem configuração no macOS. Nomenclatura baseada em tags para agrupamento lógico.
Interface de dispositivo TUN
Abstração de dispositivo TUN multiplataforma. Implementações nativas para Linux (linux.rs), macOS (macos.rs via utun) e Android (ponte JNI). Windows via WinTUN planeado.
Cinco princípios, impostos pelo próprio protocolo.
O MCC implementa a rede Verified-Trust como código, não como política. Cada princípio abaixo é imposto ao nível do pacote — não existe um painel de administração onde o possa desativar.
Nunca confiar, sempre verificar
Cada pacote requer autenticação criptográfica. Não existe confiança implícita baseada na localização de rede ou na origem do dispositivo.
Acesso de privilégio mínimo
Os túneis definem permissões explícitas de porta e protocolo. Um túnel para tcp:443 não pode transportar tráfego tcp:5432. O uso indevido descarta o pacote.
Identidade baseada em certificados
Todos os nós são autenticados através de certificados assinados, emitidos ao abrigo de uma hierarquia de certificação controlada pelo operador da rede.
Encriptação de ponta a ponta
Os dados são encriptados na origem e apenas desencriptados no destino. Os nós de retransmissão intermédios podem encaminhar, mas não conseguem ler.
Segmentação de rede
Os túneis isolam o tráfego entre pontos finais específicos. Um comprometimento num túnel não afeta qualquer outro túnel ou serviço.
Túneis: protegidos criptograficamente, restritos por porta, alinhados com a NIS2.
Um túnel no MCC é um canal de comunicação bidirecional protegido criptograficamente entre dois pontos finais, com restrições explícitas de protocolo e porta. Cada túnel possui uma identidade de ponto final Ed25519 única, um papel de cliente ou servidor, e uma lista branca explícita de portas TCP/UDP. Os pacotes que não correspondem são silenciosamente descartados. A arquitetura facilita a conformidade com a Diretiva NIS2 da UE (2023) e o Cyber Resilience Act da UE (2024), isolando canais de comunicação individuais — impedindo o movimento lateral, tal como os reguladores esperam atualmente que as infraestruturas críticas sejam construídas.
Ponta a ponta para o tráfego tunelizado
- Encriptação de dados AEAD ChaCha20-Poly1305
- Chave derivada de X25519 ECDH (local, remoto)
- Chave de túnel derivada por HKDF com salt constante
- Cada túnel tem IDs de ponto final Ed25519 únicos
Proteção externa entre saltos
- Todas as mensagens RPC (exceto Init/InitAck) encriptadas
- Nonce aleatório de 12 bytes prefixado por mensagem
- Salts aleatórios enviados no InitAck (diferentes por ligação)
- Chaves separadas para mensagens de entrada e saída
A camada de túnel (nonce/salt constante por motivos de desempenho) está envolvida dentro da camada RPC (nonce/salt aleatório por mensagem). A camada externa proporciona proteção contra replay, chaves novas por sessão e dupla verificação — assim, mesmo que o túnel interno reutilize material criptográfico por eficiência, a proteção externa faz com que um atacante que recupere o texto cifrado do túnel continue sem nada para reproduzir.
Quatro primitivas padronizadas pela IETF. Sem criptografia caseira.
Cada operação criptográfica no MCC assenta numa norma RFC revista por pares. Utilizamos as mesmas primitivas que protegem o Signal, o WireGuard e o TLS 1.3.
| Componente | Norma | Referência |
|---|---|---|
| X25519 ECDH | RFC 7748 | Curve25519 — segurança de 128 bits |
| HKDF | RFC 5869 | Derivação de chaves baseada em HMAC |
| ChaCha20-Poly1305 | RFC 7539 | AEAD, ~1,5 GB/s apenas em software |
| Assinaturas Ed25519 | RFC 8032 | EdDSA — utilizado para certificados |
Estado da arte atual em curvas elíticas. Nível de segurança de 128 bits (equivalente a RSA de 3072 bits). A implementação em tempo constante previne ataques de temporização. Utilizado por Signal, WireGuard, TLS 1.3.
Não requer aceleração por hardware (ao contrário do AES-NI). ~1,5 GB/s em CPUs modernos, ainda rápido em hardware modesto. Tempo constante por conceção (resistente a ataques de temporização de cache). Ideal para routers MIPS-32 e sistemas embarcados.
Malha hierárquica, não DHT plana. O Pancake substitui o Kademlia.
O MCC implementa uma topologia hierárquica em árvore parent-child, otimizada para implementações IoT típicas. A implementação atual abandona a malha plana em favor de uma estrutura em árvore hierárquica, porque a maioria das redes IoT forma naturalmente árvores com 1 a 2 nós raiz — e o encaminhamento DHT plano (estilo Kademlia) desperdiça largura de banda em redes que não são planas.
- Cálculo de caminho mais curto de Dijkstra
- Cache do próximo salto para desempenho
- Prevenção automática de ciclos
- Failover de parent por ordem de prioridade
- Encaminhamento baseado em propriedades através de tags e nomes DNS
- As atualizações de topologia fluem apenas para cima, em direção à raiz, não bidirecionalmente
- Elimina a sobrecarga de pesquisa das DHTs planas
- As atualizações unidirecionais são mais fáceis de compreender
- Reflete a topologia física real das implementações MCC típicas
Cada nó filho conhece uma lista ordenada de parents por IP:porta. Em caso de timeout, muda para o próximo parent na lista. Faz ping periodicamente aos parents de maior prioridade — quando o parent original regressa, o filho volta a mudar para ele. Mensagens KeepAlive a cada 20 segundos mantêm a conectividade bidirecional através de NAT. Os parents nunca são removidos da topologia (configuração persistente).
Construído para os dispositivos mais pequenos. Testado nas maiores redes.
O MCC foi concebido primeiro para dispositivos de periferia com recursos limitados. O mesmo binário Rust funciona num Raspberry Pi Zero 2W, num router Teltonika RUT956 (128 MiB RAM) e em 12 000 nós num único servidor cloud.
- Testado com centenas de nós
- Estrangulamento no nó raiz: armazenamento completo da topologia
- Escala até milhares por região
- Configurável através do certificado de rede
- Típico: 10 a 100 túneis por nó
- Cada túnel ~2 KB de sobrecarga de memória
- A arquitetura orientada a eventos processa milhares/seg.
- O transporte UDP elimina a sobrecarga do handshake TCP
- Tolerância à perda de pacotes através de nova tentativa ao nível da aplicação
Linux, Android, macOS — todos em produção. Windows planeado.
O mesmo núcleo Rust funciona em todas as plataformas suportadas, com implementações de dispositivo TUN leves e específicas de cada plataforma. O suporte para Windows está planeado via WinTUN.
| Plataforma | Estado | Funcionalidades |
|---|---|---|
| Linux | Completo | TUN/TAP, integração iptables, gestão de capacidades (CAP_NET_ADMIN, CAP_NET_RAW), kill switch, redirecionamento de porta |
| Android | Completo | Integração com o serviço VPN, bindings JNI via mcc-android, resolvedor DNS nativo, encaminhamento baseado em processos |
| macOS | Completo | Suporte nativo de dispositivo TUN, respondedor mDNS para .local, integração com DNS do sistema |
| Windows | Planeado | TUN/TAP via WinTUN |
- Raspberry Pi 4
- Raspberry Pi Zero 2W
- Intel NUC
- Servidores cloud (AMD EPYC, Intel Xeon)
amd64, arm64, armhf, armel — pacotes DEB, RPM, tar.gz
- Teltonika RUT956
- Teltonika RUT950
- Teltonika RUT200
- Teltonika RUTX50
OpenWRT e derivados — pacotes IPK e tar.gz
Três cenários de implementação. Um protocolo. Uma frota em produção.
O MCC adapta-se a três topologias de implementação comuns: IoT industrial com parents on-premise, serviços distribuídos entre centros de dados, e acesso remoto para dispositivos móveis. As três já estão em funcionamento hoje.
IoT industrial
- Dispositivos de periferia (sensores, atuadores) ligam-se a um parent on-premise
- O parent on-premise liga-se à raiz na cloud
- Túneis gateway expõem serviços específicos (Modbus, OPC-UA)
- Certificado de rede privado para isolamento
Serviços distribuídos
- Microsserviços distribuídos por vários centros de dados
- O MCC fornece uma rede overlay segura
- Descoberta de serviços baseada em DNS
- Distribuição de certificados SSL para HTTPS
Acesso remoto
- Dispositivos móveis ligam-se através de nós parent públicos
- Túneis para serviços específicos (SSH, RDP, VNC)
- Controlo de acesso baseado em certificados através de listas brancas de túneis
MIBO — frota de 150 autocarros, Renânia do Norte-Vestfália
O MCC é a camada de conectividade que alimenta a frota de 150 autocarros da MIBO na rede MINT. A telemetria assinada pelo veículo (número de passageiros, CO₂, GPS) circula através de túneis MCC para uma cadeia de dados ancorada na Solana e na U2U — de nível de produção, pronta para auditoria, todos os dias.
Atestação multi-chain
As identidades de nó do MCC podem ser ancoradas em peaq, ICP, Solana, U2U, Linera, Celo, Hedera, Optimism e Lisk — mesmo protocolo, múltiplas raízes de confiança. Escolha a chain que os seus clientes e reguladores já auditam.
Quer executar o MCC?
O MCC é a camada de conectividade subjacente a todos os produtos Staex — Connectivity, Connect & Transfer (MINT) e a Agentic Suite. Fale connosco sobre a sua implementação na sua própria infraestrutura, ou mergulhe diretamente na documentação.