Arquitectura de Seguridad: La Pila Técnica Completa

Vaultaire usa AES-256-GCM para el cifrado autenticado de los índices de bóveda, las claves envueltas, los encabezados, el contenido, las miniaturas y los metadatos de los archivos. PBKDF2-HMAC-SHA512 deriva una clave de bóveda local a partir del patrón y de una sal común a todo el dispositivo guardada en Keychain. Esa clave de bóveda envuelve una clave maestra aleatoria aparte de 256 bits, que cifra los archivos mediante CryptoKit en el proceso de la aplicación.

La Pila Criptográfica

Vaultaire usa varios mecanismos criptográficos que trabajan juntos, cada uno elegido para una función concreta. PBKDF2 convierte una credencial humana en una clave de bóveda o de recuperación. AES-256-GCM protege los índices, los envoltorios, los metadatos, las miniaturas y el contenido de los archivos. Una clave maestra aleatoria separa el cifrado de archivos de larga duración de un patrón que se puede cambiar. Keychain y la protección de datos de iOS protegen la sal ligada al dispositivo y los registros de recuperación mientras el dispositivo está bloqueado. Ninguna clave de descifrado en poder del proveedor da al desarrollador acceso rutinario al texto sin cifrar de la bóveda.

No es complejidad por gusto. Cada capa cubre una superficie de ataque distinta. AES-256-GCM combina confidencialidad y autenticación, así que un texto cifrado modificado no pasa la verificación. PBKDF2 encarece la prueba de cada patrón o frase. Gracias a la clave maestra aleatoria, un cambio de patrón puede volver a envolver una clave en lugar de volver a cifrar cada archivo. La protección de datos de Keychain protege la sal y los registros de recuperación locales, y la aplicación reconoce que el cifrado simétrico ocurre en la memoria del proceso.

En conjunto, estas capas forman una arquitectura de defensa en profundidad, pero no todas son barreras independientes. Un patrón adivinado se puede comprobar con el nombre de archivo del índice y la autenticación de AES-GCM, y un dispositivo desbloqueado y comprometido puede observar claves o texto sin cifrar en el proceso de la aplicación. Por eso la arquitectura depende de la entropía de la credencial, del coste de PBKDF2, de la protección del dispositivo iOS y del manejo correcto del cifrado autenticado, además de la solidez del propio AES.

AES-256-GCM: Cifrado de Archivos

Cada foto, vídeo y documento guardado en Vaultaire se cifra con AES-256-GCM, el estándar de cifrado avanzado con una clave de 256 bits en modo Galois/Counter. Vaultaire también usa AES-GCM para los índices de bóveda, los encabezados de archivo, las miniaturas y los sobres de claves. El algoritmo y el tamaño de clave están estandarizados; la seguridad de Vaultaire sigue dependiendo del manejo de nonces, la gestión de claves, la solidez de las credenciales y la corrección de la implementación.

El “256” en AES-256 se refiere a la longitud de clave en bits. Una clave de 256 bits tiene 2²⁵⁶ valores posibles. Para ponerlo en perspectiva: hay unos 10⁸⁰ átomos en el universo observable. Si cada átomo fuera una supercomputadora probando mil millones de claves por segundo, ejecutándose desde el Big Bang, habrían explorado menos de una billonésima de una billonésima de un por ciento del espacio de claves. AES-256 no va a ser roto por fuerza bruta. No hoy. No en este siglo. No antes de que las estrellas se apaguen.

Por Qué Importa el Modo GCM

AES es un cifrado por bloques — cifra datos en fragmentos de 128 bits. El “modo” determina cómo se combinan esos fragmentos. GCM (Modo Galois/Counter) proporciona dos cosas que modos más simples como CBC no: cifrado paralelizado y autenticación incorporada.

La pieza de autenticación es crítica. GCM genera una etiqueta criptográfica para cada archivo cifrado. Esta etiqueta actúa como un sello de manipulación. Si incluso un solo bit del texto cifrado se modifica — ya sea por un actor malicioso o un sector de disco corrupto — la etiqueta de autenticación no coincidirá, y el descifrado fallará. No obtienes datos corruptos. Obtienes una señal clara de que algo está mal. Esta propiedad se llama cifrado autenticado, y previene toda una clase de ataques donde un adversario modifica datos cifrados para manipular la salida descifrada.

PBKDF2: Derivación de Claves

Vaultaire deriva claves distintas para funciones distintas. El patrón y la sal común a todo el dispositivo guardada en Keychain pasan por PBKDF2-HMAC-SHA512 durante 600.000 iteraciones para producir la clave local de la bóveda. Una derivación determinista a partir del patrón produce la clave independiente de copia de seguridad en la nube. La frase de recuperación normalizada pasa por 800.000 iteraciones de PBKDF2 para producir la clave de un sobre de recuperación. Ninguna de esas derivaciones convierte una credencial humana en 256 bits de entropía solo porque la salida mida 256 bits.

Cómo PBKDF2 Protege Tu Patrón

La idea central de PBKDF2 es un trabajo deliberado. Toma el patrón serializado o la frase normalizada y ejecuta cientos de miles de iteraciones de HMAC-SHA512. Un usuario legítimo paga ese costo una vez por cada intento de desbloqueo o recuperación. Un atacante lo paga por cada candidato, aunque el hardware en paralelo y las decisiones de implementación determinan la velocidad real de los intentos.

Vaultaire configura PBKDF2 con 600.000 iteraciones para las claves derivadas del patrón. Eso encarece cada intento, pero una estimación de ataque responsable debe indicar un tiempo medido por candidato y el hardware supuesto. A exactamente 1 ms por candidato, 1.000.000.000 de intentos en serie tardan unos 11,6 días, no años. La salida de 256 bits no amplía la entropía de un patrón predecible.

La derivación local del patrón usa una sal aleatoria criptográfica por dispositivo, guardada como elemento de Keychain WhenUnlockedThisDeviceOnly. La sal no es secreta y la comparten las bóvedas de ese dispositivo. Impide que una tabla creada para un dispositivo sirva directamente para otro dispositivo con una sal distinta, pero no obliga a un atacante a empezar de nuevo con cada bóveda del mismo dispositivo.

AES-256-GCM: Protección de metadatos

Cifrar contenido de archivos no es suficiente. Nombres de archivos, fechas de creación, dimensiones de miniaturas y estructura de la bóveda son todos metadatos — y los metadatos pueden ser tan reveladores como los datos mismos. Un archivo llamado “declaración-impuestos-2025.pdf” le dice a un atacante exactamente qué hay dentro incluso si el contenido está cifrado. Una marca de tiempo muestra cuándo usaste la bóveda. Un tamaño de miniatura revela si algo es una foto o un vídeo.

Vaultaire protege estos metadatos con AES-256-GCM, no con ChaCha20. Los nombres de archivo y los tipos MIME van codificados en encabezados de archivo cifrados. El índice cifrado de la bóveda contiene los registros de archivos, las fechas, la información de tamaño, la organización del almacenamiento y la clave maestra envuelta. Los datos de las miniaturas también se cifran con la clave maestra aleatoria.

¿Por qué el cifrado autenticado para metadatos?

Los metadatos necesitan integridad además de confidencialidad. AES-GCM produce una etiqueta de autenticación para cada valor cifrado, así que Vaultaire puede rechazar un encabezado, índice, miniatura o sobre modificado en lugar de aceptar texto sin cifrar controlado por un atacante. El diseño usa a propósito una sola construcción de cifrado autenticado en todos estos formatos de almacenamiento, en lugar de afirmar una diversidad criptográfica que la implementación no ofrece.

Usar el mismo cifrado no significa reutilizar a ciegas la misma clave o el mismo nonce. La clave de la bóveda protege el índice y envuelve la clave maestra aleatoria; la clave maestra protege el material de los archivos. CryptoKit crea cajas selladas autenticadas con nonces nuevos, y el formato por flujo de Vaultaire deriva un nonce distinto para cada fragmento ordenado. Las garantías vienen de la separación de claves, la disciplina con los nonces y la autenticación, no de un segundo cifrado para los metadatos.

Arquitectura de Conocimiento Cero

Hay una pregunta que conviene hacerse sobre cualquier app de seguridad: ¿qué pasa si la empresa que hay detrás sufre un ataque, recibe una orden judicial o simplemente actúa de mala fe?

Con la mayoría de las apps, la respuesta es incómoda. Tienen tus datos, tus claves, o ambos. Una orden judicial las obliga a entregarlos. Una brecha de datos los expone. Un empleado deshonesto accede a ellos. La seguridad de la app solo es tan fuerte como la seguridad operativa de la empresa, y la historia muestra que las empresas sufren brechas con frecuencia.

Vaultaire no opera ninguna cuenta ni servicio de almacenamiento que reciba tu patrón, tu frase secreta, tus claves de descifrado o el contenido legible de la bóveda. El cifrado y el descifrado ocurren en el proceso de la aplicación, en tu dispositivo. Cuando la copia de seguridad en iCloud está activada, la aplicación envía texto cifrado autenticado a tu base de datos privada de CloudKit, no a un servicio de bóvedas controlado por Vaultaire.

Qué Significa Conocimiento Cero en la Práctica

Si una autoridad envía a Vaultaire una orden judicial que exige el texto sin cifrar de una bóveda, la empresa no tiene el patrón, la frase de recuperación, la clave de bóveda, la clave de copia de seguridad ni la clave maestra necesarios para descifrarlo. Los registros cifrados de iCloud están en la base de datos privada de CloudKit del usuario. En el dispositivo, sin embargo, el material de recuperación se guarda en una base de datos cifrada de Keychain, y las claves simétricas existen en la memoria de la aplicación mientras CryptoKit cifra o descifra una bóveda abierta.

Este límite del proveedor es una propiedad de la arquitectura, no la promesa de que todo el entorno del cliente quede fuera del modelo de confianza. Vaultaire no tiene en ningún servidor una clave de descifrado que pueda entregar para recuperar una bóveda de forma rutinaria. La aplicación publicada, iOS, el dispositivo desbloqueado y la implementación criptográfica pueden seguir procesando datos legibles, así que hay que confiar en ellos.

Keychain y el límite del proceso de la aplicación

El Secure Enclave de Apple puede proteger las claves privadas compatibles y participa en partes de la arquitectura de seguridad de la plataforma, pero sus API públicas no aceptan una clave simétrica arbitraria derivada con PBKDF2 ni ejecutan dentro del coprocesador las operaciones AES-GCM de Vaultaire sobre los archivos. Por eso Vaultaire no describe su cifrado de bóveda como AES del Secure Enclave.

Vaultaire usa elementos normales de contraseña genérica de iOS Keychain para la sal aleatoria del dispositivo, la base de datos de recuperación cifrada y la clave aleatoria que protege esa base de datos. Estos elementos usan la clase de accesibilidad WhenUnlockedThisDeviceOnly. Keychain y la protección de datos crean un límite importante en el dispositivo, sobre todo con el teléfono bloqueado, pero esta arquitectura es distinta de una clave no exportable del Secure Enclave.

Cuando dibujas el patrón, CommonCrypto deriva la clave de bóveda en el proceso de la aplicación. Después, CryptoKit y el CryptoEngine de Vaultaire usan los bytes de la clave simétrica en ese proceso para autenticar y descifrar el índice, desenvolver la clave maestra y procesar los archivos. La aplicación borra el estado activo cuando se bloquea, pero un atacante con privilegios suficientes que observe una sesión desbloqueada tiene una oportunidad distinta de la de un examinador que solo tiene el texto cifrado de un dispositivo bloqueado.

Un sistema operativo con jailbreak o comprometido de otra forma puede afectar a la entrada del patrón, la memoria de la aplicación, las vistas previas descifradas, las exportaciones o la pantalla. Vaultaire recomienda un iPhone actualizado y sin jailbreak porque el diseño se apoya en el aislamiento de procesos de iOS, Keychain y la protección de datos. No afirma que un compromiso con acceso root deje inaccesibles las claves simétricas de una bóveda abierta.

Vectores de Inicialización por Archivo

Si cifras dos archivos idénticos con la misma clave, una implementación ingenua produciría el mismo texto cifrado. Eso es un problema. Un atacante que ve dos bloques cifrados idénticos sabe, sin descifrar nada, que los dos archivos originales son iguales. En una bóveda llena de fotos, este tipo de análisis de patrones puede revelar información incluso a través del cifrado.

Vaultaire evita el texto cifrado determinista generando un nonce criptográfico nuevo en cada operación de sellado AES-256-GCM. Los encabezados y el contenido de los archivos se sellan por separado, y los archivos grandes usan un formato por flujo autenticado con un nonce base aleatorio y un nonce distinto para cada fragmento ordenado. Por eso dos copias de la misma foto no producen la misma representación cifrada.

Los nonces se guardan junto al texto cifrado y no son secretos; su requisito de seguridad es ser únicos para una clave dada. Vaultaire pide nonces de 96 bits al generador aleatorio criptográfico de Apple para el cifrado de una sola operación y registra el nonce base en el encabezado del formato por flujo. El riesgo de colisión depende del número de cifrados con una misma clave, así que la implementación genera un valor nuevo en lugar de presentar el tamaño de 96 bits como una garantía fija de una entre 2⁹⁶ durante toda la vida útil.

Gestión de memoria: se descarta el estado activo de las claves

Un fallo habitual en el software de seguridad es dejar datos sensibles en memoria cuando ya no se necesitan. Las claves de cifrado, las contraseñas derivadas y los datos descifrados pueden quedarse en la RAM mucho después de que la app haya terminado de usarlos. Las herramientas forenses pueden volcar la memoria del dispositivo y buscar esos restos, una técnica conocida como ataque de arranque en frío o análisis de volcado de memoria.

Vaultaire limita el tiempo durante el que siguen disponibles el estado activo de las claves y los datos descifrados de la interfaz. Cuando la app se bloquea o se cierra la sesión, su código sigue varias rutas de limpieza:

• Se descarta el estado activo de la bóveda. La app elimina su sesión actual de clave de bóveda y exige otro desbloqueo antes de mostrar contenido de la bóveda.
• Los envoltorios de claves borran los búferes propios. Los contenedores de bytes seguros de Vaultaire sobrescriben los búferes que les pertenecen cuando se liberan.
• Se invalida el estado de la clave maestra en caché. La clave maestra descifrada que se guarda para el índice abierto se descarta en las rutas de bloqueo y de reinicio de caché correspondientes.
• Se borran las cachés descifradas de la interfaz que controla Vaultaire. La limpieza de miniaturas y vistas previas reduce el estado residual de la aplicación, sin afirmar que controle cada copia creada por Swift, iOS u otro proceso.

La próxima vez que Vaultaire se abra bloqueado, dibujas el patrón y la app vuelve a derivar la clave de bóveda antes de poder autenticar el índice y desenvolver la clave maestra. Es una limpieza de sesión, no la afirmación de que cada copia transitoria en memoria recibió un borrado demostrable de varias pasadas ni de que se destruyó una referencia a una clave del Secure Enclave. Si la app se cierra de forma inesperada, iOS recupera el proceso, pero el código de limpieza no puede ejecutarse después de cada cierre abrupto.