Crittografia e sicurezza Applicazioni della crittografia 1) Luks e CryptSetup (LINUX PRO 182) 2) Verifica dei pacchetti software in Apt (https://debian- handbook.info/browse/stable/sect.package-authentication.html) 3) Vulnerabilità nei package manager (https://www2.cs.arizona.edu/stork/packagemanagersecurity/att acks-on-package-managers.html)

Creare volumi cifrati con cryptsetup Si possono creare volumi protetti da una semplice password oppure utilizzando LUKS, lo standard per la cifratura dei dischi sotto Linux. I volumi LUKS contengono header che specificano il tipo di cifratura e l’hash usati insieme al salt univoco a 256 bit che viene aggiunto alla password per aumentare il livello di sicurezza Questo header contiene una master key cifrata per decifrare il container. In questo modo si può in futuro cambiare la password utilizzata oppure aggiungere più password, in modo da garantire l’accesso al dispositivo cifrato a persone fidate

Creare un container cifrato Generiamo un file con dati casuali di 512 MB sudo dd if=/dev/urandom of=test1 bs=1M count=512 Aggiungiamo un header Luks al container con sudo cryptsetup -y luksFormat test1 Montiamo il device sudo cryptsetup luksOpen test1 vol1. Lo troveremo in dev/mapper/vol1 Creiamo un file system ext4 sudo mkfs.ext4 -j /dev/mapper/vol1 Creiamo un punto di mount sudo mount /dev/mapper/vol1 /mnt/secretfiles Si possono pertanto copiare i file nella cartella segreta

Altro sul container Luks Per chiudere il container sudo umount /mnt/secretfiles sudo cryptsetup luksClose vol1 Aggiungiamo un’altra chiave per poter aprire il dispositivo sudo cryptsetup luksAddKey test1 Rimuoviamo una chiave per aprire il dispositivo sudo cryptsetup luksRemoveKey test1

Usare un file al posto di una password Possiamo usare per esempio una bellissima immagine di un gattino Attenzione che questo modo non è sicuro perché l’immagine potrebbe essere facilmente disponibile in rete, pertanto a volte è meglio usare per esempio un file di dati casuali. sudo cryptsetup luksAddKey test1 /home/utente/gatto.jpg Occorre digitare la password già impostata per il container per poter aggiungere il file chiave. Se vogliamo pertanto aprire il container usando l’immagine invece della chiave sudo crypsetup luksOpen test1 vol1 –key-file /home/utente/gatto.jpg

Che cos’è un Hash È un metodo di criptazione usato per garantire l’integrità di un messaggio Un hash o message digest è un numero generato applicando un algoritmo a una stringa di testo. L’hash è univoco per un determinato testo (o almeno dovrebbe esserlo). Due stringhe diverse non devono avere lo stesso valore di hash.

Verifica dei pacchetti software in Apt La sicurezza è molto importante, è necessario pertanto garantire che i pacchetti che si installano tramite un gestore dei pacchetti provengano da una fonte affidabile Ecco come funziona La sicurezza funziona tramite una catena di hash crittografici e firme. Il file firmato è il Release file, fornito dai mirror di Debian Contiene una lista di Packages file (in altre parole elencano i pacchetti disponibili nel mirror) insieme agli hash md5, sha1 e sha256. Questi hash garantiscono che i file non siano stati alterati. Per la verifica della firma è necessario avere a disposizione la chiave pubblica. Le chiavi che usa apt per la verifica della firma dei pacchetti si configurano tramite il comando apt-key Si possono aggiungere nuove chiavi, vedere quelle esistenti apt-key list per vedere la lista delle chiave pubbliche salvata nel portachiavi di Apt

Aggiungere la firma di un pacchetto proveniente da un repository esterno Usiamo il file source.list per aggiungere un nuovo repository per installare un nuovo pacchetto non contenuto nei repository ufficiali della distribuzione Occorre pertanto ottenere la chiave pubblica Per aggiungere la nostra chiave al portachiavi di apt dobbiamo usare questo comando apt-key add < key.asc key.asc è il file contenente una chiave pubblica gpg Una volta che le chiavi sono nel portachiavi, apt verificherà le firme prima di fare un’operazione pericolosa, pertanto il sistema non permetterà di installare un pacchetto senza poter verificare l’autenticità della firma del Release file

Vulnerabilità nei package manager E’ importante mantenere aggiornati i nostri sistemi Linux Ma anche il gestore dei pacchetti potrebbe non essere sicuro I gestori dei pacchetti hanno un accesso completo al sistema e possono anche danneggiare l’intero sistema https://www2.cs.arizona.edu/stork/packagemanagersecurity/ attacks-on-package-managers.html A questo link è contenuta una ricerca dell’Università dell’Arizona sulle vulnerabilità dei package manager più conosciuti (apt, yum, rpm) Vediamo un riassunto di questa

Replay Attack Da Wikipedia, l'enciclopedia libera. Nell'ambito della sicurezza informatica il replay-attack è una forma di attacco di rete che consiste nell'impossessarsi di una credenziale di autenticazione comunicata da un host ad un altro, e riproporla successivamente simulando l'identità dell'emittente. In genere l'azione viene compiuta da un attaccante che s'interpone tra i due lati comunicanti. Gli attacchi di tipo replay si evitano con l'uso di token di sessione generati pseudocasualmente. Un'altra contromisura è quella di utilizzare una marca temporale e di far sì che questa sia inserita nel corpo del messaggio criptato.

Metadata Replay I pacchetti sono considerati sempre sicuri una volta che la firma è stata verificata. Questo significa che anche se un pacchetto ha una vulnerabilità conosciuta, i client continueranno ad installare tale pacchetto insicuro. Un attaccante può rispondere con il pacchetto correttamente firmato ma di una versione precedente e il computer potrebbe essere sottoposto ai bug della versione precedente del pacchetto. Il comportamento predefinito dei package manager è quello di installare la versione più recente di un pacchetto che è disponibile nella distribuzione Linux. Per garantire la sicurezza di una distro sembrerebbe semplicemente necessario installare i metadati più recenti del repository di una distribuzione in modo regolare.

La sicurezza dei mirror Dato che c’è poco controllo su chi gestisce un mirror, non c’è garanzia che il mirror sia benevolo. Gli utenti di una distro potrebbero parlare con un attacker che ha creato un mirror e si è inserito nella lista dei mirror ufficiali della distribuzione

Cosa succede con un Replay Attack di un Package Manager? Quando un utente installa un pacchetto, il package manager restituisce da un mirror di un repository la lista dei pacchetti disponibili. Un mirror malevolo potrebbe rispondere con una lista dei pacchetti non aggiornata. Il cliente sa che la lista dei pacchetti è firmata, ma non sa che la lista dei pacchetti è quella vecchia.

Cosa possiamo fare per proteggerci? Usare repository di fiducia e che appartengono a organizzazioni attendibili. Aggiornare manualmente il sistema. Sapere quando gli aggiornamenti sono disponibili e le versioni corrette di questi. Verificare manualmente e installare i pacchetti. Questi controlli dovrebbe farlo il maintainer di una distribuzione. Usare repository che firmano i metadati, come apt Usare https per la comunicazione con i mirror. Apt ha un pacchetto opzionale che gestisce https apt-transport-https