Desde Linux 6.9, `luksSuspend` de LUKS dejó de borrar las claves de cifrado de disco de la memoria

Naturaleza de la regresión

• Desde Linux 6.9, cryptsetup luksSuspend ya no borraba de forma fiable las claves de los volúmenes LUKS de la RAM al suspender, aunque a los usuarios se les seguía pidiendo la frase de contraseña al reanudar.
• El error se originó en un cambio en la vida útil del keyring del kernel: se esperaba que las claves almacenadas en un keyring de hilo desaparecieran cuando el hilo terminara, pero dejaron de hacerlo, dejando una copia adicional de la clave del volumen en la memoria del kernel.
• Esto hacía que los sistemas que creían estar “extra seguros al suspender” fueran menos seguros de lo previsto, aunque parecieran funcionar con normalidad.

Suspender vs hibernar y modelo de amenaza

• Suspensión a RAM: la RAM (incluidas las claves de disco) sigue alimentada; la mayoría de los sistemas no borran las claves LUKS, así que el cifrado de disco protege principalmente discos apagados o extraídos.
• Hibernación a disco: el contenido de la RAM (incluidas las claves) se escribe en un intercambio/imagen cifrado y la RAM se apaga; al reanudar, los usuarios vuelven a introducir las frases de contraseña.
• Algunos sostienen que solo la hibernación (o apagar siempre el equipo) protege de forma significativa contra ataques de arranque en frío; otros señalan que la viabilidad del ataque depende mucho del modelo de amenaza.

Arranque en frío y acceso físico

• Con acceso físico a un portátil suspendido y bloqueado, los atacantes pueden:
  • Realizar ataques de arranque en frío (reinicio rápido en un sistema operativo personalizado, o enfriar la RAM y transferirla).
  • Usar DMA o técnicas similares en sistemas mal configurados.
• Varios comentarios recalcan que esto es relevante sobre todo para objetivos de alto valor o estatales, no para ladrones normales.

Soluciones temporales y mitigaciones

• Se discutieron las mitigaciones recomendadas:
  • Usar hibernación en lugar de suspensión; algunos usuarios de Fedora hibernan automáticamente tras un tiempo de espera de suspensión.
  • Activar el cifrado de memoria de la CPU (funciones de Intel/AMD) cuando esté disponible, aunque esto principalmente contrarresta ataques físicos a la RAM, no el uso lógico indebido de las claves.
  • Usar funciones de EFI/TPM como MemoryOverwriteRequest para asegurar que la RAM se borre al reiniciar.

Alcance y particularidades de las distribuciones

• luksSuspend pertenece a cryptsetup aguas arriba; Debian añadió una integración que lo vincula con la suspensión, y se informó de que este enfoque se había portado a otras distribuciones.
• La regresión afectó a configuraciones que dependían de la semántica de luksSuspend, no a los sistemas estándar de “solo suspender”.

Comparaciones y temas más amplios de seguridad

• Larga digresión comparando BitLocker, FileVault, LUKS y VeraCrypt:
  • A las empresas les gusta la facilidad de administración de BitLocker, especialmente con TPM+PIN y depósito de claves.
  • Los usuarios preocupados por la privacidad desconfían del cifrado propietario y del depósito de claves en la nube.
• Varios comentarios destacan:
  • El código abierto es más auditable, pero no está automáticamente auditado.
  • La falta de pruebas de integración robustas permitió esta regresión; añadir una prueba dedicada se considera la verdadera solución a largo plazo.