¿Qué es el cifrado de conocimiento cero? Una guía sencilla
El cifrado de conocimiento cero significa que el proveedor no puede acceder a tus datos.
El cifrado de conocimiento cero es una arquitectura limitada por el proveedor en la que el servicio no posee la clave necesaria para descifrar el contenido almacenado del usuario. A diferencia del cifrado estándar en la nube, donde el proveedor controla la clave de contenido, el cifrado del lado del cliente puede mantener esa capacidad en los dispositivos de los usuarios. Una solicitud legal, una infracción o información privilegiada aún pueden exponer texto cifrado, registros de cuentas, datos de tráfico u otros metadatos que conserva el proveedor. La guía de administración de claves del NIST hace que la custodia de claves sea central para el acceso, pero la aplicación del cliente, el sistema operativo y el dispositivo desbloqueado siguen siendo parte del límite de confianza.
Cómo funciona el cifrado de conocimiento cero
La analogía más sencilla: una caja fuerte de hotel donde solo tú estableces la combinación, y el hotel nunca la conoce. Si olvidas la combinación, el hotel no puede abrir la caja fuerte por ti. Eso no es un defecto en el diseño. Ese es el diseño.
En términos técnicos, el cifrado de conocimiento cero funciona a través de tres pasos:
Derivación de claves en el dispositivo. El usuario proporciona una credencial, como una contraseña, una frase de contraseña o un patrón. Una función de derivación de clave basada en contraseña la combina con una sal para producir una clave en el dispositivo del usuario. Un diseño bien separado puede usar esa clave para desbloquear una clave de cifrado de contenido aleatoria en lugar de cifrar cada archivo directamente con la credencial humana.
Cifrado antes de la transmisión. Todos los datos se cifran en el dispositivo usando la clave derivada antes de que salgan del dispositivo para el almacenamiento en la nube o la copia de seguridad. La salida cifrada (texto cifrado) es lo que se sube.
El proveedor no recibe ninguna clave de contenido en texto plano. Las claves de contenido existen necesariamente en la memoria del cliente durante el uso y también pueden almacenarse local o remotamente dentro de sobres cifrados autenticados. El proveedor puede almacenar texto cifrado y claves envueltas sin mantener el secreto de usuario necesario para abrirlas. Es posible que los metadatos de la cuenta, el tráfico, el tamaño de los registros y el tiempo sigan siendo visibles.
La restricción crítica: si el usuario pierde todas las credenciales válidas y la ruta de recuperación, el contenido cifrado se vuelve inaccesible. La recuperación aún puede existir, pero es necesario explicar su custodia clave. Si un restablecimiento de correo electrónico por sí solo restaura contenido legible sin una aprobación del dispositivo antiguo, una frase de recuperación, una clave de recuperación o un secreto equivalente en poder del usuario, el proveedor ha conservado una ruta efectiva de regreso al texto sin formato.
Cifrado de conocimiento cero vs. otros tipos de cifrado
El término "cifrado" aparece en los materiales de marketing de casi todos los servicios en la nube. Las diferencias entre tipos son sustanciales.
| Tipo | Quién tiene la clave | El proveedor puede leer los datos | Sobrevive a brecha del proveedor | Ejemplo |
|---|---|---|---|---|
| Sin cifrado | N/A | Sí | No | Dropbox (nivel estándar) |
| Cifrado en tránsito (TLS) | Proveedor | Sí (en reposo en sus servidores) | No | Google Photos |
| Cifrado en reposo del lado del servidor | Proveedor | Sí (tienen la clave de descifrado) | Parcialmente (depende del alcance de la brecha) | iCloud (estándar) |
| Cifrado de plataforma de extremo a extremo | Dispositivos cliente y sistema de recuperación de cuentas. | No a través de la ruta de servicio normal | Depende del cliente, la recuperación y la exposición de metadatos. | iCloud con protección de datos avanzada |
| Cifrado del lado del cliente ciego al proveedor | Ruta de recuperación controlada por el cliente y el usuario | Sin clave de contenido de texto plano retenida por el proveedor | El contenido puede permanecer cifrado; Los metadatos y el texto cifrado aún pueden filtrarse | Bóveda cifrada y sistemas de respaldo |
La distinción entre "cifrado en reposo" y "cifrado de conocimiento cero" es la más confundida comúnmente. Con el cifrado en reposo, el proveedor cifra tus datos en sus servidores usando claves que controlan. Esto protege contra el robo físico del hardware del servidor. No protege contra el proveedor leyendo tus datos, una citación judicial por los datos y las claves, o una amenaza interna. El proveedor tiene la capacidad de descifrado.
Con el cifrado del lado del cliente ciego al proveedor, el servicio no recibe la clave de contenido de texto sin formato a través del protocolo documentado. El texto cifrado almacenado puede permanecer opaco para ese proveedor, mientras que el software del cliente, la ruta de recuperación, los metadatos de la cuenta y el canal de entrega del software aún requieren confianza y revisión.
Por qué importa el cifrado de conocimiento cero
Las brechas de datos exponen miles de millones de registros anualmente
El Centro de recursos sobre robo de identidad informó 3205 violaciones de datos en los Estados Unidos en 2023, que afectaron a aproximadamente 353 millones de personas. Cuando un proveedor posee claves de contenido, una infracción puede exponer tanto los datos almacenados como una ruta para descifrarlos. El cifrado ciego al proveedor separa esos activos: una vulneración del servidor aún puede exponer el texto cifrado y los metadatos, pero no una clave de contenido de texto plano en poder del proveedor. La adivinación de credenciales y el compromiso del cliente siguen siendo riesgos separados.
La compulsión legal es una amenaza real
Se puede exigir a los proveedores que revelen los datos que conservan. Un diseño ciego al proveedor puede limitar esa respuesta al texto cifrado y a los metadatos disponibles de cuenta, tráfico, facturación o servicio porque el proveedor no posee la clave de contenido de texto sin formato. Si otra parte puede obtener una credencial de usuario, explotar a un cliente u obligar a revelar información es una cuestión aparte. Apple introdujo la protección de datos avanzada en iOS 16.2 como una expansión opcional del cifrado de extremo a extremo para iCloud datos.
"Confía en nosotros" no es una arquitectura de seguridad
El cifrado del lado del servidor se basa en políticas y claves controladas por el proveedor. El cifrado ciego al proveedor cambia la custodia de la clave, por lo que la ruta de servicio documentada carece de una clave de contenido de texto sin formato. Se trata de un límite arquitectónico más fuerte, pero su fuerza aún depende del código de cliente correcto, la entrega de software autenticado, la recuperación de sonido, los dispositivos seguros y una implementación que coincida con la especificación.
El estándar NIST detrás de la criptografía
AES-GCM fue estandarizado por el Instituto Nacional de Estándares y Tecnología en SP 800-38D (2007). La propia AES fue seleccionada por el NIST a través de un concurso público en 2001. El "256" en AES-256 se refiere a una clave de 256 bits. La búsqueda exhaustiva de una clave uniformemente aleatoria es computacionalmente inviable, pero una contraseña o patrón humano puede proporcionar mucha menos entropía incluso cuando una función de derivación de clave genera 256 bits.
GCM (modo Galois/Counter) añade cifrado autenticado, lo que significa que el proceso de descifrado detecta cualquier manipulación del texto cifrado. Si se altera un solo bit de los datos cifrados, el descifrado falla en lugar de producir una salida corrupta. Esto evita que los atacantes manipulen datos cifrados sin ser detectados.
PBKDF2 (Función 2 de derivación de clave basada en contraseña), especificada en RFC 8018, convierte una credencial proporcionada por un ser humano en material de clave de longitud fija mediante llamadas repetidas a funciones pseudoaleatorias. Más iteraciones aumentan el costo de cada suposición. No añaden entropía a un patrón o contraseña predecible, por lo que la elección de credenciales y la verificación fuera de línea siguen siendo importantes.
Cómo implementa Vaultaire la separación de claves de proveedor
bóveda es una bóveda cifrada del lado del cliente para iPhone. En el sentido del producto que a menudo se comercializa como "conocimiento cero", su afirmación documentada más limitada es que Wraxle no recibe el contenido de la bóveda en texto sin formato ni las claves necesarias para descifrarlo. Así es como funcionan la implementación y los límites de confianza restantes en cada capa.
Derivación de claves. El usuario dibuja un patrón en una cuadrícula de 5x5 de 25 puntos. PBKDF2-HMAC-SHA512 combina esa secuencia con una en todo el dispositivo Keychain salt durante 600.000 iteraciones para derivar una clave de bóveda de 256 bits. La clave del almacén autentica el índice cifrado y envuelve una clave maestra aleatoria independiente de 256 bits. La información de recuperación, incluido el patrón, se almacena en un AES-GCM cifrado Keychain base de datos en lugar de archivos de texto sin formato o una cuenta de Vaultaire.
Cifrado de archivos. Cada archivo importado se cifra con AES-256-GCM bajo la clave maestra aleatoria. CryptoKit crea cajas selladas autenticadas con nonces nuevos, y el formato de transmisión deriva un nonce distinto para cada fragmento ordenado.
Cifrado de metadatos. nombres de archivos, MIME tipos, fechas, registros de índice y datos en miniatura también están protegidos con AES-256-GCM. Vaultaire no utiliza ChaCha20 para los metadatos de la bóveda.
Gestión de claves. Vaultaire almacena la sal de su dispositivo y la base de datos de recuperación cifrada como de costumbre iOS Keychain elementos con contraseña genérica protegidos con la WhenUnlockedThisDeviceOnly clase de accesibilidad. Las claves de bóveda derivadas de patrones y las claves maestras aleatorias se procesan en la memoria de la aplicación a través de CryptoKit. El bloqueo elimina el estado de clave activa, pero Swift y iOS no admiten la garantía de que se sobrescriba cada copia transitoria.
Descubrimiento de bóveda. La interfaz normal no muestra una lista de bóvedas. El formato local almacena exactamente 1 archivo de índice cifrado para cada bóveda y el código de mantenimiento puede enumerar esos archivos. Por lo tanto, alguien con acceso al contenedor de aplicaciones puede contar índices cifrados, aunque los nombres de archivos no revelan patrones, nombres o contenidos de texto sin formato. Ver el completo arquitectura de seguridad y explicación de cifrado de patrón.
Cómo saber si una app usa cifrado de conocimiento cero real
Comience con tres pruebas rápidas y luego verifique la arquitectura publicada:
La prueba de contraseña olvidada. Si el restablecimiento del correo electrónico por sí solo restaura datos legibles, pregunte qué mecanismo del proveedor recuperó la clave de contenido efectiva. Las frases de recuperación retenidas por el usuario, la aprobación de dispositivos antiguos y los restablecimientos controlados por el proveedor son diseños diferentes.
La prueba del nuevo dispositivo. Si un nuevo dispositivo restaura contenido legible, identifique el dispositivo secreto o confiable que lo autorizó. El inicio de sesión en la cuenta por sí solo sugiere una ruta de recuperación controlada por el proveedor; una frase de recuperación más registros de respaldo cifrados pueden preservar la separación de la clave del proveedor.
La prueba de la cuenta. Una dirección de correo electrónico o un número de teléfono vincula la identidad con los metadatos del servicio, pero por sí solo no prueba que el proveedor pueda descifrar el contenido. Inspeccione la jerarquía de claves, el diseño de recuperación, el código o auditoría del cliente, la política de metadatos y si el texto cifrado autenticado permite verificaciones de credenciales fuera de línea.
Estas pruebas son filtros, no una prueba de seguridad. Una especificación coherente debe nombrar la clave de contenido, la clave de desbloqueo, las sales, los parámetros de derivación, el formato de cifrado autenticado, las reglas nonce, los sobres de recuperación, el almacenamiento secreto local, los metadatos de la nube y el punto donde existen las claves de texto sin formato. La revisión independiente es una evidencia más sólida que la etiqueta de un producto.
Preguntas frecuentes
¿Es el cifrado de conocimiento cero lo mismo que el cifrado de extremo a extremo?
Se superponen pero no son idénticos. El cifrado de extremo a extremo (E2EE) significa que los datos se cifran en el dispositivo del remitente y se descifran solo en el dispositivo del destinatario. El cifrado de conocimiento cero significa que el proveedor no puede acceder a los datos. Un servicio puede ser cifrado de extremo a extremo sin ser de conocimiento cero si el proveedor generó o tiene acceso a las claves en algún momento. El cifrado de conocimiento cero es el estándar más estricto.
¿Qué pasa si pierdo mi contraseña con cifrado de conocimiento cero?
Sus datos se vuelven permanentemente inaccesibles si se pierden todas las credenciales válidas y el sobre de recuperación. Un restablecimiento o una clave maestra controlados por el proveedor debilitarían los límites del proveedor, por lo que la recuperación debe diseñarse por separado. bóveda genera una frase personalizada que contiene 9 palabras separadas cuya clave de recuperación derivada abre un sobre de clave de bóveda cifrada. La frase no regenera ni codifica la clave, y la restauración de un nuevo dispositivo también requiere la clave cifrada correspondiente. CloudKit registros.
¿Pueden las fuerzas del orden acceder a datos cifrados con conocimiento cero?
Es posible que un proveedor tenga que revelar el texto cifrado almacenado y los metadatos de cuenta, tráfico, facturación o servicio que conserva. Sin una clave de contenido de texto plano en poder del proveedor, ese proveedor no puede utilizar su ruta de servicio normal para descifrar el contenido. La explotación de dispositivos, el descubrimiento de credenciales, las copias de recuperación y la divulgación obligatoria son rutas separadas cuya legalidad y efectividad varían según la jurisdicción y los hechos.
¿Es el cifrado de conocimiento cero más lento que el cifrado regular?
AES-256-GCM El rendimiento no depende de quién tiene la llave. La derivación basada en contraseña agrega trabajo durante el desbloqueo y su duración depende del algoritmo, el recuento de iteraciones, el dispositivo y la implementación. Las aplicaciones deben medir ese costo en el hardware compatible y equilibrar la capacidad de respuesta con el costo impuesto en cada conjetura fuera de línea.
¿El conocimiento cero significa que la app no recopila ningún dato en absoluto?
No necesariamente. El término aborda el límite de clave de contenido del proveedor, no todos los flujos de datos. Una aplicación aún puede procesar datos de cuentas, análisis, informes de fallas, direcciones IP, tamaños de registros, tiempos u otros metadatos de servicios. Vaultaire no requiere una cuenta de identidad y dice que sus análisis basados en el consentimiento excluyen los contenidos, patrones, frases y claves de descifrado de la bóveda; es política de privacidad describe las reglas actuales de recopilación y retención.
¿Cómo se compara el cifrado de conocimiento cero con la Protección de Datos Avanzada de Apple?
La Protección Avanzada de Datos (ADP) de Apple, introducida en iOS 16.2, extiende el cifrado de extremo a extremo a más iCloud categorías y utiliza el modelo de recuperación de cuentas de Apple. Vaultaire mantiene el contenido de la bóveda local de forma predeterminada y no requiere una cuenta de identidad de Vaultaire; copia de seguridad, sincronización y uso compartido opcionales cifrados del lado del cliente CloudKit registros en la cuenta de Apple del usuario. Vaultaire también ofrece acceso a la bóveda separado por patrones y modo de coacción, con los límites de almacenamiento y recuperación descritos en su documentación de negación plausible.
Resumen
El cifrado de conocimiento cero se trata mejor como un reclamo de separación de claves del proveedor: el servicio no contiene la clave de texto plano necesaria para descifrar el contenido almacenado. Esto es más fuerte que el cifrado del lado del servidor bajo claves controladas por el proveedor, pero no es una afirmación de que las claves existan sólo en la memoria, que los metadatos desaparezcan o que se venza cada compromiso de cliente y dispositivo. Juzgue el producto por su jerarquía clave, diseño de recuperación, implementación y revisión independiente.