KEK y FEK explicadas: por qué importa el cifrado por archivo

Respuesta rápida. La KEK (Key Encryption Key, clave de cifrado de claves) y la FEK (File Encryption Key, clave de cifrado de archivos) forman una jerarquía de claves de dos niveles que usan las apps cifradas serias. La FEK, una clave aleatoria, cifra los datos; la KEK, derivada de tu contraseña, cifra («envuelve») la FEK. Este patrón, llamado cifrado de sobre (envelope encryption), lo usan Signal, BitLocker, AWS KMS y la protección de archivos de Apple, y en su forma de manual cada archivo tiene su propia FEK. Filarr usa los dos niveles de otra manera: una FEK aleatoria por cuenta, con la que se cifran tus archivos y tus notas, cada uno con un valor aleatorio nuevo. Cambiar tu contraseña solo vuelve a envolver esa FEK, y una copia robada de los datos del servidor no abre nada.

Cuando una app de notas cifrada dice «tus datos están cifrados con AES-256», hay una decisión de arquitectura oculta que importa más que el algoritmo: ¿cuántas claves hay y cómo están organizadas?

El diseño ingenuo usa una sola clave para todo: tu contraseña, estirada hasta convertirse en una clave maestra, cifra cada archivo. El diseño mejor usa dos niveles: una clave de datos aleatoria que cifra el contenido, envuelta por una clave derivada de tu contraseña. Se llama cifrado de sobre (envelope encryption), y los dos niveles tienen nombres concretos: KEK (Key Encryption Key) y FEK (File Encryption Key). En la disposición de manual, cada archivo tiene incluso su propia FEK.

Este artículo explica por qué existe el diseño de dos niveles, cómo funciona paso a paso, contra qué ataques defiende y cómo reconocer una app cifrada bien diseñada.

¿Qué son la KEK y la FEK?

Los términos proceden de los sistemas de gestión de claves y de la literatura sobre KMS en la nube. Las definiciones:

FEK (File Encryption Key): una clave simétrica aleatoria (normalmente de 256 bits) que cifra el contenido de los archivos. En la disposición de manual, cada archivo del sistema tiene su propia FEK única; algunos diseños, entre ellos el de Filarr, usan una sola FEK para toda una cuenta.
KEK (Key Encryption Key): una clave maestra, normalmente derivada de la contraseña del usuario, que cifra las FEK. La KEK nunca cifra directamente el contenido de los archivos.

En la disposición de manual, la organización es jerárquica: una KEK, muchas FEK.

                     Contraseña
                         │
                         ▼
                  KDF (PBKDF2 / Argon2id)
                         │
                         ▼
                  ╔══════════╗
                  ║   KEK    ║   ← solo vive en memoria
                  ╚══════════╝
                         │
                         │ cifra cada FEK
            ┌────────────┼────────────┐
            ▼            ▼            ▼
        ┌──────┐    ┌──────┐    ┌──────┐
        │ FEK1 │    │ FEK2 │    │ FEK3 │
        └──────┘    └──────┘    └──────┘
            │            │            │
            ▼            ▼            ▼
      ┌──────────┐ ┌──────────┐ ┌──────────┐
      │archivo 1 │ │archivo 2 │ │archivo 3 │
      │ cifrado  │ │ cifrado  │ │ cifrado  │
      └──────────┘ └──────────┘ └──────────┘

Cuando guardas un archivo:

Se genera una FEK aleatoria nueva
Se cifra el archivo con su FEK mediante AES-256-GCM
Se cifra la FEK con la KEK mediante AES-256-GCM
Se guarda el archivo cifrado junto a la FEK cifrada en el disco (o se sube a la nube)

Cuando lees un archivo:

Se usa tu contraseña para volver a derivar la KEK
Se descifra la FEK con la KEK
Se descifra el archivo con la FEK

La KEK solo vive en la memoria del proceso y se borra cuando bloqueas o cierras la app. Las FEK viven cifradas en el disco. La contraseña original no se guarda en ninguna parte.

¿Por qué no usar una sola clave global para todo?

El diseño de una sola clave parece más sencillo. Estiras tu contraseña hasta una clave maestra, cifras cada archivo con esa clave maestra y listo. ¿Para qué añadir una capa?

El diseño de una sola clave tiene tres problemas concretos.

1. El radio de alcance. Si un texto cifrado deja escapar la clave (por un fallo, un canal lateral o la reutilización de un nonce), todos los archivos cifrados con esa clave quedan expuestos. Con una FEK por archivo, que se filtre la clave de cifrado de un archivo solo expone ese archivo.

2. La rotación de claves es imposible. Con una sola clave global, rotar la clave (porque se sospecha que está comprometida) obliga a volver a cifrar todos los archivos. Es lento y arriesgado. Con KEK/FEK, puedes rotar la KEK y volver a envolver las FEK sin descifrar ni volver a cifrar nunca el contenido de los archivos.

3. Compartir de forma selectiva es imposible. Si quieres compartir un archivo con otro usuario, tendrías que compartir la clave maestra global, lo que le da acceso a todos tus archivos, para siempre. Con una FEK por archivo, compartes una sola FEK cifrada con la clave pública del destinatario. Recibe exactamente un archivo.

Estos problemas no son teóricos. La historia de los desastres criptográficos es, en buena parte, la historia de diseños de «una clave para todo» que fallaron estrepitosamente.

¿Qué significa cifrado de sobre?

«Cifrado de sobre» (envelope encryption) es el nombre que recibe el patrón KEK/FEK en el sector de la seguridad en la nube. La metáfora: cada archivo se sella en un sobre con su clave de datos particular (FEK), y ese sobre se mete a su vez en otro sobre sellado con una clave de cifrado de claves (KEK).

AWS KMS, Google Cloud KMS, Azure Key Vault y HashiCorp Vault implementan todos el cifrado de sobre. La KEK gestionada en la nube nunca sale de un módulo de seguridad de hardware; a la aplicación solo vuelven las FEK (cifradas con esa KEK).

Filarr usa el mismo patrón en tu dispositivo: tu contraseña deriva la KEK, la KEK solo vive en memoria y envuelve una única FEK, la clave de tu cuenta, con la que se cifran tus archivos y tus notas (detalles más abajo).

¿Cómo se generan realmente la KEK y la FEK?

Las dos mitades usan métodos de generación distintos porque tienen requisitos distintos.

Generación de la FEK: aleatoriedad criptográficamente segura. Una FEK es un valor aleatorio de 256 bits obtenido del generador de números aleatorios seguro del sistema operativo (crypto.randomBytes en Node, getRandomValues en los navegadores, /dev/urandom en Linux, BCryptGenRandom en Windows). En la disposición de manual, cada archivo nuevo recibe una FEK nueva; en Filarr, cada cuenta. En ambos casos, la FEK nunca se deriva de nada: es aleatoriedad pura.

Generación de la KEK: función de derivación de claves. La KEK se deriva de la contraseña del usuario mediante una función lenta diseñada para resistir los ataques de fuerza bruta. Se usan habitualmente dos funciones:

PBKDF2-SHA-512, con sal por usuario, con al menos las 210 000 iteraciones que recomienda OWASP para SHA-512 (600 000 es su cifra para SHA-256).
Argon2id con al menos 64 MB de coste de memoria, 3 iteraciones y 4 líneas de paralelismo. La buena práctica actual (RFC 9106).

Argon2id es la opción preferida para los diseños nuevos porque es de memoria intensiva (memory-hard), lo que hace que la fuerza bruta con GPU y ASIC sea muchísimo más cara que con PBKDF2. Muchas apps cifradas siguen usando PBKDF2 por compatibilidad con las bibliotecas existentes, a veces junto a Argon2id como defensa en profundidad.

¿Contra qué ataques defiende el diseño KEK/FEK?

Una buena forma de evaluar cualquier arquitectura criptográfica es recorrer escenarios de ataque concretos.

Ataque 1: se expone la clave de un archivo. Un fallo en la aplicación escribe brevemente una FEK en un registro en disco. Un atacante con acceso al disco lee el registro. Lo que obtiene: el contenido de un archivo. Lo que no obtiene: la clave maestra ni ningún otro archivo. El diseño de una sola clave suspende esta prueba de forma catastrófica.

Ataque 2: un usuario comparte un archivo. Con una FEK por archivo, compartir significa cifrar una FEK con la clave pública del destinatario. El destinatario obtiene acceso a un archivo, nada más. Con una sola clave global, no puedes compartir nada sin compartirlo todo.

Ataque 3: el usuario cambia su contraseña. Con KEK/FEK, derivas una KEK nueva a partir de la nueva contraseña y vuelves a envolver cada FEK con ella. No se toca ningún contenido de archivo. La operación es rápida (milisegundos) y atómica. Con una sola clave, hay que volver a cifrar cada archivo desde cero: un proceso destructivo, lento y propenso a errores.

Ataque 4: se compromete el servidor en la nube. El atacante lee todos los blobs cifrados del disco. Lo que obtiene: texto cifrado + FEK cifradas. Lo que no obtiene: la KEK (solo está en la memoria de tu dispositivo), así que no puede descifrar las FEK y, por tanto, no puede descifrar nada.

Ataque 5: recuperación forense de un archivo borrado. Con una FEK por archivo, puedes «triturar» un archivo borrando solo su FEK. El contenido cifrado del archivo se vuelve ilegible para siempre, aunque los bytes sigan en el disco. Con una sola clave, borrar solo los metadatos de un archivo deja que se pueda seguir descifrando: el borrado seguro exige sobrescribir los bytes.

En todos los escenarios, el diseño de dos niveles se comporta mejor que el de una sola clave.

¿Tiene este patrón otros nombres?

Sí. El mismo patrón de arquitectura aparece en muchos sitios con nombres distintos:

Envelope encryption (cifrado de sobre): AWS, Google Cloud, Azure
Key wrapping (envoltura de claves): terminología del NIST
DEK + KEK: «Data Encryption Key» en lugar de «File Encryption Key»
Clave maestra + claves de archivo: la protección de archivos de Apple en iOS / macOS
Vault key + record keys: 1Password
VMK + FVEK: Microsoft BitLocker (Volume Master Key + Full Volume Encryption Key)

Todos son el mismo patrón: una clave maestra que cifra claves de datos, y son las claves de datos las que tocan los datos. Los nombres cambian, pero la estructura es constante.

¿Cómo saber si una app de notas usa cifrado por archivo?

Al evaluar una app de notas o de almacenamiento de archivos cifrada, busca estas señales:

Documentación de arquitectura que mencione la envoltura de claves, el cifrado de sobre o las claves por archivo. Una app seria explica públicamente cómo organiza su cifrado. Si la documentación solo dice «AES-256», es una afirmación de marketing, no una arquitectura.
Informes de auditoría independientes. Los auditores indicarán explícitamente si se usan claves por archivo. Que aparezcan «KEK y FEK» en un informe de auditoría es una señal positiva clara.
La posibilidad de compartir de forma selectiva. Si la app permite compartir archivos sueltos sin dar al destinatario acceso a toda tu bóveda, es casi seguro que usa claves por archivo. Los diseños de una sola clave no pueden compartir de forma selectiva.
Un cambio de contraseña rápido. Si cambiar tu contraseña maestra tarda segundos y no obliga a volver a cifrar toda tu biblioteca, el diseño usa envoltura de claves (se actualiza la KEK; las FEK y los archivos no se tocan).
Código abierto. Con el código fuente público, puedes verificar la arquitectura directamente. Busca términos como wrapKey, wrappedFek, unwrapKey, kekId o keyEncryptionKey.

¿Cómo implementa Filarr la KEK/FEK?

Filarr usa los dos niveles, con una diferencia respecto a la disposición de manual: la FEK es la clave de tu cuenta, no la clave de un solo archivo.

Derivación de la KEK. Tu contraseña pasa por PBKDF2-SHA-512 (600 000 iteraciones, muy por encima de las 210 000 que recomienda OWASP para PBKDF2-SHA512) para producir una KEK de 256 bits. La KEK solo vive en la memoria del proceso; nunca se escribe en disco en claro.
Generación de la FEK. Cada cuenta, o cada perfil local, recibe una FEK aleatoria de 256 bits del generador aleatorio seguro del sistema operativo. La FEK nunca se deriva de tu contraseña.
Cifrado de los archivos. Tus archivos y tus notas se cifran con AES-256-GCM con la FEK, con un valor aleatorio nuevo (el nonce, o IV) para cada archivo y cada cifrado. Dos formatos van un paso más allá y derivan de la FEK una clave propia, con HKDF y una sal aleatoria: los archivos grandes importados en el escritorio y los bloques sincronizados. Consulta qué es AES-256-GCM para saber por qué importa este modo.
Envoltura de la FEK. La FEK se cifra con la KEK mediante AES-256-GCM, y una segunda vez con tu frase de recuperación (24 palabras en una cuenta en la nube). En una cuenta en la nube, el servidor conserva las dos copias envueltas, para que un dispositivo nuevo pueda abrir tus datos.
Aislamiento entre perfiles. Cada perfil local de Filarr tiene su propia FEK y su propia KEK, derivada de una contraseña distinta. La KEK del perfil A no puede descifrar la FEK del perfil B, aunque los dos pertenezcan al mismo usuario.
Subida a la nube. Cuando la sincronización en la nube está activada, Filarr sube los blobs de los archivos cifrados, y el servidor conserva la FEK envuelta. Una copia robada de los datos del servidor no abre nada sin tu contraseña o tu frase de recuperación. Iniciar sesión tampoco entrega lo necesario para reconstruir la KEK: desde el 16 de octubre de 2026, una app actualizada envía una clave derivada de tu contraseña con una sal distinta, no la propia contraseña. Durante una transición de unos dos meses, una cuenta que todavía no ha vuelto a iniciar sesión, o una versión antigua de la app, sigue enviando la contraseña (por HTTPS), donde un servidor comprometido podría capturarla.

Frente a los ataques anteriores, esta disposición te da dos cosas. Un cambio de contraseña solo vuelve a envolver la FEK, así que es instantáneo y no toca ningún archivo (ataque 3). Una copia robada de los datos del servidor da texto cifrado y claves envueltas, nada legible (ataque 4). Lo que no te da es un radio de alcance limitado a un archivo: la FEK abre toda la cuenta, y por eso no sale nunca de tu dispositivo en claro y solo se guarda envuelta (ataque 1). Compartir tampoco depende de una FEK por archivo: un enlace compartido lleva una clave exclusiva después del #, y una bóveda compartida tiene una clave exclusiva, sellada para cada miembro (ataque 2).

Lee la arquitectura de seguridad completa de Filarr para conocer los parámetros exactos y el modelo de amenazas.

Para saber más

NIST SP 800-38F: Methods for Key Wrapping, el estándar del cifrado de sobre
RFC 9106: Argon2 password hashing, la KDF moderna
OWASP Password Storage Cheat Sheet, las recomendaciones actuales
Qué es AES-256-GCM y por qué importa
El cifrado zero-knowledge, explicado
Cifrado de extremo a extremo vs zero-knowledge
¿Qué es el software local-first?
La arquitectura de seguridad de Filarr