La protección comienza antes de la carga
El contenido de los archivos, los nombres de los archivos, los tipos MIME, las miniaturas, los nombres de las bóvedas y los nombres y la estructura de las carpetas se cifran en su dispositivo antes de cargarse. El servicio almacena texto cifrado y claves envueltas. Un intruso que obtiene solo esos registros almacenados no obtiene la clave de la bóveda en texto sin formato, el secreto del dispositivo ni su clave de recuperación.
Esto supone que el navegador, el sistema operativo, el código de la aplicación entregada y el generador de números aleatorios son confiables al crear o desbloquear una bóveda. El cifrado en reposo no puede proteger una bóveda desbloqueada del código malicioso que se ejecuta en su dispositivo.
Claves independientes para cada bóveda
Cada bóveda comienza con una clave maestra AES de 256 bits generada aleatoriamente. La clave la genera el generador criptográfico de números aleatorios del navegador, en lugar de derivarse directamente de su gesto. Las claves de bóveda independientes limitan el efecto de la divulgación de una única clave de bóveda.
Un patrón de dispositivo combina la secuencia de puntos ordenada con un secreto de dispositivo aleatorio de 256 bits. PBKDF2 con HMAC-SHA-256, una nueva sal de 128 bits y 600.000 iteraciones deriva una clave de envoltura de 256 bits. Luego, AES-256-GCM cifra la clave maestra bajo esa clave de envoltura. El servicio recibe el contenedor cifrado, su sal y los parámetros de derivación públicos. El secreto del dispositivo permanece en la base de datos local IndexedDB de este navegador.
Los patrones utilizan sólo una cuadrícula de 5 × 5 y al menos seis puntos distintos. Los formatos de patrones anteriores no son compatibles. Las bóvedas existentes necesitan sus claves de recuperación para registrar un nuevo patrón. El tamaño de la cuadrícula no es una promesa de seguridad de la contraseña: los gestos predecibles son aún más fáciles de adivinar. El secreto del dispositivo agrega protección contra alguien que solo tiene los registros del servidor, pero no es una clave respaldada por hardware. Alguien que copie tanto el secreto local como el contenedor puede intentar adivinar patrones fuera de línea.
Las claves de acceso autentican su cuenta mediante respuestas de desafío de clave pública. La autenticación de la cuenta no deriva una clave de bóveda ni descifra sus archivos. Una sesión de cuenta válida y un desbloqueo exitoso de la bóveda son requisitos separados en el flujo de solicitud normal.
| Objetivo | Construcción |
|---|---|
| Llave maestra de la bóveda | Clave aleatoria AES de 256 bits |
| Envoltura de llaves | PBKDF2-HMAC-SHA-256 · 600.000 iteraciones · Sal de 128 bits → AES-256-GCM |
| Metadatos y miniaturas | AES-256-GCM · nonce aleatorio de 96 bits · etiqueta de autenticación de 128 bits |
| Derivación de clave de archivo | HKDF-SHA-256 · salt aleatorio de 256 bits por archivo · salida AES de 256 bits |
| Secreto de recuperación | 192 bits aleatorios, mostrados como seis grupos de caracteres hexadecimales |
Confidencialidad y detección de manipulaciones
Los metadatos de la bóveda, los metadatos de los archivos, las miniaturas y las claves empaquetadas utilizan AES-256-GCM con etiquetas de autenticación de 128 bits. Cada cifrado independiente utiliza un nuevo nonce aleatorio de 96 bits. El descifrado verifica la etiqueta antes de devolver texto sin formato; El texto cifrado modificado o una clave incorrecta hacen que falle la autenticación.
Los datos autenticados adicionales vinculan cada objeto cifrado con su versión de formato, identificador de almacén, identificador de objeto y propósito. Por ejemplo, un registro de metadatos de archivo y miniatura utiliza contextos diferentes. Mover un objeto cifrado a una bóveda diferente o sustituirlo por otro objeto cambia el contexto autenticado y falla la verificación.
El contexto autenticado no oculta los identificadores y no demuestra su frescura. Un registro anterior válido todavía puede tener una etiqueta válida. Las comprobaciones de revisión de aplicaciones detectan actualizaciones simultáneas ordinarias, pero esto no es una defensa criptográfica contra un servicio malicioso que reproduce un estado completamente antiguo.
Los archivos grandes utilizan segmentos autenticados
El contenido del archivo utiliza la construcción de transmisión AES-256-GCM-HKDF-SHA-256 descrita por Tink, implementada mediante primitivas criptográficas del navegador. Cada nueva secuencia de archivos tiene un encabezado de 40 bytes que contiene su marcador de longitud, un salt aleatorio de 32 bytes y un prefijo nonce aleatorio de 7 bytes.
HKDF deriva una clave de cifrado de archivos independiente de la clave maestra del almacén. Su contexto incluye los identificadores de archivo y bóveda, la longitud de bytes de texto sin formato y el tamaño de segmento configurado. El nonce de 12 bytes de cada segmento combina el prefijo aleatorio, un contador de segmento de cuatro bytes y un indicador de segmento final. Los segmentos llevan etiquetas GCM de 128 bits.
La aplicación procesa archivos en segmentos acotados de aproximadamente 5 MiB. Las posiciones de los segmentos, el indicador del segmento final y las longitudes de bytes esperadas hacen que los segmentos intercambiados, alterados o truncados no superen la verificación. Las descargas autentican cada segmento antes de publicarlo; un error en una secuencia tardía puede dejar una descarga incompleta, por lo que es importante completarla correctamente. Los reintentos de carga reutilizan bytes ya cifrados en lugar de cifrar contenido nuevo con el mismo segmento nonce.
La construcción sigue el Especificación de transmisión Tink AES-GCM-HKDF. La implementación y la configuración del segmento de Revault no han sido auditadas ni certificadas de forma independiente por Tink.
La recuperación es un segundo camino hacia la misma clave.
Un secreto de recuperación se genera a partir de 24 bytes aleatorios, lo que da 192 bits de entrada aleatoria. Obtiene de forma independiente una clave de encapsulación utilizando PBKDF2-HMAC-SHA-256 y su propio salt, y cifra la misma clave maestra de bóveda con AES-256-GCM. Cualquiera que obtenga el secreto de recuperación y una copia de la bóveda cifrada puede descifrar esa bóveda.
El secreto de recuperación se muestra durante la instalación y el servicio no lo almacena en texto sin formato. Manténgalo separado de sus archivos cifrados. Al borrar los datos del navegador se elimina el secreto del dispositivo; recuperar el acceso requiere la copia cifrada en la nube de su cuenta y la clave de recuperación, o una copia de seguridad cifrada exportada y su clave de recuperación. No existe una clave maestra de descifrado en poder del proveedor.
Un kit de recuperación contiene un secreto y envoltorios de claves, pero ningún contenido de archivo. Una copia de seguridad cifrada contiene un inventario autenticado y segmentos de archivos cifrados, sin el secreto del dispositivo del navegador. La importación verifica los datos cifrados y crea una nueva bóveda con nuevos identificadores y claves.
Cambiar un patrón reemplaza el envoltorio de este dispositivo. No rota la clave maestra de la bóveda, no revoca otro dispositivo, no invalida las copias de seguridad antiguas ni cambia un secreto de recuperación existente. Si una clave de almacén o un secreto de recuperación se ve comprometido, mueva los datos a un nuevo almacén con claves nuevas.
Los recursos compartidos nativos utilizan cifrado independiente
Las comparticiones móviles envuelven por defecto las claves de las versiones elegidas con una nueva clave de compartición y reutilizan los archivos cifrados. El aislamiento adicional opcional vuelve a cifrarlos. Las claves del origen siguen privadas. El cifrado idéntico permite correlacionar comparticiones; ningún modo puede recuperar una copia guardada por el destinatario.
iOS puede colocar este texto cifrado en una jerarquía de registros CloudKit separada con una invitación privada de solo lectura. No comparte la zona de sincronización de la bóveda. Los recursos compartidos nativos multiplataforma utilizan partes de servidor limitadas con sumas de comprobación SHA-256. Las capacidades de administración y lectura aleatorias independientes de 256 bits se almacenan como hashes en el servidor. El secreto de descifrado se pasa por separado y nunca se carga. Las acciones controladas vencen en el momento elegido por el remitente, dentro de los 30 días. El servicio cuenta atómicamente las sesiones de acceso y aplica el máximo, el vencimiento y la revocación elegidos. Una sesión de descarga dura como máximo 15 minutos y nunca supera el vencimiento del recurso compartido.
Los receptores autentican cada segmento cifrado y abren una bóveda compartida aislada con el secreto separado del remitente. No se requiere cuenta, bóveda personal o patrón. Las bóvedas personales permanecen cerradas. Cuando se permite la exportación, los destinatarios pueden guardar una copia cifrada .qvault que se abre con ese secreto compartido. De lo contrario, no existen controles de exportación. La sesión temporal valida el acceso continuo. Estos son controles de la aplicación: las capturas de pantalla, los clientes modificados y las copias retenidas no se pueden evitar criptográficamente. Los recursos compartidos son instantáneas sin actualizaciones continuas de fuentes. Las invitaciones sin restricciones CloudKit no imponen recuentos de acceso ni caducidad automática; el acceso dura hasta que el propietario deja de compartir. La eliminación de un original no revoca su participación separada y ninguna revocación puede recuperar una copia ya retenida.
Actividad de bóveda opcional
Los registros de auditoría nativos están desactivados de forma predeterminada y configurados por almacén en cada dispositivo. Los últimos 500 eventos locales se cifran con la clave maestra de la bóveda y un contexto autenticado dedicado. Excluyen claves, patrones, contenidos de archivos y otros datos de bóvedas, no se sincronizan y se pueden borrar o deshabilitar. No son pruebas a prueba de manipulaciones. Los desbloqueos fallidos no se asignan a una bóveda.
Los nuevos recursos compartidos controlados creados con el registro habilitado conservan hasta 100 marcas de tiempo de sesiones de acceso en el servicio compartido. Sólo la capacidad de gestión puede recuperarlos; el registro no contiene ninguna identidad del destinatario ni secreto de descifrado. Deshabilitar el registro local afecta las acciones futuras. Los registros compartidos existentes conservan su configuración original hasta su revocación o vencimiento y limpieza.
Fotos de robo cifradas opcionales
Los propietarios pueden habilitar las alertas de robo por separado para cada bóveda en cada dispositivo. Después de tres patrones inigualables, la aplicación de primer plano puede capturar una foto de la cámara frontal, sujeta a permiso, disponibilidad de la cámara y un tiempo de reutilización de un minuto. Los indicadores de la cámara del sistema permanecen visibles. Las diez alertas más recientes se almacenan localmente y nunca se agregan a Fotos ni se cargan. Un patrón no coincidente no identifica una bóveda de destino, por lo que cada bóveda habilitada recibe un registro de intento de dispositivo cifrado por separado.
Una clave pública RSA-3072 dedicada envuelve una clave nueva de 256 bits AES-GCM para cada alerta usando OAEP con SHA-256 y MGF1-SHA-256. Esto permite el cifrado mientras la bóveda está bloqueada. La clave privada correspondiente está cifrada bajo la clave maestra de esa bóveda con un contexto autenticado dedicado. Sólo desbloquear esa bóveda puede descifrar sus fotos. Las alertas aparecen en su vista de auditoría independientemente del registro de actividad normal y se pueden borrar en la configuración de Alertas de intrusión. No son pruebas a prueba de manipulaciones.
Cargas cifradas a su propio depósito
La configuración de almacenamiento de una bóveda puede conectar este navegador directamente a un punto final HTTPS compatible con S3 especificado por el usuario. Los archivos del dispositivo seleccionado se cifran localmente utilizando la misma construcción de archivo. Cada uno se convierte en un objeto .qvault portátil e independiente que contiene un inventario cifrado autenticado y claves de bóveda empaquetadas. Los nombres de objetos aleatorios evitan exponer los nombres de archivos originales. La restauración requiere el objeto descargado y la clave de recuperación del almacén.
La configuración y las credenciales del punto final se cifran bajo la clave maestra de la bóveda con un contexto autenticado dedicado y se guardan en el IndexedDB de este dispositivo. No se sincronizan ni se envían a la API de Revault. La firma de solicitudes utiliza AWS Signature versión 4, HMAC-SHA-256 y un hash de cada cuerpo de solicitud limitado. Las partes multiparte de ocho MiB transportan bytes ya cifrados directamente al proveedor de almacenamiento. El acceso al depósito sigue regido por los permisos de ese proveedor y la política CORS.
El proveedor puede ver identificadores de claves de acceso, rutas de objetos, tamaños de bytes, tiempos de carga e información de conexión. Mantenga el depósito privado y sus credenciales limitadas a las operaciones requeridas. Los objetos cargados son independientes de la sincronización y el uso compartido en la nube Revault. Intentos de bloqueo o cancelación para cancelar cargas no finalizadas; El cierre de pestañas o la pérdida de conectividad pueden dejar piezas huérfanas, así que configure una regla de ciclo de vida de carga incompleta. Safe Exit elimina las credenciales de almacenamiento local de otras bóvedas, pero no elimina objetos de sus depósitos.
Safe Exit elimina el acceso local
Puede designar una bóveda en este navegador como bóveda Safe Exit. Al ingresar el patrón de esa bóveda, se abre normalmente, sin una confirmación de activación ni un aviso de finalización. Se eliminan las instantáneas locales, los fragmentos cifrados, los secretos de dispositivos y los cambios en cola de otras bóvedas. Los datos no sincronizados se pueden perder.
Un límite local persistente evita que esas bóvedas se incluyan o restauren automáticamente mediante sincronización en este navegador. Sus copias cifradas en la nube y en otros dispositivos permanecen sin cambios. La recuperación es explícita, un almacén a la vez, y requiere la clave de recuperación de ese almacén antes de que se pueda inscribir un nuevo patrón de dispositivo.
Se trata de una eliminación de acceso local, no de un borrado físico garantizado ni de un ocultamiento forense. Los perfiles del navegador, las instantáneas del sistema de archivos, las descargas anteriores, las capturas de pantalla, los registros de servicios y otros dispositivos pueden conservar pruebas. Al borrar los datos locales de este navegador también se borra el límite de aislamiento local; una instalación nueva puede enumerar las bóvedas en la nube de la cuenta nuevamente después de la autenticación.
Lo que queda visible
El cifrado protege el contenido, no todos los datos relacionados con el almacenamiento. El servicio puede observar asociaciones de cuentas, identificadores de objetos aleatorios, recuentos de objetos, tamaños de bytes, revisiones, marcas de tiempo, envoltorios cifrados, encabezados de flujo y actividad de solicitudes. Los registros operativos y de red pueden revelar información de conexión. Este no es un sistema de anonimato y no ofrece resistencia al análisis del tráfico.
El cifrado de transporte protege las solicitudes en tránsito cuando la aplicación se entrega a través de HTTPS. Esto es independiente del cifrado del lado del cliente que mantiene cifrado el contenido de los archivos almacenados en el servicio.
Donde termina la protección
La navegación privada suele eliminar el almacenamiento local cuando finaliza la sesión privada. Una solicitud de almacenamiento persistente no hace que una sesión de incógnito sea permanente. Las copias sincronizadas en la nube permanecen, pero se pueden perder los patrones locales, los cambios no sincronizados, los archivos en caché y la configuración de Safe Exit. Una nueva sesión privada necesita acceso a la cuenta y su clave de recuperación para registrar un nuevo patrón.
La aplicación elimina su referencia de clave de bóveda en memoria y revoca las URL de vista previa privadas cuando está bloqueada. Se bloquea automáticamente cuando está oculto o después de cinco minutos de inactividad. Las aplicaciones nativas también se bloquean cuando están en segundo plano, eliminan vistas previas temporales y borran los buffers de claves propios cuando finalizan las operaciones. La administración de memoria del navegador, Swift y JVM no puede garantizar el borrado inmediato de cada copia de clave o búfer de medios decodificados.
El malware, una extensión insegura, un código de aplicación comprometido o alguien que vea una pantalla desbloqueada pueden capturar texto sin formato y secretos. El cifrado no puede evitar la denegación de servicio de una cuenta, la eliminación de objetos en la nube, el ransomware, la pérdida de un secreto de recuperación o la retención de datos por parte de un servicio. Mantenga una copia de seguridad cifrada por separado y proteja el dispositivo.
Revault no se ha sometido a una auditoría de seguridad independiente. Estas son descripciones del diseño criptográfico implementado, no una certificación o garantía contra cualquier intrusión.