A arquitetura de segurança do Remio, dita com clareza.

§01 · Resumo executivo

O Remio é um aplicativo de área de trabalho remota construído sobre uma arquitetura ponto a ponto de conhecimento zero. O conteúdo da tela, os dados de entrada e os fluxos de áudio têm criptografia de ponta a ponta entre os dispositivos usando o DTLS-SRTP, padrão da indústria — o mesmo modelo de segurança em que todo produto baseado em WebRTC se apoia. Ao contrário das soluções centralizadas, o servidor de sinalização do Remio apenas facilita o estabelecimento inicial da conexão — ele nunca vê, processa nem armazena dados de sessão.

Não é preciso conta, não há senhas para violar nem banco central de credenciais. O pareamento de dispositivos usa códigos de seis dígitos lidos na própria tela do host, e todas as chaves de sessão são efêmeras, com Perfect Forward Secrecy (sigilo perfeito): mesmo que uma chave seja comprometida, as sessões passadas e futuras continuam criptograficamente seguras. Essa arquitetura elimina categorias inteiras de ataques que afligiram os concorrentes — porque simplesmente não há nada para roubar.

§02 · Modelo de ameaças

A arquitetura de segurança do Remio é projetada contra um conjunto de cenários de ameaça relevantes para o uso de área de trabalho remota em contextos corporativos e pessoais. Somos explícitos sobre contra o que protegemos e onde ficam as fronteiras de confiança.

Ameaças contra as quais protegemos

• Espionagem. Toda mídia (vídeo, áudio) e todos os canais de dados (entrada, teclado, cursor) são criptografados com SRTP e DTLS, respectivamente. Um observador de rede vê apenas pacotes criptografados, sem nenhuma capacidade de reconstruir o conteúdo da sessão.
• Homem no meio (MITM). O handshake DTLS com verificação da impressão digital do certificado impede a interceptação. O canal de sinalização usa TLS 1.3 com Perfect Forward Secrecy.
• Comprometimento do servidor. Mesmo que o nosso servidor de sinalização seja totalmente comprometido, os atacantes só obtêm acesso a metadados de conexão (endereços IP, carimbos de data e hora). O conteúdo da sessão nunca é transmitido pelos nossos servidores nem armazenado neles.
• Acesso não autorizado. O pareamento por PIN exige proximidade física ou o conhecimento de um PIN exibido. Não existe um banco de credenciais acessível remotamente para atacar.
• Roubo de credenciais. Sem senhas, sem contas, sem repositório central de credenciais. A confiança no dispositivo é estabelecida pelo pareamento por PIN; os tokens de sessão (JWT) têm vida curta e são vinculados ao dispositivo.
• Replay de sessão. A proteção contra replay embutida no SRTP e os números de sequência do DTLS impedem que pacotes capturados sejam reproduzidos.
• Ataques à cadeia de suprimentos. Todos os binários do Remio têm assinatura de código. As versões para macOS são notarizadas pela Apple. As versões para iOS são distribuídas exclusivamente pela App Store.

Fronteiras de confiança

O nosso modelo de ameaças define explicitamente três fronteiras de confiança:

1. Fronteira do dispositivo. Cada dispositivo só é confiável após a verificação do PIN. As proteções no nível do SO (sandbox, Keychain, Secure Enclave) protegem os dados no dispositivo.
2. Fronteira da rede. Todos os dados em trânsito são criptografados. Presumimos que a rede é hostil.
3. Fronteira do servidor. Os nossos próprios servidores são tratados como relays não confiáveis. Eles facilitam as conexões, mas não conseguem inspecionar o conteúdo.

§03 · Visão geral da arquitetura

O Remio separa o plano de sinalização (estabelecimento da conexão) do plano de dados (streaming). Essa separação é fundamental para o nosso projeto de conhecimento zero — o servidor que ajuda você a se conectar nunca toca nos dados que você troca.

Sinalização vs. plano de dados

A única responsabilidade do servidor de sinalização é retransmitir ofertas/respostas SDP e candidatos ICE entre dispositivos durante o estabelecimento da conexão. Uma vez estabelecida a conexão P2P, o servidor de sinalização não participa mais.

O servidor não consegue interpretar o conteúdo retransmitido — é um blob binário criptografado que só o dispositivo de destino consegue interpretar. O protocolo binário acrescenta uma camada extra de estrutura que torna os ataques de injeção mais difíceis em comparação com a sinalização baseada em JSON.

§04 · Camadas de criptografia

O Remio emprega uma estratégia de criptografia em várias camadas, em que cada canal de comunicação usa o protocolo criptográfico mais adequado aos seus requisitos.

Perfect forward secrecy (sigilo perfeito)

Toda sessão do Remio gera um conjunto único de chaves de criptografia efêmeras por meio da troca de chaves ECDHE.

• Comprometer a chave da sessão atual não expõe as sessões passadas.
• Comprometer a chave da sessão atual não expõe as sessões futuras.
• Cada par de chaves existe apenas durante uma única sessão.
• As chaves nunca são gravadas em disco — existem apenas na memória.

Suítes de cifras

# Sinalização — suítes de cifras do TLS 1.3 (em ordem de preferência)
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

# Mídia — perfil de proteção SRTP (padrão do setor no WebRTC)
SRTP_AES128_CM_SHA1_80   # AES-128 em modo contador, autenticação HMAC-SHA1-80

# Certificados DTLS
ECDSA autoassinado (P-256), verificado fora de banda pelas impressões digitais do SDP

Rotação de chaves

As chaves são rotacionadas automaticamente nas seguintes fronteiras:

• Início da sessão. Um novo handshake DTLS gera chaves novas a cada conexão.
• Derivação de chaves SRTP. As chaves de mídia são derivadas do handshake DTLS e são únicas por faixa de mídia.
• Reconexão. Se uma sessão é interrompida e reconectada, ocorre uma troca de chaves completamente nova.

§05 · Autenticação e pareamento

O Remio evita deliberadamente a autenticação tradicional por usuário e senha. Em vez disso, usamos um modelo de pareamento de dispositivos por PIN que elimina os vetores de ataque mais comuns em softwares de área de trabalho remota.

Pareamento por PIN

Quando um cliente quer se conectar a um host pela primeira vez, o processo funciona assim:

1. O host exibe um PIN numérico curto na tela (ou como um código QR).
2. O cliente digita o PIN, que é enviado ao host pelo canal de sinalização.
3. O host valida o PIN e confirma ou rejeita o pareamento.
4. Em caso de sucesso, é estabelecida uma relação de confiança entre dispositivos.
5. As conexões seguintes do mesmo dispositivo não exigem novo pareamento.

Modelo de confiança entre dispositivos

Depois de pareado, cada dispositivo é identificado por um ID de dispositivo único. O host mantém uma lista local de dispositivos confiáveis. Essa relação de confiança é:

• Armazenada localmente apenas no dispositivo host, no Keychain do SO.
• Nunca transmitida — o servidor não sabe quais dispositivos são confiáveis.
• Revogável — o host pode remover um dispositivo confiável a qualquer momento.

Tokens de sessão (JWT)

Depois do pareamento, tokens assinados de vida curta (expiração em 24 horas) são usados para a autenticação no servidor de sinalização.

Esses tokens autenticam um dispositivo no servidor de sinalização para a criação de salas e a retransmissão de mensagens. Eles não concedem acesso ao conteúdo da sessão, que é protegido por um handshake DTLS separado.

Acesso de agentes de IA (Remio MCP Server)

O Remio está estendendo esse mesmo modelo de confiança a agentes de IA. Ferramentas como o Claude Code, o Codex ou o app Claude podem operar as suas máquinas remotamente pelo Remio MCP Server — e a fronteira de segurança é idêntica à que um cliente humano atravessa:

• Tudo é controlado pelo seu login. Um agente só alcança hosts que estão online e pareados com a conta com a qual você se autenticou (login do Google ou da Apple, via OAuth). Sem conta autenticada, sem ferramentas.
• O Remio é um intermediário, não um operador. A única função do servidor MCP é expor um conjunto de ferramentas restritas à sua conta autenticada e entregá-las à ferramenta de IA que você escolheu conectar. O Remio não consegue iniciar uma sessão com a sua máquina por conta própria — um host só aceita conexões que apresentem prova da autorização da sua conta, exatamente como no modelo de confiança entre dispositivos acima.
• O mesmo transporte criptografado. As sessões de agentes seguem pelos mesmos canais com criptografia de ponta a ponta descritos no §04. Os nossos servidores continuam vendo apenas blobs criptografados — as propriedades de conhecimento zero do §06 valem sem alteração.
• Visível, interrompível, auditada. Uma sessão de agente é exibida no host enquanto roda, pode ser encerrada na hora com uma chave de interrupção e é registrada em um log de auditoria local.

§06 · Projeto de conhecimento zero

Conhecimento zero não é um termo de marketing no Remio — é uma restrição arquitetural. Os nossos sistemas são projetados para que o conteúdo da sessão seja estruturalmente inacessível ao Remio, aos seus funcionários ou a qualquer terceiro.

O que os nossos servidores conseguem ver

• Endereços IP dos dispositivos que se conectam (necessários para a rede).
• Carimbos de data e hora das conexões.
• IDs de dispositivo (identificadores opacos, não vinculados a informações pessoais).
• Metadados de sinalização: a troca de oferta/resposta SDP e os candidatos ICE.

O que os nossos servidores não conseguem ver

• Conteúdo da tela — os quadros de vídeo têm criptografia SRTP de ponta a ponta.
• Áudio — a mesma criptografia SRTP do vídeo.
• Eventos de entrada — mouse, teclado e toque têm criptografia DTLS.
• Posição do cursor — transmitida por um canal de dados criptografado.
• Conteúdo de arquivos — qualquer transferência de arquivo ocorre por canais criptografados.
• Dados da área de transferência — canal de dados criptografado.
• Estado dos aplicativos — quais apps você está rodando, no que está trabalhando.

Política de retenção de dados

Por causa da nossa arquitetura P2P, na prática não há nada para reter:

• Conteúdo da sessão. Nunca armazenado. Apenas fluxo em tempo real.
• Logs de sinalização. Metadados de conexão retidos por até 30 dias para depuração e depois excluídos. Não contêm conteúdo de sessão.
• Contas de usuário. Não é preciso conta. Os dados opcionais do Firebase Auth são gerenciados pela infraestrutura do Google e podem ser excluídos pelo usuário.
• Informações do dispositivo. Armazenadas localmente em cada dispositivo. Se você optar por entrar em uma conta, a sua lista de dispositivos é sincronizada com ela (veja a política de privacidade).

Fluxo de dados que prioriza o P2P

Na maioria das conexões (em que o NAT traversal tem sucesso), os dados fluem diretamente entre os dispositivos, sem tocar em nenhum servidor:

# Melhor caso: P2P direto
Cliente <—— DTLS-SRTP (criptografado) ——> Host
              ↑ Sem participação de servidor

# Alternativa: relay TURN
Cliente <— DTLS-SRTP —> Servidor TURN <— DTLS-SRTP —> Host
                            ↑ Ainda com criptografia E2E
                            ↑ O servidor vê apenas blobs criptografados

Mesmo no cenário de alternativa por relay TURN, o servidor de relay trata apenas pacotes criptografados. Ele age como um cano burro — não consegue decifrar, inspecionar nem modificar os dados.

§07 · Segurança de rede

Estabelecimento da conexão P2P

O Remio usa o protocolo ICE (Interactive Connectivity Establishment) para encontrar o melhor caminho possível de conexão entre os dispositivos:

1. Candidatos de host — conexão direta na rede local, na mesma rede.
2. Candidatos server-reflexive (STUN) — NAT traversal por servidores STUN para descobrir o IP público.
3. Candidatos de relay (TURN) — relay criptografado quando uma conexão direta não pode ser estabelecida.

O agente ICE testa todos os pares de candidatos simultaneamente e seleciona o caminho de menor latência e mais confiável. O P2P direto é sempre preferido.

Políticas de transporte configuráveis

As conexões, por padrão, preferem o P2P direto com alternativa automática para o relay criptografado. Políticas mais rígidas — forçar todo o tráfego pelo relay ou pular totalmente a descoberta na rede local — estão disponíveis para ambientes de rede restritos.

Limitação de taxa

O servidor de sinalização implementa uma limitação de taxa agressiva para evitar abusos:

Os limitadores de taxa expirados são limpos automaticamente a cada 5 minutos, com um TTL de 10 minutos, evitando o esgotamento de memória por ataques distribuídos.

Proteção contra DDoS

A nossa infraestrutura de sinalização é protegida pela Cloudflare, que oferece:

• DNS Anycast com uma rede de borda global.
• Mitigação de DDoS nas camadas 3, 4 e 7.
• Web Application Firewall (WAF).
• Limitação de taxa na borda antes de o tráfego chegar à origem.
• Detecção de bots e páginas de desafio.

§08 · Segurança do cliente

O Remio aproveita a pilha de segurança completa de cada sistema operacional para proteger os dados locais e garantir a integridade do aplicativo.

macOS

• Integração com o Keychain. Todos os dados sensíveis (tokens de confiança do dispositivo, JWT) são armazenados no Keychain do macOS, protegidos pelas credenciais de login do usuário e por criptografia de hardware.
• App Sandbox. O Remio roda em um ambiente isolado, com permissões mínimas. A captura de tela e a acessibilidade exigem aprovação explícita do usuário.
• Assinatura de código. Todas as versões são assinadas com certificados do Apple Developer.
• Notarização. As versões para macOS são notarizadas pela Apple, o que confirma que estão livres de malware conhecido.
• Hardened runtime. Impede injeção de código, sequestro de bibliotecas e depuração nas versões de produção.

iOS

• App Transport Security (ATS). Todas as conexões de rede precisam usar HTTPS/TLS. Nenhuma exceção configurada.
• Secure Enclave. Onde disponível, as chaves criptográficas são geradas e armazenadas no hardware do Secure Enclave.
• Keychain Services. As credenciais do dispositivo são armazenadas no Keychain do iOS com a classe de proteção kSecAttrAccessibleWhenUnlockedThisDeviceOnly.
• Revisão da App Store. Todas as versões para iOS passam pelo processo de revisão de segurança da Apple.
• Sem dados em segundo plano. O app não coleta nem transmite dados quando está em segundo plano.

Assinatura de código & verificação

# Verifique o binário do Remio para macOS — verify_signature.sh
$ codesign --verify --deep --strict "Remio Host.app"
# Remio Host.app: valid on disk

$ spctl --assess --verbose "Remio Host.app"
# Remio Host.app: accepted
# source=Notarized Developer ID

§09 · Resposta a incidentes

Histórico de segurança

Em fevereiro de 2026, o Remio não tem histórico de violações ou incidentes de segurança. A nossa arquitetura de conhecimento zero reduz de forma significativa a superfície de ataque — não há banco central de credenciais ou de dados de sessão para mirar.

Relato de vulnerabilidades

Incentivamos a divulgação responsável por parte de pesquisadores de segurança. Se você descobrir uma possível vulnerabilidade:

1. Envie um e-mail para [email protected] com uma descrição detalhada.
2. Inclua os passos para reproduzir, se aplicável.
3. Confirmamos o recebimento em até 48 horas.
4. Buscamos resolver as vulnerabilidades confirmadas em até 30 dias.
5. Os autores dos relatos são creditados no nosso changelog de segurança, a menos que prefiram o anonimato.

Política de divulgação responsável

• Pedimos uma janela de divulgação de 90 dias antes da divulgação pública.
• Não tomamos medidas judiciais contra pesquisadores que agem de boa-fé.
• Priorizamos as correções por gravidade: crítica, alta, média, baixa.
• Um programa formal de recompensas por bugs está no nosso roteiro.

Processo de resposta a incidentes

No caso de um problema de segurança confirmado:

1. Contenção. Isolar os sistemas afetados em até 1 hora.
2. Avaliação. Determinar o escopo e o impacto em até 24 horas.
3. Comunicação. Notificar os usuários afetados em até 72 horas (em conformidade com o GDPR).
4. Correção. Implantar patches pela infraestrutura de atualização automática.
5. Post-mortem. Publicar um relatório de transparência.

§10 · Conformidade

Preparo para o GDPR

A arquitetura de conhecimento zero do Remio é inerentemente amigável ao GDPR, porque minimizamos a coleta de dados ao mínimo técnico absoluto:

• Minimização de dados. Coletamos apenas o necessário para estabelecer a conexão.
• Direito ao apagamento. Como não armazenamos o conteúdo do usuário, não há nada para excluir. Os dados opcionais de conta podem ser excluídos mediante solicitação.
• Portabilidade de dados. Os dados de confiança dos dispositivos são armazenados localmente e controlados pelo usuário.
• Consentimento. O pareamento por PIN é um mecanismo de consentimento explícito para cada dispositivo.
• Sem transferências internacionais de conteúdo. As conexões P2P mantêm os dados entre os dispositivos; eles nunca entram na nossa infraestrutura.

Roteiro do SOC 2

Marcos de conformidade planejados

• Auditoria de segurança independente — testes de intrusão profissionais e revisão de código, planejados para 2026.
• SOC 2 Tipo I — avaliação inicial dos controles organizacionais.
• SOC 2 Tipo II — verificação contínua de conformidade.
• Programa de recompensas por bugs — recompensas formais pela divulgação responsável.

Residência dos dados

Como o Remio prioriza o P2P, os dados da sessão residem onde estão os seus dispositivos. Os seus dados nunca saem da conexão direta entre os seus dispositivos. O servidor de sinalização (hospedado na Cloudflare e na DigitalOcean) processa apenas metadados de conexão — e esses metadados não estão vinculados a nenhuma informação pessoal.

§11 · Comparação com as alternativas

O setor de área de trabalho remota foi assolado por violações de segurança de grande repercussão. Veja como a arquitetura do Remio difere fundamentalmente das alternativas centralizadas.

Por que as arquiteturas centralizadas falham

O problema fundamental dos serviços centralizados de área de trabalho remota é que uma única violação pode comprometer todos os usuários. Quando os servidores de produção do AnyDesk foram violados em fevereiro de 2024, os atacantes roubaram certificados de assinatura de código, o que, em tese, lhes permitiria distribuir malware disfarçado de software legítimo do AnyDesk. Todas as senhas dos usuários precisaram ser redefinidas.

Quando o APT29 (um grupo russo apoiado pelo Estado) violou a rede corporativa do TeamViewer em junho de 2024, isso levantou dúvidas sobre a integridade do próprio produto — porque uma arquitetura centralizada significa que o fornecedor tem a capacidade técnica de acessar as sessões.

O Remio elimina essa classe de ataque por completo. A violação do nosso servidor de sinalização rende apenas metadados de conexão. Não há credenciais para roubar, sessões para acessar nem certificados que possam ser usados para assinar software malicioso voltado aos dispositivos dos nossos usuários.

§12 · Conclusão

A segurança do Remio não é um conjunto de recursos acrescentados a um produto — é uma consequência de decisões arquiteturais tomadas desde o primeiro dia. Ao escolher o P2P em vez do centralizado, o pareamento por PIN em vez de senhas e o conhecimento zero em vez da coleta de dados, construímos uma área de trabalho remota em que a segurança é o estado padrão, e não um upgrade opcional.

Acreditamos que a privacidade não é opcional e que a confiança deve ser conquistada pela transparência, e não exigida por termos de serviço. Este whitepaper faz parte desse compromisso.

Para perguntas, revisões de segurança corporativas ou para relatar uma vulnerabilidade:

• Consultas de segurança: [email protected]
• Vendas corporativas: [email protected]
• Geral: [email protected]