Mover / tmp a un tmpfs encriptado

Question

Mover / tmp a un tmpfs encriptado

#1 de Thomas Pornin (4 votos)

1

BLUF: Estoy usando un SSD en mi sistema, así que mi principal razón para usar tmpfs para aumentar la vida útil de mi unidad es mover los archivos de lectura / escritura a una memoria volátil. Pero desde el punto de vista de la seguridad, también me gustaría saber si tendría sentido cifrar la memoria volátil con fines de seguridad.

Especificaciones actuales del sistema:

OS:                 Custom Arch Linux Build

RAM:                6GB  
My build rarely goes over 1GB of RAM usage. 

Primary Drive:      128GB SSD 
    Holds the OS, setup with LUKS on LVM for full disk (-boot) encryption. 

Secondary Drive:    1TB HDD (much slower) 
    For long term storage and backup (fully encrypted).

Preocupación:

Tal como está una vez que mi sistema se apaga, un usuario necesita la clave para poder acceder al disco duro de mi sistema. Sin embargo, desde un punto de vista anti-forense, la RAM sería un objetivo viable para la recuperación durante al menos unos minutos después del cierre (posiblemente más tiempo con algo de piratería aérea).

Mi pregunta es: para evitar una recuperación de arranque en frío en este caso tan improbable, ¿sería una opción viable cifrar el contenido de tmpfs con algo como dm-crypt ?

Básicamente estoy pidiendo una comprobación de la lógica. ¿Qué agujeros posibles me faltan?

encryption linux memory

pregunta Jay Holister 13.05.2015 - 18:25

fuente

1 respuesta

Lea otras preguntas en las etiquetas encryption linux memory

¿Dónde comenzar con las pruebas de seguridad de la API? [cerrado] ¿Cómo pueden los piratas informáticos acceder a los nombres de usuario de WordPress? [duplicar]

score 4 · Answer 1

Si considera que los atacantes pueden recuperar el contenido de la RAM (un ataque de arranque en frío ), entonces debe tener en cuenta que los atacantes pueden recuperar el contenido de RAM . La aplicación usa su sistema de archivos /tmp como un repositorio temporal para algunos elementos de datos, pero las mismas aplicaciones lo leen nuevamente en la RAM. Es decir, es poco probable que el sistema de archivos basado en RAM contenga la única copia en RAM para los datos confidenciales. Cualquier cosa que haga con /tmp , ya sea encriptación o cualquier otra cosa, solo será una solución parcial.

Otro punto es que un sistema de archivos encriptado sigue siendo un almacenamiento para archivos, que el sistema en vivo puede leer y escribir. Por lo tanto, incluso si está cifrada, la clave de descifrado (en la máquina en vivo) debe estar en algún lugar en ella ... es decir, en la RAM. Si los atacantes pueden leer la RAM, pueden recuperar esa clave y eliminar todo su cifrado.

Lo que podría hacer para reducir la probabilidad de recuperación de datos por parte de los atacantes es asegurarse de vaciar la RAM como parte del procedimiento de apagado. Esto implicaría, desde el último proceso que se ejecuta en la máquina:

Desmontando /tmp .
Desactivando el espacio de intercambio (por cierto, ¿encripta su partición de intercambio? Alternativamente, podría simplemente desactivar el intercambio; lo hago en mi computadora portátil).
Llenar la RAM con bytes aleatorios (o ceros), asignar páginas y llenarlas hasta que la asignación falle. En ese momento, usted sabe que el kernel encontró toda la RAM disponible y la llenó con aleatoriedad; esto incluiría todas las páginas que correspondían a /tmp basado en RAM.

Por lo que explico anteriormente, tal procedimiento sería necesario de todos modos (ya que los datos confidenciales pueden estar fuera de /tmp ), y hace que cualquier cifrado de /tmp sea irrelevante.

Los problemas restantes son que la RAM que no es de la aplicación, en el espacio del kernel, podría necesitar una limpieza; y un procedimiento de apagado solo tiene efecto cuando se aplica un cierre. Si el atacante roba la máquina en vivo, entonces puede desconectar el enchufe (o la batería, para una computadora portátil) para obtener una instantánea nueva y en vivo de la memoria RAM. El cifrado no lo ayudaría allí (porque la clave de cifrado sería parte de la instantánea).