La arquitectura de seguridad de Remio, dicha con claridad.

§01 · Resumen ejecutivo

Remio es una aplicación de escritorio remoto construida sobre una arquitectura de conocimiento cero y de dispositivo a dispositivo. El contenido de la pantalla, los datos de entrada y los flujos de audio se cifran de extremo a extremo entre los dispositivos con DTLS-SRTP, un estándar de la industria: el mismo modelo de seguridad en el que se apoya todo producto basado en WebRTC. A diferencia de las soluciones centralizadas, el servidor de señalización de Remio solo facilita el establecimiento inicial de la conexión: nunca ve, procesa ni almacena los datos de la sesión.

No se requieren cuentas, no hay contraseñas que vulnerar ni una base de datos central de credenciales. La vinculación de dispositivos usa un código QR o un ID del dispositivo y un PIN que se leen en la propia pantalla del host, y todas las claves de sesión son efímeras con secreto perfecto hacia adelante: aunque una clave se vea comprometida, las sesiones pasadas y futuras siguen siendo criptográficamente seguras. Esta arquitectura elimina categorías enteras de ataques que han afectado a la competencia, porque simplemente no hay nada que robar.

§02 · Modelo de amenazas

La arquitectura de seguridad de Remio está diseñada frente a un conjunto de escenarios de amenaza relevantes para el uso del escritorio remoto tanto en entornos empresariales como personales. Somos explícitos sobre contra qué nos protegemos y dónde están los límites de confianza.

Amenazas contra las que nos protegemos

• Espionaje. Todo el contenido multimedia (video, audio) y los canales de datos (entrada, teclado, cursor) se cifran con SRTP y DTLS, respectivamente. Un observador de la red solo ve paquetes cifrados sin posibilidad de reconstruir el contenido de la sesión.
• Intermediario malicioso (MITM). El protocolo de enlace DTLS con verificación de la huella del certificado impide la interceptación. El canal de señalización usa TLS 1.3 con secreto perfecto hacia adelante.
• Vulneración del servidor. Aunque nuestro servidor de señalización se vea totalmente comprometido, los atacantes solo obtienen acceso a los metadatos de la conexión (direcciones IP, marcas de tiempo). El contenido de la sesión nunca se transmite por nuestros servidores ni se almacena en ellos.
• Acceso no autorizado. La vinculación exige escanear el código QR del host, escribir el ID del dispositivo y el PIN que muestra, o iniciar sesión en la misma cuenta de Remio en ambos. No existe una base de datos de credenciales accesible de forma remota que atacar.
• Robo de credenciales. Sin contraseñas, sin cuentas, sin un almacén central de credenciales. La confianza entre dispositivos se establece mediante la vinculación con PIN; los tokens de sesión (JWT) son de corta duración y están ligados al dispositivo.
• Repetición de sesiones. La protección contra repetición integrada de SRTP y los números de secuencia de DTLS impiden que se reproduzcan paquetes capturados.
• Ataques a la cadena de suministro. Todos los binarios de Remio están firmados. Las versiones para macOS están notarizadas por Apple. Las versiones para iOS se distribuyen exclusivamente a través del App Store.

Límites de confianza

Nuestro modelo de amenazas define explícitamente tres límites de confianza:

1. Límite del dispositivo. Cada dispositivo es de confianza solo tras la verificación del PIN. Las protecciones del sistema operativo (el aislamiento de apps y el almacenamiento protegido de cada sistema, como el llavero) protegen los datos del dispositivo.
2. Límite de la red. Todos los datos en tránsito están cifrados. Asumimos que la red es hostil.
3. Límite del servidor. Nuestros propios servidores se tratan como retransmisores no confiables. Facilitan las conexiones, pero no pueden inspeccionar el contenido.

§03 · Resumen de la arquitectura

Remio separa el plano de señalización (preparación de la conexión) del plano de datos (transmisión). Esta separación es fundamental para nuestro diseño de conocimiento cero: el servidor que te ayuda a conectarte nunca toca los datos que intercambias.

Señalización frente a plano de datos

La única responsabilidad del servidor de señalización es retransmitir las ofertas y respuestas SDP y los candidatos ICE entre los dispositivos durante la preparación de la conexión. Una vez establecida la conexión entre dispositivos, el servidor de señalización ya no interviene.

El servidor no puede interpretar el contenido retransmitido: es un bloque binario cifrado que solo el dispositivo de destino puede interpretar. El protocolo binario añade una capa adicional de estructura que dificulta los ataques de inyección en comparación con una señalización basada en JSON.

§04 · Capas de cifrado

Remio emplea una estrategia de cifrado de varias capas en la que cada canal de comunicación usa el protocolo criptográfico más adecuado para sus requisitos.

Secreto perfecto hacia adelante

Cada sesión de Remio genera un conjunto único de claves de cifrado efímeras mediante el intercambio de claves ECDHE.

• Comprometer la clave de la sesión actual no expone las sesiones pasadas.
• Comprometer la clave de la sesión actual no expone las sesiones futuras.
• Cada par de claves existe solo mientras dura una sesión.
• Las claves nunca se guardan en disco: existen solo en memoria.

Suites de cifrado

# Señalización — suites de cifrado TLS 1.3 (en orden de preferencia)
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

# Multimedia — perfil de protección SRTP (valor predeterminado de WebRTC en la industria)
SRTP_AES128_CM_SHA1_80   # AES-128 en modo contador, autenticación HMAC-SHA1-80

# Certificados DTLS
ECDSA autofirmado (P-256), verificado fuera de banda mediante las huellas SDP

Rotación de claves

Las claves se rotan automáticamente en los siguientes momentos:

• Inicio de la sesión. Un nuevo protocolo de enlace DTLS genera claves nuevas para cada conexión.
• Derivación de claves SRTP. Las claves multimedia se derivan del protocolo de enlace DTLS y son únicas para cada pista multimedia.
• Reconexión. Si una sesión se interrumpe y se reconecta, se produce un intercambio de claves completamente nuevo.

§05 · Autenticación y vinculación

Remio evita deliberadamente la autenticación tradicional con usuario y contraseña. En su lugar, usamos un modelo de vinculación de dispositivos basado en PIN que elimina los vectores de ataque más comunes del software de escritorio remoto.

Vinculación basada en PIN

Cuando un cliente quiere conectarse a un host por primera vez, el proceso funciona así:

1. El host muestra en su pantalla un PIN numérico corto (o un código QR).
2. El cliente introduce el PIN, que se envía al host por el canal de señalización.
3. El host valida el PIN y confirma o rechaza la vinculación.
4. Si es correcto, se establece una relación de confianza entre dispositivos.
5. Las conexiones posteriores del mismo dispositivo no requieren volver a vincular.

Modelo de confianza entre dispositivos

Una vez vinculado, cada dispositivo se identifica con un ID de dispositivo único. El host mantiene una lista local de dispositivos de confianza. Esta relación de confianza es:

• Almacenada localmente solo en el dispositivo host, en el almacenamiento protegido que ofrece su sistema: el llavero en una Mac, el almacenamiento cifrado del sistema en Windows, un archivo privado en Linux.
• Nunca transmitida: el servidor no sabe qué dispositivos son de confianza.
• Revocable: el host puede quitar un dispositivo de confianza en cualquier momento.

Tokens de sesión (JWT)

Después de la vinculación, se usan tokens firmados de corta duración (24 horas de vigencia) para autenticarse ante el servidor de señalización.

Estos tokens autentican a un dispositivo ante el servidor de señalización para crear salas y retransmitir mensajes. No dan acceso al contenido de la sesión, que está protegido por un protocolo de enlace DTLS independiente.

Acceso de agentes de IA (Remio MCP Server)

Remio extiende este mismo modelo de confianza a los agentes de IA. Herramientas como Claude Code, Codex o la app de Claude pueden operar tus máquinas de forma remota mediante el Remio MCP Server, y el límite de seguridad es idéntico al que cruza un cliente humano:

• Todo está condicionado a tu inicio de sesión. Un agente solo puede llegar a los hosts que están en línea y vinculados a la cuenta con la que tú te autenticaste (inicio de sesión con Google o Apple, mediante OAuth). Sin una cuenta autenticada, no hay herramientas.
• Remio es un intermediario, no un operador. El único trabajo del servidor MCP es exponer un conjunto de herramientas limitadas a tu cuenta autenticada y entregárselas a la herramienta de IA que tú elegiste conectar. Remio no puede iniciar por su cuenta una sesión con tu máquina: un host solo acepta conexiones que presenten una prueba de la autorización de tu cuenta, exactamente como en el modelo de confianza entre dispositivos anterior.
• El mismo transporte cifrado. Las sesiones de los agentes viajan por los mismos canales cifrados de extremo a extremo descritos en el §04. Nuestros servidores siguen viendo solo bloques cifrados: las propiedades de conocimiento cero del §06 se aplican sin cambios.
• Visible, interrumpible y auditada. Una sesión de un agente se muestra en el host mientras se ejecuta, se puede terminar al instante con un interruptor de emergencia y queda registrada en un registro de auditoría local.

§06 · Diseño de conocimiento cero

En Remio, el conocimiento cero no es un término de marketing: es una restricción de arquitectura. Nuestros sistemas están diseñados para que el contenido de la sesión sea estructuralmente inaccesible para Remio, sus empleados o cualquier tercero.

Lo que pueden ver nuestros servidores

• Las direcciones IP de los dispositivos que se conectan (necesarias para la red).
• Las marcas de tiempo de las conexiones.
• Los ID de dispositivo (identificadores opacos, no vinculados a información personal).
• Metadatos de señalización: intercambio de oferta y respuesta SDP, candidatos ICE.

Lo que no pueden ver nuestros servidores

• El contenido de la pantalla: los fotogramas de video están cifrados con SRTP de extremo a extremo.
• El audio: el mismo cifrado SRTP que el video.
• Los eventos de entrada: mouse, teclado y toques están cifrados con DTLS.
• La posición del cursor: se transmite por el canal de datos cifrado.
• El contenido de los archivos: cualquier transferencia de archivos ocurre por canales cifrados.
• Los datos del portapapeles: canal de datos cifrado.
• El estado de las aplicaciones: qué apps estás ejecutando y en qué estás trabajando.

Política de conservación de datos

Gracias a nuestra arquitectura de dispositivo a dispositivo, en la práctica no hay nada que conservar:

• Contenido de la sesión. Nunca se almacena. Solo transmisión en tiempo real.
• Registros de señalización. Los metadatos de conexión se conservan hasta 30 días para depuración y luego se eliminan. No contienen contenido de la sesión.
• Cuentas de usuario. No se requieren cuentas. Los datos opcionales de Firebase Auth los gestiona la infraestructura de Google y el usuario puede eliminarlos.
• Información del dispositivo. Se almacena localmente en cada dispositivo. Si decides iniciar sesión, tu lista de dispositivos se sincroniza con tu cuenta (consulta la política de privacidad).

Flujo de datos con prioridad en la conexión directa

En la mayoría de las conexiones (en las que el recorrido de NAT funciona), los datos fluyen directamente entre los dispositivos sin tocar ningún servidor:

# Mejor caso: conexión directa entre dispositivos
Cliente <—— DTLS-SRTP (cifrado) ——> Host
              ↑ Sin intervención de servidores

# Respaldo: retransmisión TURN
Cliente <— DTLS-SRTP —> Servidor TURN <— DTLS-SRTP —> Host
                            ↑ Sigue cifrado de extremo a extremo
                            ↑ El servidor solo ve bloques cifrados

Incluso en el escenario de respaldo con retransmisión TURN, el servidor de retransmisión maneja solo paquetes cifrados. Actúa como una tubería ciega: no puede descifrar, inspeccionar ni modificar los datos.

§07 · Seguridad de la red

Establecimiento de la conexión entre dispositivos

Remio usa el protocolo ICE (Interactive Connectivity Establishment) para encontrar la mejor ruta de conexión posible entre dispositivos:

1. Candidatos del host: conexión directa por red local en la misma red.
2. Candidatos reflexivos del servidor (STUN): recorrido de NAT mediante servidores STUN para descubrir la IP pública.
3. Candidatos de retransmisión (TURN): retransmisión cifrada cuando no se puede establecer una conexión directa.

El agente ICE prueba todos los pares de candidatos al mismo tiempo y elige la ruta de menor latencia y mayor fiabilidad. Siempre se prefiere la conexión directa entre dispositivos.

Políticas de transporte configurables

Por defecto, las conexiones prefieren la ruta directa entre dispositivos con respaldo automático a la retransmisión cifrada. Hay políticas más estrictas (forzar todo el tráfico por la retransmisión u omitir por completo el descubrimiento en la red local) para entornos de red restringidos.

Limitación de frecuencia

El servidor de señalización aplica una limitación de frecuencia estricta para evitar abusos:

Los limitadores de frecuencia vencidos se limpian automáticamente cada 5 minutos con una vigencia de 10 minutos, lo que evita el agotamiento de memoria por ataques distribuidos.

Protección contra DDoS

Nuestra infraestructura de señalización está protegida por Cloudflare, que ofrece:

• DNS Anycast con una red global de nodos perimetrales.
• Mitigación de DDoS en las capas 3, 4 y 7.
• Firewall de aplicaciones web (WAF).
• Limitación de frecuencia en el perímetro antes de que el tráfico llegue al origen.
• Detección de bots y páginas de verificación.

§08 · Seguridad del cliente

Remio aprovecha toda la pila de seguridad de cada sistema operativo para proteger los datos locales y garantizar la integridad de la aplicación.

macOS

• Integración con el llavero. Todos los datos sensibles (tokens de confianza del dispositivo, JWT) se guardan en el llavero de macOS, protegidos por las credenciales de inicio de sesión del usuario y por el cifrado del hardware.
• Aislamiento de apps (App Sandbox). Remio se ejecuta en un entorno aislado con permisos mínimos. La captura de pantalla y la accesibilidad requieren la aprobación explícita del usuario.
• Firma de código. Todas las versiones se firman con certificados de Apple Developer.
• Notarización. Las versiones para macOS están notarizadas por Apple, lo que confirma que no contienen malware conocido.
• Entorno de ejecución reforzado. Impide la inyección de código, el secuestro de bibliotecas y la depuración en las versiones de producción.

iOS

• App Transport Security (ATS). Todas las conexiones de red deben usar HTTPS/TLS. No hay excepciones configuradas.
• Protección de datos. Los elementos del llavero se cifran con claves que el dispositivo deriva de su propio hardware, y los elementos marcados como solo de este dispositivo nunca salen de él, ni siquiera en una copia de seguridad.
• Servicios del llavero. Las credenciales del dispositivo se guardan en el llavero de iOS con la clase de protección kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly.
• Revisión del App Store. Todas las versiones de iOS pasan por el proceso de revisión de seguridad de Apple.
• Sin datos en segundo plano. La app no recopila ni transmite datos cuando está en segundo plano.

Firma de código y verificación

# Verificar el binario de 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 · Respuesta a incidentes

Historial de seguridad

A febrero de 2026, Remio no tiene historial de vulneraciones ni incidentes de seguridad. Nuestra arquitectura de conocimiento cero reduce de forma significativa la superficie de ataque: no hay una base de datos central de credenciales ni de datos de sesión a la que apuntar.

Reporte de vulnerabilidades

Fomentamos la divulgación responsable por parte de los investigadores de seguridad. Si descubres una posible vulnerabilidad:

1. Escribe a security@remio.net con una descripción detallada.
2. Incluye los pasos para reproducirla, si corresponde.
3. Confirmamos la recepción en un plazo de 48 horas.
4. Nos proponemos resolver las vulnerabilidades confirmadas en un plazo de 30 días.
5. Reconocemos a quienes reportan en nuestro registro de cambios de seguridad, salvo que prefieran el anonimato.

Política de divulgación responsable

• Pedimos una ventana de divulgación de 90 días antes de la divulgación pública.
• No emprendemos acciones legales contra investigadores que actúan de buena fe.
• Priorizamos las correcciones según la gravedad: crítica, alta, media, baja.
• Un programa formal de recompensas por errores está en nuestra hoja de ruta.

Proceso de respuesta a incidentes

En caso de un problema de seguridad confirmado:

1. Contención. Aislar los sistemas afectados en 1 hora.
2. Evaluación. Determinar el alcance y el impacto en 24 horas.
3. Comunicación. Notificar a los usuarios afectados en 72 horas (conforme al RGPD).
4. Remediación. Desplegar parches mediante la infraestructura de actualización automática.
5. Análisis posterior. Publicar un informe de transparencia.

§10 · Cumplimiento

Preparación para el RGPD

La arquitectura de conocimiento cero de Remio es compatible con el RGPD por naturaleza, porque reducimos la recopilación de datos al mínimo técnico absoluto:

• Minimización de datos. Solo recopilamos lo necesario para establecer la conexión.
• Derecho de supresión. Como no almacenamos el contenido de los usuarios, no hay nada que eliminar. Los datos opcionales de la cuenta se pueden eliminar a solicitud.
• Portabilidad de los datos. Los datos de confianza de los dispositivos se almacenan localmente y los controla el usuario.
• Consentimiento. La vinculación con PIN es un mecanismo de consentimiento explícito para cada dispositivo.
• Sin transferencias transfronterizas de contenido. Las conexiones entre dispositivos mantienen los datos entre ellos; nunca entran en nuestra infraestructura.

SOC 2

Aún no está implementado

• Auditoría de seguridad independiente: todavía no se ha hecho ninguna prueba de penetración ni revisión de código por parte de terceros.
• SOC 2 Tipo I: todavía no hay informe.
• SOC 2 Tipo II: todavía no hay informe.
• Programa de recompensas por errores: recompensas formales por divulgación responsable.

Residencia de los datos

Como Remio da prioridad a la conexión directa entre dispositivos, los datos de la sesión residen donde estén tus dispositivos. Tus datos nunca salen de la conexión directa entre tus dispositivos. El servidor de señalización (alojado con Cloudflare y DigitalOcean) procesa solo metadatos de conexión, y esos metadatos no están vinculados a ninguna información personal.

§11 · Comparación con las alternativas

La industria del escritorio remoto ha sufrido vulneraciones de seguridad de gran repercusión. Así es como la arquitectura de Remio se diferencia de raíz de las alternativas centralizadas.

Por qué fallan las arquitecturas centralizadas

El problema fundamental de los servicios de escritorio remoto centralizados es que una sola vulneración puede comprometer a todos los usuarios. Cuando los servidores de producción de AnyDesk fueron vulnerados en febrero de 2024, los atacantes robaron certificados de firma de código, lo que potencialmente les permitía distribuir malware disfrazado de software legítimo de AnyDesk. Hubo que restablecer todas las contraseñas de los usuarios.

Cuando APT29 (un grupo patrocinado por el Estado ruso) vulneró la red corporativa de TeamViewer en junio de 2024, surgieron dudas sobre la integridad del propio producto, porque una arquitectura centralizada significa que el proveedor tiene la capacidad técnica de acceder a las sesiones.

Remio elimina por completo esta clase de ataque. Vulnerar nuestro servidor de señalización solo produce metadatos de conexión. No hay credenciales que robar, ni sesiones a las que acceder, ni certificados que se puedan usar para firmar software malicioso dirigido a los dispositivos de nuestros usuarios.

§12 · Conclusión

La seguridad de Remio no es un conjunto de funciones añadidas a un producto: es la consecuencia de decisiones de arquitectura tomadas desde el primer día. Al elegir la conexión directa en lugar de la centralizada, la vinculación con PIN en lugar de las contraseñas y el conocimiento cero en lugar de la recopilación de datos, hemos construido un escritorio remoto en el que la seguridad es el estado predeterminado, no una mejora opcional.

Creemos que la privacidad no es opcional y que la confianza debe ganarse con transparencia, no exigirse mediante términos de servicio. Este informe técnico es parte de ese compromiso.

Para preguntas, revisiones de seguridad empresariales o para reportar una vulnerabilidad:

• Consultas de seguridad: security@remio.net
• Ventas para empresas: enterprise@remio.net
• General: hello@remio.net