Cómo protegen las apps las claves de cifrado localmente

Categoría

Seguridad local

Publicado

septiembre 26, 2026

Tiempo de lectura

13 min de lectura

Las aplicaciones protegen las claves de cifrado localmente separando la clave que cifra un archivo del código y los datos que protege, y colocando después esa clave detrás de la seguridad del dispositivo. Un diseño habitual genera una clave aleatoria para cifrar el archivo, la guarda en el almacén de claves protegido del sistema operativo y la cifra —o la envuelve— con otra clave vinculada al dispositivo, a un PIN o a ambos. La biometría suele desbloquear el acceso a ese material protegido, en lugar de convertirse en la clave de cifrado. Este enfoque por capas implica que copiar solo un archivo cifrado no debería bastar para leerlo. También explica un límite importante: si un dispositivo se ve comprometido mientras está desbloqueado o el diseño de recuperación es débil, el cifrado local puede seguir fallando.

Para una base más amplia, lee qué es una clave de cifrado de archivos y para qué sirve. La protección de las file encryption keys se explora en un artículo dedicado. En resumen, la diferencia entre clave y contraseña es que una clave realiza el bloqueo criptográfico, mientras que una contraseña o un PIN normalmente controla el acceso a esa clave.

La mayoría de las aplicaciones bien diseñadas no cifran cada archivo directamente con un PIN. Un PIN corto tiene muy poca entropía para actuar por sí solo como clave de archivo segura a largo plazo, especialmente si un atacante puede realizar intentos ilimitados. En su lugar, las aplicaciones suelen combinar varias funciones:

• Clave de cifrado de archivo (DEK): un secreto aleatorio que cifra el archivo o la base de datos local.
• Clave de cifrado de claves (KEK): una clave independiente que cifra, o envuelve, la clave de cifrado del archivo.
• Almacenamiento seguro: un servicio protegido del sistema operativo que guarda o controla el uso de claves sensibles.
• PIN o código de acceso: una prueba de que la persona que abre la aplicación está autorizada para solicitar la clave.
• Verificación biométrica: un paso local y cómodo de aprobación, como la autenticación por huella o rostro, cuando el dispositivo lo admite.

Esta separación es útil porque los archivos pueden cifrarse con una clave aleatoria robusta, mientras el usuario conserva una forma práctica de desbloquear la aplicación. También permite cambiar un PIN o revocar una sesión sin tener que volver a cifrar necesariamente todos los archivos protegidos.

La envoltura de claves consiste en cifrar una clave con otra clave. Puede entenderse como colocar una clave pequeña y muy valiosa dentro de un contenedor cerrado, en vez de intentar volver a bloquear cada documento con un secreto de usuario distinto.

Por ejemplo, una aplicación puede crear una clave aleatoria para cifrar un documento privado. Después cifra esa clave aleatoria con una clave vinculada al dispositivo y conservada en el almacenamiento seguro. La aplicación guarda el documento cifrado y la clave de archivo envuelta. Cuando el usuario autorizado abre el documento, el sistema operativo permite utilizar la clave vinculada al dispositivo para desenvolver la clave de archivo, que entonces puede descifrar el documento.

La envoltura de claves aporta ventajas prácticas:

• La clave de archivo puede ser aleatoria y robusta sin que el usuario tenga que recordarla.
• Una base de datos de archivos comprometida no expone automáticamente claves que puedan utilizarse.
• Una aplicación puede proteger por separado distintas claves de archivo y limitar el impacto de un problema con una de ellas.
• A menudo puede añadirse un nuevo método de acceso envolviendo de nuevo la misma clave de archivo, en lugar de volver a cifrar archivos grandes.

La envoltura no es un escudo mágico. Si un atacante obtiene la clave ya desenvuelta desde la memoria de un dispositivo desbloqueado y comprometido, o puede utilizar la misma ruta de autorización del almacenamiento seguro, la protección puede eludirse. El cifrado protege mejor los secretos cuando el dispositivo y sus controles de acceso siguen siendo fiables.

En teléfonos y ordenadores modernos, una aplicación debería evitar guardar una clave de cifrado sin proteger en un archivo de preferencias, un campo de base de datos ordinario, un registro, una copia de seguridad o el código fuente. En su lugar, puede pedir al sistema operativo que cree o proteja una clave en el almacén de claves de la plataforma. Según el dispositivo, las operaciones con claves pueden contar con apoyo de hardware diseñado para aislar el material sensible del almacenamiento habitual de las aplicaciones.

Los nombres concretos varían entre plataformas, pero el objetivo de diseño es coherente: la aplicación debería solicitar una operación criptográfica autorizada en lugar de leer libremente una clave maestra permanente en un archivo normal. El almacenamiento seguro también puede aplicar políticas como exigir que el dispositivo esté desbloqueado, requerir autenticación reciente del usuario o invalidar material protegido tras determinados cambios en la seguridad del dispositivo.

Para orientación práctica, consulta dónde guardar las claves de cifrado. Conservar el contenido cifrado y su clave utilizable en la misma ubicación sin protección anula buena parte del propósito del cifrado.

El almacenamiento de claves respaldado por hardware puede dificultar su extracción porque el material de la clave puede no ser exportable: el software puede pedir al hardware que descifre o firme, pero no recuperar simplemente los bytes secretos. Es una mejora relevante frente al almacenamiento local sin protección. Sin embargo, no protege frente a todos los riesgos, entre ellos el malware que actúa mientras el usuario está autenticado, un dispositivo robado y desbloqueado, vulnerabilidades de software o un atacante que conoce el código de acceso del dispositivo.

Un PIN puede añadir una capa de control independiente, pero los diseños seguros lo tratan con cuidado. En vez de convertir 1234 directamente en la clave de cifrado del archivo, una aplicación puede procesar el PIN mediante una función de derivación de claves basada en contraseña y una sal aleatoria única. La clave derivada resultante puede ayudar a desbloquear una clave de aplicación envuelta o autenticar una solicitud para utilizar material local protegido.

Una función de derivación hace deliberadamente más costoso cada intento. La sal garantiza que el mismo PIN no produzca el mismo resultado entre usuarios o dispositivos. Los límites locales de reintentos, las demoras progresivas y las políticas de hardware seguro pueden reducir aún más los intentos rápidos de adivinación. Estos controles importan porque un PIN se elige por comodidad, no por su fortaleza criptográfica.

La biometría normalmente funciona de forma distinta a una clave derivada de PIN. La aplicación recibe una señal de éxito o fallo del sistema biométrico del dispositivo; no debería recibir ni guardar una huella dactilar o una plantilla facial. En muchos diseños, una autenticación biométrica correcta autoriza al almacenamiento seguro a liberar o utilizar una clave protegida durante un tiempo limitado.

El siguiente marco es una lista ilustrativa para tomar decisiones, no una prueba de producto ni una auditoría de una aplicación concreta. Ayuda a distinguir una protección local significativa de afirmaciones vagas de que un archivo simplemente está «cifrado».

• Pregunta qué se cifra. ¿Solo se cifra la transmisión o también se cifran en reposo los archivos y el historial local del dispositivo?
• Pregunta dónde se guardan las claves utilizables. Busca almacenamiento seguro del sistema operativo o protección vinculada al dispositivo, no archivos de claves en texto plano.
• Pregunta qué desbloquea la clave. Un PIN, código de acceso y aprobación biométrica deberían controlar el acceso; no deben confundirse con la propia clave de archivo aleatoria.
• Pregunta por la resistencia a intentos sin conexión. Un diseño basado en PIN debería utilizar una sal, un método de derivación lento y controles de reintentos prácticos cuando sea posible.
• Pregunta por la recuperación y las copias de seguridad. Si se pierde el dispositivo, ¿puede el usuario recuperar los datos de forma segura? Si existe recuperación, ¿qué nueva relación de confianza o superficie de ataque introduce?
• Pregunta qué sucede en un dispositivo comprometido. La documentación de seguridad honesta reconoce que el cifrado local no puede proteger completamente los datos mientras un software malicioso tiene acceso a una sesión desbloqueada.

La privacidad no debería depender de que las personas recuerden un ritual complejo antes de cada envío. Los diseños cotidianos más robustos convierten el almacenamiento local protegido en la opción predeterminada, sin dejar de explicar claramente el compromiso que implica la recuperación.

Imagina que una aplicación almacena localmente un documento de identidad cifrado. El documento se cifra con una clave de archivo aleatoria. Esa clave se envuelve con una clave que el almacenamiento seguro del teléfono solo utilizará después de desbloquear el dispositivo y de que la aplicación reciba la aprobación de un PIN o de la biometría. Una persona que copie los archivos cifrados de la aplicación desde el teléfono perdido debería seguir sin disponer de la clave utilizable necesaria para descifrarlos.

Ahora cambia las condiciones: el teléfono fue robado mientras estaba desbloqueado, o el atacante conoce el código de acceso del dispositivo y puede abrir la aplicación. Es posible que el cifrado local ya no impida el acceso. Por eso pueden importar el código de acceso del dispositivo, el bloqueo automático, las actualizaciones oportunas del sistema operativo y un control de acceso a nivel de aplicación. El escenario ilustra compromisos de diseño; no describe un resultado medido ni garantiza protección frente a un ataque concreto.

Cuando una aplicación para compartir archivos conserva su historial operativo y sus datos sensibles principalmente en el dispositivo del usuario, la protección local de claves pasa a formar parte del modelo de privacidad, no es un detalle técnico secundario. Oblivio está diseñada en torno a datos locales cifrados, acceso protegido mediante PIN y, cuando el dispositivo lo admite, biometría. Su finalidad es reducir el esfuerzo de tratar los archivos sensibles de forma distinta a los adjuntos ordinarios.

Por ejemplo, enviar un documento mediante un canal genérico puede resolver la entrega, pero dejar al remitente con poco control después. Oblivio añade controles como acceso temporal, revocación, registros locales de los envíos y datos locales cifrados. No deben asumirse una jerarquía interna de claves ni detalles de implementación más allá del diseño documentado; para los usuarios, lo importante es que proteger un archivo incluye tanto la capa de cifrado como el modo de controlar el acceso a sus claves.

• Usar un PIN como único secreto de cifrado. Los PIN cortos necesitan límites de intentos y derivación de claves; las claves de cifrado aleatorias son más robustas para proteger archivos.
• Guardar claves junto a los archivos en texto plano. Una carpeta copiada no debería contener tanto el contenido cifrado como una clave inmediatamente utilizable.
• Registrar secretos. Los registros de depuración, informes de fallos, eventos de analítica y operaciones con el portapapeles pueden exponer material que el almacenamiento seguro debía proteger.
• Confundir biometría con cifrado. La biometría suele ser un mecanismo de aprobación, no el secreto empleado para cifrar el archivo.
• Añadir recuperación sin modelar el riesgo. Una clave de recuperación, custodia en la nube o un segundo dispositivo puede evitar el bloqueo, pero cada opción amplía quién o qué puede desbloquear los datos.
• Suponer que el cifrado detiene toda filtración. Un destinatario autorizado todavía puede copiar, fotografiar o divulgar el contenido. Los controles de acceso y el rastreo pueden aumentar la disuasión, pero no prometen un control total después de la visualización.

Si la pérdida de claves es tu principal preocupación, lee qué pasa cuando se pierde una clave de cifrado. Un cifrado sólido suele implicar que no existe un botón universal para restablecer el acceso, por lo que la planificación de la recuperación debe ser intencionada.

• Las aplicaciones protegen las claves de cifrado locales separando las claves de archivo de las credenciales de usuario y de los datos de la aplicación.
• La envoltura de claves cifra una clave de archivo con otra clave protegida y crea una capa útil de separación.
• El almacenamiento seguro del sistema operativo y los controles respaldados por hardware pueden dificultar de forma relevante la extracción de claves.
• Los PIN y la biometría normalmente autorizan el uso de una clave; no sustituyen a las claves de cifrado de archivo con alta entropía.
• Los dispositivos perdidos, los mecanismos de recuperación, las sesiones desbloqueadas y el malware siguen siendo límites importantes que conviene comprender.

Para comparar modelos locales y centrados en la nube, nuestra guía sobre cifrado en el dispositivo frente a cifrado en la nube explica dónde cambia de manos el control. Cuando un archivo necesita más que una entrega ordinaria, Oblivio ofrece un enfoque más controlado del acceso de los destinatarios, la duración y la revocación.