Da por hecho que los servidores están comprometidos

Antes de que una entrada llegue al almacén, su payload se cifra con una clave simétrica (AES-256-GCM). Este cifrado forma parte del modelo de datos, no del transporte. El servidor que guarda las entradas no puede leer su contenido: solo ve bytes cifrados.

Cuando el servidor responde a una petición de sincronización, envuelve los payloads de las entradas en una capa RSA adicional, con la clave pública del usuario que las pide. Aunque alguien capture la respuesta HTTP, no podrá descifrarla sin la clave RSA privada del destinatario.

Toda la comunicación va por TLS. Eso protege los metadatos (IDs de entrada, marcas de tiempo, parámetros de la petición) que las capas de cifrado del payload no cubren. Juntas, las tres capas garantizan una protección completa en reposo, en tránsito y en la línea.

Todos los documentos se cifran con la clave AES-256 predeterminada del tenant salvo que se indique otra. Cada usuario registrado recibe esa clave al incorporarse. Sirve para los datos generales de todo el tenant.

Para los documentos sensibles, crea una clave de cifrado con nombre y compártela solo con los usuarios autorizados. Las claves viajan fuera de línea (envía la clave cifrada por correo y la contraseña por teléfono o en persona) o de forma opaca para el administrador mediante una política: un usuario que ya tiene la clave la empaqueta con la clave pública personal de cada destinatario, así que un administrador puede distribuirla sin llegar a leerla. Solo quien tiene la clave puede descifrarlos.

Una clave especial que cifra únicamente las entradas de control de acceso del directorio (registros de usuario, revocaciones, grupos). Los servidores la usan para validar en qué claves de firma se confía, sin ver nombres de usuario ni datos de negocio. Los nombres de usuario se guardan como hashes SHA-256; los nombres reales van cifrados con la clave RSA del administrador.

Cada sesión de sincronización empieza con un saludo de desafío y respuesta:

• El cliente envía su clave pública de firma al servidor
• El servidor busca la clave en el directorio y envía un desafío aleatorio
• El cliente firma el desafío con su clave privada
• El servidor verifica la firma, comprueba si hay revocación y emite un JWT de corta duración

Sin contraseñas ni bases de datos de sesión en el servidor. Un usuario revocado no puede ni iniciar el proceso de autenticación.

Los usuarios nuevos se suman mediante un saludo en tres pasos en el que las claves privadas nunca salen del dispositivo:

• Solicitud de unión — El usuario nuevo genera sus claves en local y crea una solicitud que solo contiene claves públicas. Se puede compartir por cualquier canal sin riesgo.
• Aprobación del administrador — El administrador registra al usuario en el directorio y cifra las claves simétricas con una contraseña de uso único.
• Intercambio por dos canales — La respuesta de unión se envía por correo o chat; la contraseña compartida se comunica aparte, por teléfono o en persona.

• Firma: Ed25519 (seguridad de 128 bits, curva elíptica)
• Cifrado del payload: AES-256-GCM (seguridad de 256 bits)
• Cifrado del transporte: RSA-OAEP con SHA-256 (claves de 3072 bits)
• Derivación de claves: PBKDF2 con sales únicas por tipo de clave
• Firma de tokens: HMAC-SHA256
• Hashing: SHA-256 (direccionamiento por contenido, privacidad del nombre de usuario)

• Confidencialidad: cifrado AES-256-GCM — solo lee quien tiene la clave
• Autenticidad: firmas Ed25519 — demuestran quién creó cada cambio
• Integridad: encadenamiento por hash — manipular algo rompe la cadena y se detecta en cualquier punto
• No repudio: las firmas no se pueden falsificar — la autoría es demostrable
• Privacidad: los nombres de usuario van con hash y cifrados — el servidor no puede identificar a nadie

• Brecha en el servidor — Quien ataca obtiene solo texto cifrado y claves públicas. Nada en claro, ninguna clave privada, ningún nombre de usuario.
• Interceptación de la red — Tres capas de cifrado protegen los datos incluso si TLS queda comprometido.
• Cambios no autorizados — Todo cambio va firmado; los que no lo están o lo están mal se rechazan.
• Manipulación — El encadenamiento por hash hace detectable cualquier modificación.
• Acceso de un usuario revocado — La revocación se aplica tanto en el desafío como al validar el token; bloquea la sincronización de inmediato.
• Escucha en un relay — Los nodos de relay guardan y reenvían entradas cifradas que no pueden descifrar.

El contenido del payload siempre va cifrado, pero algunos metadatos son visibles para el servidor por diseño. Es un compromiso deliberado: el protocolo de sincronización necesita metadatos para reconciliar entradas.

• Visible: marcas de tiempo de las entradas, hashes de contenido, estructura de los documentos (cuántas entradas tiene cada uno), patrones de acceso (cuándo sincronizan los usuarios)
• No visible: el contenido de los documentos, los nombres de usuario, las claves de cifrado, el contenido de los adjuntos

Los hashes de contenido revelan cuándo dos entradas contienen los mismos datos cifrados (para deduplicarlos). Es un compromiso aceptado a cambio de eficiencia en el almacenamiento.

Revocar a un usuario bloquea toda sincronización futura y rechaza sus cambios posteriores. Sin embargo, los datos ya sincronizados en su dispositivo siguen siendo accesibles: ningún sistema puede garantizar el borrado en un dispositivo que nunca vuelve a conectarse. Mitigación: usa claves con nombre para los documentos sensibles (radio de impacto menor) y rota las claves cuando alguien deja el equipo. Haven Enterprise añade a esas mismas políticas de gobernanza un borrado remoto del dispositivo firmado por el administrador: el tenant se elimina de un dispositivo robado o dado de baja la próxima vez que se conecta.

Varias claves por usuario (firma, cifrado, claves simétricas con nombre) exigen una distribución segura. Mitigación: una sola contraseña desbloquea todas las claves mediante PBKDF2 con sales distintas. El KeyBag ofrece un almacén de claves unificado. El flujo de solicitud y respuesta de unión se encarga del intercambio de claves para los usuarios nuevos. Haven Enterprise automatiza el trabajo del día a día: las políticas de distribución de claves firmadas por el administrador aprovisionan claves a usuarios y grupos — y las revocan de nuevo —, empaquetadas para cada destinatario, y cada cliente reconcilia su KeyBag en la siguiente sincronización.

Por defecto el servidor no puede consultar el contenido de los documentos porque solo ve texto cifrado. Todas las consultas se hacen en el cliente, con indexación incremental. Pero si tu caso necesita procesamiento en el servidor (por ejemplo, un sistema de reservas en línea o una web pública), puedes darle al proceso del servidor una clave de descifrado o compartir con él un subconjunto de los datos. Es una decisión de arquitectura consciente en cada despliegue: la confidencialidad es lo predeterminado, y el acceso del servidor se activa solo donde haga falta.

Una auditoría de seguridad completa identificó áreas por reforzar: limitación de peticiones en los endpoints, revocación de tokens JWT y rotación de la clave de administrador. Los cambios antedatados de usuarios revocados ya se evitan con recibos del testigo basados en una hora de confianza (consulta el modelo de control de acceso). La base criptográfica (Ed25519, AES-256-GCM, RSA-OAEP) es sólida. El refuerzo operativo está en marcha.