La Ilusión del Cifrado
Actualizado para 2026
En diciembre de 2022, LastPass informó a sus usuarios sobre una brecha. El mensaje fue tranquilizador: las contraseñas estaban "cifradas." El contenido de los cofres estaba "seguro."
Para 2025, más de 438 millones de dólares habían sido robados de usuarios de LastPass. El robo provino directamente de sus cofres supuestamente seguros.
¿Cómo? LastPass tenía las claves.
Su equipo de seguridad debe saber esto antes de elegir una herramienta en la nube. Se aplica a cualquier herramienta que maneje archivos sensibles — incluidas las plataformas de anonimización de PII.
Cifrado del Lado del Servidor vs. Arquitectura de Conocimiento Cero
La mayoría de las herramientas en la nube dicen que "cifran sus archivos." Pero usan cifrado del lado del servidor (SSE). Esto es lo que significa:
| Propiedad | Cifrado del Lado del Servidor | Arquitectura de Conocimiento Cero |
|---|---|---|
| Dónde ocurre el cifrado | En el servidor del proveedor | En su dispositivo (navegador/escritorio) |
| Quién tiene las claves | El proveedor | Solo usted |
| El proveedor puede leer su contenido | Sí | No |
| Una brecha expone archivos | Sí | No (solo texto cifrado) |
| El proveedor puede ser forzado a divulgar | Sí | No (no lo tiene) |
| Acceso de fuerzas del orden | Via el proveedor | No posible sin su clave |
LastPass tenía las claves. Ese fue el error fatal. Los atacantes entraron y obtuvieron tanto el texto cifrado como las herramientas para descifrarlo. Usaron ingeniería social, fuerza bruta sobre contraseñas débiles y metadatos de cuentas antiguas.
Por Qué Esto Importa para el Artículo 25 del RGPD
El artículo 25 del RGPD (Protección de datos desde el diseño) es claro. Los responsables del tratamiento deben usar "medidas técnicas y organizativas apropiadas." Estas deben estar integradas desde el principio.
El Comité Europeo de Protección de Datos (CEPD/EDPB) ha aclarado que esto incluye la minimización criptográfica de datos. El propio sistema debe bloquear el acceso a los registros. Los controles de acceso solos no son suficientes.
Un proveedor que tiene sus claves no puede cumplir el artículo 25 en su forma estricta. Aquí está el porqué:
- Una brecha del sistema podría exponer sus registros.
- Una citación al proveedor podría entregar su contenido.
- Un empleado malicioso podría ver sus archivos.
- Un ataque a la cadena de suministro podría exponer todo.
El Comisionado Federal Alemán para la Protección de Datos (BfDI) ha emitido orientaciones al respecto. También la Autoridad Austriaca de Protección de Datos (Datenschutzbehörde). Ambos dicen que el conocimiento cero es la mejor opción técnica para el procesamiento de alto riesgo.
La Realidad de las Brechas SaaS
El informe AppOmni / Cloud Security Alliance 2024 encontró un aumento del 300% en brechas de SaaS de 2022 a 2024. Los datos clave:
- Tiempo hasta la brecha: 9 minutos (antes se medía en horas)
- Participación de terceros en brechas: se duplicó año tras año (Verizon DBIR 2025)
- Brecha de Conduent: 25,9 millones de registros expuestos (números de seguridad social, archivos de salud)
- Brecha del proveedor del NHS: 9 millones de pacientes expuestos
Las promesas de política ya no son suficientes. La arquitectura sólida es el estándar mínimo. Esto se aplica a todo procesamiento de alto riesgo.
Cómo Se Ve la Verdadera Arquitectura de Conocimiento Cero
Un sistema de conocimiento cero real tiene estas características claras:
1. Derivación de clave del lado del cliente Su clave viene de su contraseña. Un KDF de uso intensivo de memoria (Argon2id, bcrypt o scrypt) se ejecuta en su dispositivo. La clave nunca lo abandona.
2. Cifrado del lado del cliente Su contenido se cifra antes de salir de su navegador o aplicación. El servidor solo recibe texto cifrado. Sin la clave, ese texto es inútil.
3. Sin almacenamiento de clave del lado del servidor El proveedor no guarda ninguna clave, ningún fragmento de clave y ninguna copia de seguridad de clave. Usted usa su propia frase de recuperación para recuperar el acceso.
4. Verificabilidad criptográfica El sistema debe estar bien documentado. Debe estar abierto a auditoría. Las vagas afirmaciones de "cifrado de extremo a extremo" sin detalles técnicos son una señal de alerta.
Cómo anonym.legal Implementa el Conocimiento Cero
El inicio de sesión de conocimiento cero de anonym.legal usa:
- Derivación de clave Argon2id: 64 MB de memoria, 3 iteraciones — la elección de OWASP para aplicaciones de alta seguridad
- Cifrado AES-256-GCM: Se ejecuta completamente en su navegador o aplicación de escritorio antes de que se envíe cualquier contenido
- Frase de recuperación BIP39 de 24 palabras: La única forma de restaurar el acceso — no almacenada por anonym.legal
- Cero acceso a claves del lado del servidor: Los servidores de anonym.legal solo reciben texto cifrado AES-256-GCM que no pueden descifrar
Una brecha completa del servidor de anonym.legal solo produciría blobs cifrados. Sin la clave de cada usuario — que vive solo en su dispositivo — estos blobs son inútiles.
Vea nuestra descripción general de seguridad y cumplimiento y documentación de cumplimiento para todos los detalles.
La Lista de Verificación del Proveedor
Cuando elige una herramienta en la nube para registros sensibles, haga estas preguntas:
Preguntas de arquitectura:
- ¿Dónde ocurre el cifrado — en su dispositivo o en el servidor del proveedor?
- ¿Quién crea las claves?
- ¿Dónde se almacenan las claves?
- ¿Puede el proveedor entregar copias de texto plano de su contenido en respuesta a una citación?
- ¿Qué pasa con sus archivos si el proveedor es adquirido?
Preguntas de resiliencia a brechas:
- Si el sistema del proveedor es completamente comprometido, ¿qué registros están expuestos?
- Si un empleado del proveedor actúa de forma maliciosa, ¿qué contenido puede ver?
- Si un ataque a la cadena de suministro afecta al proveedor, ¿qué está expuesto?
Preguntas regulatorias:
- ¿Puede el proveedor mostrar documentación para el artículo 25 del RGPD?
- ¿Ha revisado el sistema un auditor externo?
- ¿Existe una certificación ISO 27001 o SOC 2 que cubra el cifrado?
Cualquier proveedor que no pueda responder "cero — el contenido está cifrado antes de salir de su dispositivo" a las preguntas de brecha está usando cifrado del lado del servidor. Consulte nuestras preguntas frecuentes y glosario para más definiciones.
El Caso de Uso: Due Diligence de una Aseguradora de Salud Alemana
Un oficial de cumplimiento en una gran aseguradora de salud alemana (Krankenkasse) necesitaba una herramienta de anonimización en la nube. La tarea: procesar registros de quejas de asegurados. El DPO tenía cuatro requisitos:
- El proveedor no puede acceder a los registros de los asegurados
- Sin procesamiento fuera de Alemania
- Medidas técnicas del artículo 32 del RGPD documentadas
- El riesgo de brecha reportable a la APD está minimizado
Un gran SaaS de anonimización estadounidense falló en el primer punto. Su equipo de soporte podía restablecer los cofres de usuarios — prueba de acceso a claves del lado del servidor. Una segunda herramienta guardaba texto procesado durante 30 días para "rastro de auditoría" — nuevamente, acceso del lado del servidor.
anonym.legal cumplió los cuatro criterios. El DPO pudo escribir: "Incluso una brecha completa del proveedor no produce registros de asegurados utilizables — las claves solo existen en nuestras estaciones de trabajo." La documentación del artículo 32 del RGPD se completó en cuatro horas.
Vea nuestros estudios de caso para más ejemplos reales.
El Precedente de Aplicación del ICO
En diciembre de 2025, la Oficina del Comisionado de Información del Reino Unido multó a la entidad LastPass UK con £1,2 millones. La razón: "incumplimiento de implementar medidas de seguridad técnicas y organizativas apropiadas."
La multa no fue por la brecha en sí. Fue por las decisiones arquitectónicas que la hicieron tan dañina. Configuraciones KDF deficientes, metadatos expuestos y almacenamiento de claves del lado del servidor jugaron un papel.
Los reguladores ahora preguntan: ¿limitó el sistema el impacto de la brecha? La arquitectura de conocimiento cero responde eso claramente. Es la mejor prueba de esa intención.
Cuándo la Arquitectura de Conocimiento Cero No Es la Solución Correcta
El cifrado de conocimiento cero tiene compromisos. Estos importan para algunos casos de uso:
Complejidad de recuperación: Si los usuarios pierden sus claves, sus archivos se pierden para siempre. No hay puerta trasera. La alta rotación de personal o los malos hábitos de gestión de claves hacen que esto sea un riesgo real.
Fricción de colaboración: El contenido cifrado solo puede compartirse si la otra parte tiene las herramientas de descifrado correctas. Esto es más lento que un simple enlace compartido en aplicaciones en la nube estándar.
Casos límite regulatorios: Algunas regiones requieren acceso de las fuerzas del orden a los registros por orden judicial. Los sistemas de conocimiento cero bloquean esto por diseño. Eso puede causar problemas legales en servicios financieros o telecomunicaciones, donde aplican obligaciones de interceptación legal.
Sobrecarga computacional: La derivación de clave Argon2id y el cifrado AES-256-GCM añaden latencia. Esto importa más para el procesamiento en tiempo real de alto volumen.
Para equipos que procesan millones de documentos por día, un enfoque híbrido puede funcionar mejor. Cifre solo los campos más sensibles. Mantenga los metadatos accesibles. Vea los planes de precios para niveles de volumen.
Conclusión
"Ciframos sus archivos" no es una promesa de seguridad. Es una frase de marketing que necesita escrutinio.
Las preguntas reales son simples. ¿Quién tiene las claves? ¿Dónde ocurre el cifrado? ¿Qué está expuesto si los sistemas del proveedor son vulnerados?
Para equipos que procesan registros sensibles bajo RGPD, HIPAA o reglas similares, estas decisiones de arquitectura dan forma tanto a su riesgo legal como a su exposición real a brechas.
LastPass cifró el contenido de sus usuarios. La arquitectura de conocimiento cero habría convertido la brecha de 2022 en un no-evento. Los 438 millones de dólares robados de los usuarios fueron el costo de un atajo arquitectónico.
anonym.legal usa arquitectura de conocimiento cero para la anonimización de PII. La derivación de clave Argon2id se ejecuta en su navegador o aplicación de escritorio. El cifrado AES-256-GCM ocurre antes de que cualquier contenido salga de su dispositivo. Los servidores de anonym.legal almacenan solo texto cifrado que no pueden descifrar. Obtenga más información en nuestra página de información o explore el sistema de tokens.