Qual è un modo sicuro per richiedere una password e cancellare la password memorizzata nella cache in Linux?

2

Quindi ho più dischi rigidi crittografati con la stessa password e invece di doverli inserire più volte mi piacerebbe averlo configurato in modo tale che dopo l'avvio ottengo automaticamente una casella di password visualizzata nella quale inserisco la password una volta e che quindi monta tutti i dischi rigidi crittografati e in seguito rimuove la password dalla cache / memoria in modo sicuro.

sembra che questo non è ancora possibile tramite VeraCrypt standard . Quindi sembra che ho bisogno di scrivere un breve script per ottenere questa funzionalità. Tuttavia, per quello ho bisogno di sapere come richiedere in modo sicuro una password e, soprattutto, come cancellare in modo sicuro la password memorizzata dopo che i volumi sono stati montati.

Sto usando Debian 9.1 con KDE.
(Mi piacerebbe anche sapere se ci sono ragioni specifiche per cui questa non è una funzionalità di VeraCrypt standard.)

    
posta mYnDstrEAm 25.08.2017 - 00:15
fonte

2 risposte

4

Non credo che sarai in grado di garantirlo.

Quindi, supponiamo di avere un comando che richiede la password in un prompt, ad es.

echo mypassword | cryptsetup luksOpen /dev/disk volume'

E vuoi chiedere la password una volta e aprire diversi volumi:

#!/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"

Questo script di shell avrebbe funzionato. Tranne che, dopo il completamento di bash, e la memoria viene restituita al sistema, non abbiamo alcuna garanzia che la password stessa non sia ancora in memoria da qualche parte (no, nonostante quest'ultima dichiarazione la tua shell potrebbe non sovrascrivere la posizione in cui è stata salvata).

Quindi, potremmo riscrivere questo in C e assicurarci manualmente che tale posizione sia sovrascritta, usando qualcosa come memset_s (sì, un memset normale non funzionerebbe).

Tuttavia, ci potrebbero essere delle copie della password in chiaro nei buffer stdio, quelli usati da cryptsetup, ecc. Il kernel non darà tali pagine ad altri programmi senza prima azzerarli, ma se un investigatore forense è venuto a congelare la tua memoria slot con azoto e scaricando il contenuto, potrebbe essere ancora lì.

Inoltre, l'effettiva chiave del disco (decrittografata dalla passphrase) sarà in memoria fino a quando i volumi saranno montati. Quindi, probabilmente non vale la pena insistere per garantirlo, e lasciare che il programma finisca sarebbe accettabile.

Suggerirei di crittografare la partizione del disco principale (e lo scambio, ovviamente) e di avere i file di chiavi per ognuno degli altri dischi (possono essere letti solo per root). Pertanto, è sufficiente inserire una password (al momento dell'avvio) e sarà in grado di decrittografare tutti i dischi. Non ci sono password crittografate che escono quando il sistema è spento, e se un utente malintenzionato ha rootato il tuo sistema in modo che sia in grado di rubare i tuoi file di chiavi, potrebbe accedere direttamente ai file (e fare troppe cose brutte), quindi non rende le cose molto più insicure.

Lo scenario principale per cui posso pensare è dove si ottiene l'accesso ripetuto, ad es. i tuoi dischi criptati vengono clonati e in seguito (dopo averne sbrogliato alcuni segreti), ottengono i tuoi passphrase / keyfiles, in modo da poter decifrare la loro copia precedente. Probabilmente potrebbero farlo anche estraendo le chiavi del disco in memoria, ma l'esistenza dei file di chiavi rende le cose più semplici. (Per evitare ciò, modificare le password e i file di chiavi e reinserire il disco dopo aver rimosso la formula segreta di Coca Cola)

Spero che questo aiuti

    
risposta data 25.08.2017 - 00:52
fonte
2

Sembra che il setup che desideri sia simile al mio, tranne che sto usando LUKS. Per quanto posso dire tutto dovrebbe funzionare con VeraCrypt modificando leggermente i comandi e le opzioni.

Non lo specifichi, ma sembra che tu abbia un dispositivo root crittografato e uno o più dispositivi secondari crittografati, altrimenti non dovrebbe funzionare correttamente selezionando un dispositivo da utilizzare come dispositivo principale.

Ero solito usare lo script di decrypt_derived di Debian, ma l'ultima volta che ho controllato (più di un anno fa) non funzionava con cryptsetup di systemd, quindi ho un file di chiavi sul mio dispositivo di root che viene usato per decifrare il secondo dispositivo.

Per iniziare suppongo tu abbia decodificato il dispositivo root e montato a / .

Crea un file di chiavi casuale a 256 bit:

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

Aggiungi keyfile come chiave per i dispositivi secondari

sudo cryptsetup luksAddKey [device] /keyfile

Modifica /etc/crypttab :

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

Da 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.

Quindi i dispositivi secondari verranno decodificati dopo che il dispositivo primario è stato montato e il file di chiavi è disponibile (purché il dispositivo primario sia elencato in /etc/fstab correttamente).

Non dimenticare di aggiornare initramfs in modo che le modifiche di crypttab abbiano effetto:

sudo update-initramfs -u -k all

Questo approccio ha il vantaggio che systemd gestisce la richiesta della password e non richiede di mantenere uno script. Lo svantaggio è che c'è un file di chiavi su uno dei tuoi dispositivi, quindi smontare i dispositivi secondari non impedirà a qualcuno con root di decrittografarli.

    
risposta data 25.08.2017 - 17:29
fonte

Leggi altre domande sui tag