¿Cuál es una forma segura de solicitar una contraseña y luego borrar la contraseña almacenada en caché en Linux?

2

Por lo tanto, tengo varios discos duros cifrados con la misma contraseña y, en lugar de tener que ingresarlos varias veces, me gustaría configurarlo para que después del arranque se muestre automáticamente un cuadro de contraseña en el que ingresé la contraseña. una vez y que luego monta todas las unidades de disco duro cifradas y luego elimina de forma segura la contraseña de la memoria caché / memoria.

Es Parece que esto todavía no es posible a través de VeraCrypt estándar . Por lo tanto, parece que necesito escribir un script corto para obtener esta funcionalidad. Sin embargo, para eso necesito saber cómo solicitar una contraseña de forma segura y, lo que es más importante, cómo borrar de forma segura la contraseña almacenada en caché después de que se hayan montado los volúmenes.

Estoy usando Debian 9.1 con KDE.
(También me interesaría si hay alguna razón específica por la que esto no sea una característica estándar de VeraCrypt.)

    
pregunta mYnDstrEAm 25.08.2017 - 00:15
fuente

2 respuestas

4

No creo que puedas garantizar eso.

Entonces, supongamos que tiene un comando que toma la contraseña en un aviso, por ejemplo.

  

echo mypassword | cryptsetup luksOpen / dev / disk volume '

Y desea solicitar la contraseña una vez y abrir varios volúmenes:

#!/bin/sh
set -e
read -p "What's the password? " password || exit 1
for disk in disk1 disk2 disk3; do
   FOLDER=/media/$USER/$disk
   echo "$password" | cryptsetup luksOpen /dev/$disk $disk && \
   mkdir -p "$FOLDER" && \
   mount /dev/mapper/$disk "$FOLDER/$disk"
done
password="xxxxxxxxxxxxxxxxxxxxxx"

Este script de shell haría. Excepto que, después de que bash finalice, y la memoria se devuelva al sistema, no tenemos garantía de que la contraseña en sí no esté aún en la memoria (no, a pesar de la última declaración, es posible que su shell no sobrescriba la ubicación donde se guardó).

Por lo tanto, podríamos reescribir esto en C y asegurarnos manualmente de que dicha ubicación se sobrescriba, usando algo como memset_s (sí, un memset normal no funcionaría).

Aún así, podría haber copias de la contraseña de texto sin formato en los buffers de stdio, los utilizados por cryptsetup, etc. El kernel no entregará tales páginas a otros programas sin primero ponerlos a cero, pero si un investigador forense se congela la memoria Las ranuras con nitrógeno y su contenido de descarga, podría seguir estando allí.

Por otra parte, la clave del disco real (descifrada de la frase de contraseña) estará en la memoria, siempre que tenga los volúmenes montados. Por lo tanto, es probable que no valga la pena insistir en garantizar eso, y simplemente dejar que el programa finalice sería aceptable.

Yo sugeriría encriptar la partición del disco principal (y swap, por supuesto), y tener archivos de claves para cada uno de los otros discos allí (pueden ser legibles solo para root). Por lo tanto, solo necesita ingresar una contraseña (en el momento del arranque) y podrá descifrar todos los discos. No hay contraseñas cifradas que se establezcan cuando el sistema se apaga, y si un atacante consiguió su sistema raíz para poder robar sus archivos de claves, también podría acceder a los archivos directamente (y hacer muchas otras cosas desagradables). por lo que no hace las cosas mucho más inseguras.

El escenario principal para el que puedo pensar es donde se obtiene acceso repetido, por ejemplo. sus discos encriptados se clonan, y más tarde (después de haberles borrado algunos secretos), obtienen su contraseña / archivos de clave, por lo que pueden descifrar su copia anterior. Probablemente podrían hacerlo también extrayendo las claves de disco en la memoria, pero la existencia de los archivos de claves simplifica las cosas. (Para evitar esto, cambie sus contraseñas y archivos de claves y vuelva a crear la clave del disco después de eliminar la fórmula secreta de Coke)

Espero que esto ayude

    
respondido por el Ángel 25.08.2017 - 00:52
fuente
2

Parece que la configuración que deseas es similar a la mía, excepto que estoy usando LUKS. Por lo que sé, todo debería funcionar con VeraCrypt cambiando ligeramente los comandos y las opciones.

No especifica, pero parece que tiene un dispositivo raíz cifrado y uno o más dispositivos secundarios cifrados, si no, esto aún debería funcionar bien al elegir un dispositivo para usar como dispositivo principal.

Solía usar el script decrypt_derived de Debian, pero la última vez que lo verifiqué (hace más de un año) no funcionaba con el cryptsetup de systemd, así que tengo un archivo de claves en mi dispositivo raíz que se usa para descifrar el segundo dispositivo.

Para comenzar, asumo que tienes el dispositivo raíz descifrado y montado en / .

Crear archivo de claves aleatorias de 256 bits:

head -c 32 /dev/urandom | sudo tee /keyfile >/dev/null && sudo chmod 400 /keyfile

Agregar archivo de claves como clave a los dispositivos secundarios

sudo cryptsetup luksAddKey [device] /keyfile

Editar /etc/crypttab :

[primary device name]    UUID=[primary device uuid]    none        luks
[secondary device name]  UUID=[secondary device uuid]  /keyfile    luks,noearly

Desde man crypttab :

   noearly
       The cryptsetup init scripts are invoked twice during the boot process -
       once before lvm, raid, etc. are started and once again after that.
       Sometimes you need to start your encrypted disks in a special order. With
       this option the device is ignored during the first invocation of the
       cryptsetup init scripts.

Por lo tanto, los dispositivos secundarios se descifrarán después de que se haya montado el dispositivo principal y el archivo de claves esté disponible (siempre que su dispositivo principal esté listado en /etc/fstab correctamente).

No te olvides de actualizar initramfs para que los cambios de crypttab surtan efecto:

sudo update-initramfs -u -k all

Este enfoque tiene la ventaja de que systemd maneja la solicitud de la contraseña y no requiere que usted mantenga una secuencia de comandos. La desventaja es que hay un archivo de claves en uno de sus dispositivos, por lo que desmontar los dispositivos secundarios no evitará que alguien con root los descifre.

    
respondido por el AndrolGenhald 25.08.2017 - 17:29
fuente

Lea otras preguntas en las etiquetas