Sanket.Chat
Seguridad: servidor sin acceso al contenido

Arquitectura con servidor sin acceso al contenido: el servidor retransmite texto cifrado

Sanket (Sanket.Chat) de Tosh Defence impide que el servidor acceda al contenido: el servidor retransmite texto cifrado y nunca dispone de las claves de los mensajes, archivos, llamadas, reacciones ni difusiones cifradas. El contenido se cifra en el dispositivo emisor y solo se descifra en los dispositivos de los destinatarios, por lo que ni Tosh Defence, ni el proveedor de alojamiento, ni los propios servidores del cliente pueden leerlo.

Un servidor sin acceso al contenido cambia las consecuencias de una vulneración del servidor. Un atacante que controla el servidor no puede leer el contenido anterior, porque las claves nunca llegaron al servidor, ni puede añadir un dispositivo sin ser detectado para espiar, porque los remitentes verifican la lista firmada de dispositivos de cada cuenta.

Qué significa que el servidor no pueda acceder al contenido

En Sanket, el servidor actúa como retransmisor del contenido cifrado. Los mensajes, las reacciones y las difusiones cifradas son mensajes libsignal cifrados en el dispositivo del remitente; los archivos adjuntos se cifran con AES-256-GCM antes de cargarse; los flujos de las llamadas se cifran de extremo a extremo antes de llegar al servidor multimedia. Las claves para todos ellos se generan y permanecen en los dispositivos de los usuarios.

Incluso la etiqueta que indica la clasificación de un mensaje viaja cifrada, por lo que el servidor no puede leerla ni modificarla.

Un servidor comprometido no revela ningún contenido

Tosh Defence analiza las consecuencias de una vulneración de cada componente del servidor. En todos los casos, el contenido de los mensajes, las reacciones, las comunicaciones cifradas de uno a muchos, las etiquetas de clasificación, el contenido de los archivos, los datos de audio y vídeo de las llamadas y las claves privadas permanecen protegidos, porque la confidencialidad del contenido nunca depende de que un componente del servidor permanezca libre de vulneraciones.

La recuperación sigue un procedimiento único: reconstruir a partir de una versión verificada y firmada, renovar los secretos del servidor, exigir una nueva autenticación y revisar el registro de auditoría que permite detectar manipulaciones.

  • Contenido de los mensajes y reacciones
  • Difusiones cifradas y su prioridad
  • Etiquetas de clasificación
  • Contenido de los archivos
  • Contenido multimedia de las llamadas
  • Claves privadas

Sin participantes que puedan escuchar sin ser detectados

La lista de dispositivos de cada cuenta está firmada con una clave almacenada en el dispositivo principal de esa cuenta y cuenta con un registro de solo adición en la instalación. Antes de cifrar, quien envía un mensaje comprueba esa lista y no envía nada a ningún dispositivo que no figure en ella, por lo que un servidor hostil no puede añadir un dispositivo para recibir copias. Los números de seguridad y los avisos de cambio de identidad permiten a los usuarios verificar directamente la identidad de los demás.

Dentro de su instalación

SANKET nunca es un servicio público compartido. Cada organización utiliza su propia instalación exclusiva, por lo que los metadatos de enrutamiento necesarios para entregar mensajes permanecen en la instalación del cliente, sujetos al control de sus administradores, su política de conservación y sus auditorías.

Los administradores gestionan las identidades, los dispositivos y las políticas; no poseen claves de contenido y no pueden leer las conversaciones.

Pruebas técnicas

Consulte los detalles en el documento técnico de SANKET

Todas las afirmaciones de esta página se desarrollan íntegramente en el documento técnico público sobre seguridad y arquitectura de SANKET, disponible gratuitamente y sin necesidad de registrarse.

Preguntas Frecuentes

Preguntas frecuentes

Haga una pregunta a nuestro equipo

¿Qué significa que el servidor no pueda acceder al contenido?

Que el servidor no tenga acceso al contenido significa que retransmite texto cifrado y nunca tiene las claves de los mensajes, archivos, llamadas, reacciones ni difusiones cifradas. El contenido solo puede leerse en los dispositivos de las personas que participan en la conversación.

¿Puede Tosh Defence leer los mensajes de los clientes?

No. Tosh Defence no opera las instalaciones de los clientes ni dispone de ninguna vía de acceso a ellas, y el contenido de los mensajes está cifrado de extremo a extremo con claves que solo existen en los dispositivos de los usuarios.

¿Pueden los administradores del cliente leer los mensajes?

No. Los administradores gestionan las identidades, los dispositivos y las políticas. El servidor no almacena las claves del contenido, por lo que los administradores no pueden leer los mensajes ni los archivos, ni acceder al contenido de las llamadas.

¿Qué ocurre si un servidor de Sanket se ve comprometido?

El contenido de los mensajes y archivos anteriores sigue siendo confidencial porque se cifró con claves que el servidor nunca tuvo. Las listas de dispositivos firmadas impiden que el atacante añada un dispositivo para recibir copias, y los números de seguridad permiten a los usuarios verificar las identidades.

¿Puede el servidor modificar o volver a transmitir un mensaje difundido?

No. La prioridad, el plazo de confirmación de recepción y la caducidad de una difusión cifrada se transmiten dentro del cifrado de extremo a extremo, por lo que el servidor no puede rebajar su prioridad ni reproducirla de nuevo.

¿Adónde van los metadatos de enrutamiento?

Los metadatos de encaminamiento necesarios para entregar los mensajes permanecen dentro de la instalación dedicada del cliente, sujetos a su propia política de conservación y auditoría.

Vea cómo una arquitectura en la que el servidor no puede leer los datos cambia su modelo de amenazas

Tosh Defence informa a los arquitectos de seguridad sobre el análisis de vulneraciones de los servidores de Sanket.Chat, la confianza en los dispositivos y el tratamiento de los metadatos.